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@xxxxxxxx> 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
