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.
Best regards,
- Maíra
As mentioned, allocating buffers through v3d and importing into ssd130x
(or simpledrm) would work correctly, since the v3d driver already sets
bo->base.map_wc = true.
Hard enforcement would mean that drivers would reject to render to
imported buffers. It is most certainly too late to implement this now.
But drivers such as v3d could at least print a warning when users
attempt to do it.
Best regards
Thomas
