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

[Thomas Zimmermann <tzimmermann@suse.de>]

(cc'ing v3d maintainers Maira and Melissa)

Hi

Am 23.09.26 um 18:00 schrieb Fabio Piparo:
> Hi Thomas,
>
> Thanks for taking a look.
>
> On 14.09.26 10:43, Thomas Zimmermann wrote:
>> I assume you write these frames quickly one after the other? As i2c is
>> really slow, you might write to buffers that are still being transferred
>> in the background.
>>
>> Do you read back the status of the page flips? DRM should tell you when
>> it has completed transferring a frame. See [1]
> The test renders with the GPU: two dumb buffers allocated on the
> ssd130x device and shared with v3d over PRIME. It runs at 10 fps.
> Before each flip it calls glFinish(), then flips with
> DRM_MODE_PAGE_FLIP_EVENT and waits for the event before drawing into
> the other buffer. The same test drawing with the CPU instead comes out
> clean.

A number of things come to my mind.

- Dumb buffers (from ssd130x) are not meant for HW rendering. They are 
generally for software rendering only.

- Hence, the ideomatic use for sharing graphics buffers is to model a 
producer-consumer relationship. Export the buffer from the device that 
generates the frame and import it to the buffer that displays it.

- Since you're compositor's sharing happens in the opposite direction, 
ssd130x might not sync correctly. (I'm not sure of v3d requires a 
dedicated flush.)

- Or maybe v3d needs to do a final cache flush after drawing to imported 
buffers.

If nothing else helpers, we could use map_wc for shared buffers in 
ssd130x, but it seems like papering over something else.

Best regards
Thomas


>
> I'm happy to send the test program if it would help.
>
> Best regards,
> Fabio

-- 
--
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)