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 <[email protected]> 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)
