[PATCH v6 10/14] drm/panthor: Add the scheduler logical block
Simona Vetter
simona.vetter at ffwll.ch
Wed Sep 4 09:22:59 UTC 2024
On Wed, Sep 04, 2024 at 09:09:53AM +0200, Boris Brezillon wrote:
> On Tue, 3 Sep 2024 21:43:48 +0200
> Simona Vetter <simona.vetter at ffwll.ch> wrote:
>
> > On Thu, Feb 29, 2024 at 05:22:24PM +0100, Boris Brezillon wrote:
> > > - Add our job fence as DMA_RESV_USAGE_WRITE to all external objects
> > > (was previously DMA_RESV_USAGE_BOOKKEEP). I don't get why, given
> > > we're supposed to be fully-explicit, but other drivers do that, so
> > > there must be a good reason
> >
> > Just spotted this: They're wrong, or they're userspace is broken and
> > doesn't use the dma_buf fence import/export ioctl in all the right places.
> > For gl this simplifies things (but setting write fences when you're only
> > reading is still bad, and setting fences on buffers you don't even touch
> > is worse), for vulkan this is just bad.
>
> For the record, I remember pointing that out in some drm_sched
> discussion, and being told that this was done on purpose :-/.
Nouvea gets it right, if it was xe people then I think they were a bit
confused. I cleared that up with some irc chat on #xe yesterday evening.
> > I think you want a context creation flag for userspace that's not broken,
> > which goes back to USAGE_BOOKKEEP for everything.
>
> Honestly, given the only user (the gallium driver) is already designed
> to do the explicit <-> implicit dance, and the fact the driver just got
> merged in the last release, I'd rather go for a silent USAGE_WRITE ->
> USAGE_BOOKKEEP if things keep working with that.
Ah yeah if you can get away with just flipping that, even better. It
really shouldn't be needed when your driver uses the dma-buf fence
import/export ioctls to handle implicit sync needs.
-Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list