From: "Maíra Canal" <mcanal@igalia.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Javier Martinez Canillas <javierm@redhat.com>,
Fabio Piparo <holofermes@gmail.com>,
Melissa Wen <mwen@igalia.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: drm/ssd130x: stale pixels when the GPU renders into the framebuffer
Date: Wed, 30 Sep 2026 10:49:41 -0300 [thread overview]
Message-ID: <a9f52cac-e8bc-4ec2-b452-0fdcb32c4713@igalia.com> (raw)
In-Reply-To: <a8814ebf-1d6b-4f71-8f53-77b7476ba0d7@suse.de>
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
>
>
>>
>
next prev parent reply other threads:[~2026-09-30 13:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 4:27 drm/ssd130x: stale pixels when the GPU renders into the framebuffer Fabio Piparo
2026-08-14 18:34 ` Javier Martinez Canillas
2026-09-14 8:43 ` Thomas Zimmermann
2026-09-23 16:00 ` Fabio Piparo
2026-09-29 9:04 ` Thomas Zimmermann
2026-09-29 21:50 ` Maíra Canal
2026-09-30 6:48 ` Thomas Zimmermann
2026-09-30 7:48 ` Javier Martinez Canillas
2026-09-30 8:32 ` Thomas Zimmermann
2026-09-30 13:49 ` Maíra Canal [this message]
2026-09-30 15:52 ` Javier Martinez Canillas
2026-09-30 18:45 ` Fabio Piparo
2026-10-02 8:18 ` Thomas Zimmermann
2026-09-30 19:57 ` Maíra Canal
2026-10-02 8:12 ` Thomas Zimmermann
2026-10-02 21:13 ` Maíra Canal
2026-10-06 6:50 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9f52cac-e8bc-4ec2-b452-0fdcb32c4713@igalia.com \
--to=mcanal@igalia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=holofermes@gmail.com \
--cc=javierm@redhat.com \
--cc=mwen@igalia.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.