+ 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].
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.
[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.
Best regards,
- Maíra
Best regards,
- Maíra
