[PATCH 5/5] drm/simpledrm: Synchronize access to GEM BOs

[Thomas Zimmermann]

Hi

Am 23.09.22 um 12:58 schrieb Javier Martinez Canillas:
> On 9/23/22 12:43, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 23.09.22 um 10:06 schrieb Javier Martinez Canillas:
>>> On 9/22/22 15:09, Thomas Zimmermann wrote:
>>>> Synchronize CPU access to GEM BOs with other drivers when updating the
>>>> screen buffer. Imported buffers might otherwise contain stale data.
>>>>
>>>
>>> Can you please elaborate what the problem is? The framebuffers memory is
>>> setup by the firmware and would never come from an imported dma-buf, so
>>> could the GEM BOs even be shared with other drivers?
>>>
>>> Or is this done just for the sake of correctness ?
>>
>> This isn't about the scanout buffer that we get from the firmware. This
>> is about synchronizing access to the GEM BO memory buffers. Our BOs'
>> memory buffer are allocated from SHMEM or could be imported via dma-buf.
>> In the latter case, another driver or hardware might modify their
>> content concurrently. We need to synchronize before reading the memory
>> from our CPU. The pattern is
>>
>>     1) sync BO memory content via begin_cpu_access()
>>     2) blit from BO mem to scanout buffer
>>     3) release BO memory via end_cpu_access()
>>
> 
> Yeah, I got that part. What I was asking is if importing from dma-buf is
> a real use case for simpledrm or if this patch was more about making the
> driver correct and aligned with what other DRM drivers do?

In a multi-GPU scenario, it could happen that one display uses 
simpledrm. If the other GPU has a native driver that exports the BO for 
screen mirroring, the synchronization might be needed. Admittedly it's 
not a likely scenario. But still...

Best regards
Thomas

> 
> In any case I agree with the change, it's just the rationale for it that
> wasn't clear to me.

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220923/f7762117/attachment.sig>