Re: drm/ssd130x: stale pixels when the GPU renders into the framebuffer

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 30.09.26 um 21:57 schrieb Maíra Canal:
> + cc Chema (Mesa developer in V3D)
>
> Hi,
>
> On 30/09/26 12:52, Javier Martinez Canillas wrote:
>> Maíra Canal <mcanal@igalia.com> writes:
>>
>> Hello Maíra,
>>
>>> Hi,
>>>
>>> On 30/09/26 05:32, Thomas Zimmermann wrote:
>>>> Hi
>>>>
>>>> Am 30.09.26 um 09:48 schrieb Javier Martinez Canillas:
>>>> [...]
>>>>>>> I have a patch implementing begin/end_cpu_access to
>>>>>>> drm_gem_prime_dmabuf_ops, which fixed the issue. However, I'm 
>>>>>>> not sure
>>>>>>> we would like to support this use case upstream because, as you
>>>>>>> mentioned, dumb buffers are usually used for software-rendering 
>>>>>>> only.
>>>>>> Before we fix anything, I think we should talk to someone with
>>>>>> dma-buf/PRIME credentials.  As I outlined, the ideomatic pattern 
>>>>>> is a
>>>>>> producer-consumer relationship and HW rendering into dumb-buffers 
>>>>>> is not
>>>>>> supported. Those buffers should have been allocated on the v3d side.
>>>>>>
>>>>>> IMHO we should write down these rules in the PRIME documentation and
>>>>>> (soft-)enforce them in the implementation.
>>>>>>
>>>>> Yeah, I think either drm_gem_fb_begin_cpu_access() needs to also sync
>>>>> exported buffers (what Maíra is proposing as a fix) or there 
>>>>> should be
>>>>> documentation of the rules for cross-devices buffer sharing through
>>>>> PRIME.
>>>>
>>>> This specific case only happens with v3d and only this driver can know
>>>> when to flush caches. If we flush caches in begin_cpu_access, we 
>>>> easily
>>>> end up paying the overhead on all systems.
>>>>
>>>
>>> I believe that's the main issue. We would pay a reasonably big price to
>>> support this uncommon (and maybe even wrong) use case.
>>>
>>> P.S.: To be clear, I wasn't proposing a fix. I should have called my
>>> patch a "hack", because although it works, I don't believe we should
>>> support this use case for the reasons stated by Thomas.
>>>
>>
>> Yes, I agree with you. Making v3d to warn as Thomas suggested seems 
>> to be
>> the best compromise.
>
> I was thinking about Thomas' suggestion, and I might be missing
> something. If v3d warns when rendering to imported buffers, it will
> warn on every RPi 4/5, as Mesa renders the display path into dumb
> buffers imported from vc4. That works because vc4 buffers are WC and
> scanned out by hardware, so the CPU never reads them [1].

Oh, that's not good. It actually convinces me that v3d (and every other 
driver) should have warned about this situation. See my example below.


>
> From my point of view, the issue here is cross-device sharing of a dumb
> buffer that the exporter reads with the CPU through a cached mapping.

The whole workaround with WC doesn't fully capture the issue.

Imagine the renderer would have used discrete video memory (e.g. like on 
an old PCI device). Rendering to an imported buffer would simply not 
work at all. After rendering a frame into the video memory, the render 
driver would have to memcpy the result from the video memory to the 
imported buffer. This would need to be done on every frame because the 
importer doesn't know when exactly the exporter requires the image.  
  Sharing buffers in the other direction would work fine.  The importer 
(now ssd130x) can always setup a page mapping from the dma-buf's 
provided s/g table. The s/g table can refer directly to the video memory 
on the PCI device.


>
> [1] Right after writing this paragraph, I decided to read the
> documentation in drm_dumb_object.c and I found:
>
> * Note that dumb objects may not be used for gpu acceleration, as has 
> been
> * attempted on some ARM embedded platforms. Such drivers really must have
> * a hardware-specific ioctl to allocate suitable buffer objects.
>
> Does anyone know why Mesa kmsro create dumb buffers for rendering? Maybe
> I understood the documentation incorrectly, but it looks like we
> shouldn't be doing that.

The first bullet point talks specifically about GPU acceleration. Mesa 
creates dumb buffers for _software rendering_. Ssd130x scans out the 
final result and transfers it to the panel. No GPU rendering involved there.

Best regards
Thomas


>
> Best regards,
> - Maíra
>
>>
>>> Best regards,
>>> - Maíra
>>>
>>
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg)