Hey Daniel,
Am 26.06.22 um 00:45 schrieb Daniel Vetter:
[SNIP]
I think we should highlight a bit more that for explicitly synchronized
userspace like vk OTHER is the normal case. So really not an exception.
Ofc aside from amdkgf there's currently no driver doing this, but really
we should have lots of them ...
See https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2FYZ%2By%2BUwo809qtvs5%40phenom.ffwll.local%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C88037a566a8d4c8d4aca08da56fc6e3c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637917939428739923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6sYto7GCLw8i3pT9OCFN1l6dxeYYHPghzKDMYxqUw90%3D&reserved=0
I didn't find anything else. So not sure how we managed to create
confusion here :-(
Well you said something like "Yeah, READ is supposed to be used for
that...." and that created the impression that AMDGPU should start using
that for Vulkan submissions and you are rejecting my idea of using
BOOKKEEP for that.
I mean that still makes a lot of sense to me because if I'm not completely
mistaken we do have use cases which break, especially Vulkan+encoding.
Yeah I think we only have some communication fumble here, nothing else :-)
Ok, well then @Bas: Sorry for all the noise, we are actually all on the
same page :)
And yes libva doesn't have any support for vk's explicit sync model, so
that will just fall flat on its face. Might motivate a few folks to fix
libva :-)
Well that's not the problem. The problem is that we have a couple of use
cases where libva is supposed to encode a Vulkan surface without letting
Vulkan know about that.
In other words: Application shares DMA-buf between Vulkan and VA-API,
renders with Vulkan and encodes with VA-API without any explicit
synchronization between the two.
I know that this is absolutely against the Vulkan specification, but it
just happened to work fine. And when you break something which used to
work people start to complain...
Note that on i915 side it's exactly the same, we've also been setting the
READ fence thus far. Since the breakage will be introduced by upgrading
mesa we'll at least avoid the kernel regression complaints, or at least I
hope we can get away with that.
Yeah, the path to salvation start's with the words: It's not my f...
problem :)
Since really I don't have any idea how it could be fixed otherwise, except
through some really, really terrible hacks. Maybe kernel module option or
so.
Anyway I think all we need is just a patch to the dma_resv docs to explain
that USAGE_BOOKKEEPING is what vulkan userspace wants, and why. Bas,
you're up to typing that?
I can do that. I'm just back from a week of vacation and still digging
through my mails.
Cheers,
Christian.
Cheers, Daniel
