Change how amdgpu stores fences in dma_resv objects

[Christian König]

Am 10.06.21 um 18:34 schrieb Michel Dänzer:
> On 2021-06-10 11:17 a.m., Christian König wrote:
>> Since we can't find a consensus on hot to move forward with the dma_resv object I concentrated on changing the approach for amdgpu first.
>>
>> This new approach changes how the driver stores the command submission fence in the dma_resv object in DMA-buf exported BOs.
>>
>> For exported BOs we now store the CS fence in a dma_fence_chain container and assign that one to the exclusive fences slot.
>>
>> During synchronization this dma_fence_chain container is unpacked again and the containing fences handled individually.
>>
>> This has a little bit more overhead than the old approach, but it allows for waiting for the exclusive slot for writes again.
> Nice!
>
> This seems to work as expected with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880: Some buffers now don't poll readable at first, until the GPU is done processing them.

Well I'm still pretty sure that any polling on the CPU should be 
avoided, but yes it is nice to have that working now in general.

> Unfortunately, as expected, without a high priority context for the compositor which can preempt client drawing, this isn't enough to prevent slow clients from slowing down the compositor as well. But it should already help for fullscreen apps where the compositor can directly scan out the client buffers at least.

I have seen patches for this flying by internally, but not sure about 
the status.

Christian.