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