From: Eric Anholt <eric@anholt.net>
To: Rob Herring <robh@kernel.org>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
David Airlie <airlied@linux.ie>,
"Marty E. Plummer" <hanetzer@startmail.com>,
Sean Paul <sean@poorly.run>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>
Subject: Re: [RFC PATCH] drm/panfrost: Add initial panfrost driver
Date: Wed, 13 Mar 2019 09:09:23 -0700 [thread overview]
Message-ID: <87o96eoix8.fsf@anholt.net> (raw)
In-Reply-To: <CAL_JsqLuoNW8Gk9bp_f4VQkEzbXOPM=GeHWEMSvvaCKtNeRHtA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2442 bytes --]
Rob Herring <robh@kernel.org> writes:
> On Fri, Mar 8, 2019 at 10:29 AM Eric Anholt <eric@anholt.net> wrote:
>>
>> Rob Herring <robh@kernel.org> writes:
>>
>> > From: "Marty E. Plummer" <hanetzer@startmail.com>
>> >
>> > This adds the initial driver for panfrost which supports Arm Mali
>> > Midgard and Bifrost family of GPUs. Currently, only the T860 Midgard GPU
>> > has been tested.
>
> [...]
>
>> It looks like you've got v3d's silliness with the fences -- we reserve a
>> shared slot, then use excl only anyway. For v3d I'm planning on moving
>> to just excl -- only one of my entrypoints has info on write vs
>> read-only, and I don't know of a usecase where having multiple read-only
>> consumers of a shared buffer simultaneously matters.
>>
>> More importantly, I think you also have my bug of not doing implicit
>> synchronization on buffers, which will break X11 rendering
>> sometimes. X11's GL requirements are that previously-submitted rendering
>> by the client fd will execute before X11's rendering on its fd to the
>> same buffers. If you're running a single client, X11's copies are cheap
>> enough that it'll probably work out most of the time.
>
> Is there a fix for this? I didn't find anything that looked like one.
>
>>
>> > --- /dev/null
>> > +++ b/include/uapi/drm/panfrost_drm.h
>>
>> > +#define DRM_IOCTL_PANFROST_SUBMIT DRM_IOWR(DRM_COMMAND_BASE + DRM_PANFROST_SUBMIT, struct drm_panfrost_submit)
>> > +#define DRM_IOCTL_PANFROST_WAIT_BO DRM_IOWR(DRM_COMMAND_BASE + DRM_PANFROST_WAIT_BO, struct drm_panfrost_wait_bo)
>> > +#define DRM_IOCTL_PANFROST_CREATE_BO DRM_IOWR(DRM_COMMAND_BASE + DRM_PANFROST_CREATE_BO, struct drm_panfrost_create_bo)
>> > +#define DRM_IOCTL_PANFROST_MMAP_BO DRM_IOWR(DRM_COMMAND_BASE + DRM_PANFROST_MMAP_BO, struct drm_panfrost_mmap_bo)
>> > +#define DRM_IOCTL_PANFROST_GET_PARAM DRM_IOWR(DRM_COMMAND_BASE + DRM_PANFROST_GET_PARAM, struct drm_panfrost_get_param)
>> > +#define DRM_IOCTL_PANFROST_GET_BO_OFFSET DRM_IOWR(DRM_COMMAND_BASE + DRM_PANFROST_GET_BO_OFFSET, struct drm_panfrost_get_bo_offset)
>>
>> SUBMIT and WAIT_BO might be IOR instead of IOWR
>
> Huh? Perhaps WAIT_BO should be IOW as we don't update the timeout
> being absolute, but both have input parameters and SUBMIT has output
> params.
Sorry, IOW was what I meant. I'm not seeing the output param of SUBMIT
-- are you thinking of how the syncobj gets updated?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-03-13 16:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-08 0:24 [RFC PATCH] drm/panfrost: Add initial panfrost driver Rob Herring
2019-03-08 0:51 ` Dave Airlie
2019-03-08 2:33 ` Alyssa Rosenzweig
2019-03-08 5:00 ` Alyssa Rosenzweig
2019-03-08 8:18 ` Neil Armstrong
2019-03-08 14:39 ` Rob Herring
2019-03-08 14:50 ` Neil Armstrong
2019-03-08 14:31 ` Rob Herring
2019-03-08 15:34 ` Alyssa Rosenzweig
2019-03-08 16:16 ` Rob Herring
2019-03-08 18:46 ` Alyssa Rosenzweig
2019-03-08 8:20 ` Neil Armstrong
2019-03-08 14:51 ` Rob Herring
2019-03-08 16:28 ` Eric Anholt
2019-03-13 13:06 ` Rob Herring
2019-03-13 16:09 ` Eric Anholt [this message]
2019-03-13 17:58 ` Rob Herring
2019-03-13 17:56 ` Eric Anholt
2019-03-14 9:01 ` Neil Armstrong
2019-03-14 12:46 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o96eoix8.fsf@anholt.net \
--to=eric@anholt.net \
--cc=airlied@linux.ie \
--cc=alyssa@rosenzweig.io \
--cc=dri-devel@lists.freedesktop.org \
--cc=hanetzer@startmail.com \
--cc=maxime.ripard@bootlin.com \
--cc=robh@kernel.org \
--cc=sean@poorly.run \
--cc=tomeu.vizoso@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.