- Expose a dirty (or content_age property)
- Attach a clip-rect blob property.
- Fake a page-flip by ping-ponging two frame-buffers pointing to the
same underlying buffer object.
Are you saying that people are already using 3) and we should keep
using
that?
I'm saying they're using 3b), flip the same buffer wrapped in the same drm_framebuffer, and expect it to work.
The only advantage dirtyfb has is that it allows you to supply the optimized upload rectangles, but at the cost of a funny api (it's working on the fb, not the plane/crtc you want to upload) and lack of drm_event
to
confirm when exactly you uploaded your stuff. But imo they should be
the
same underlying operation.
FWIW, vmwgfx has always treated a dirtyfb as a pure front-buffer like rendering operation without any synchronization, We've guaranteed that only the rects that are present are uploaded, but
only
xf86-video-vmware has taken advantage of this to keep CPU- and GPU rendered content apart. I think we've at some point run into problems with number of cliprects,
(Old
KDE lock screen?) and use multiple dirtyfb for the same update...
Ok, if we can hit this in practices then I think it's ok to have the limit. Just need to make sure userspace actually condenses the cliprects down to something within the limit, since with atomic flips you can't just do multiple updates - that would tear badly.
So I think the conclusion is to have damage clip rect limit with proper documentation stating limitation of doing multiple updates.
Wrt not syncing: I think general use pretty clearly says lots of userspace renders into buffers with gpus (not even necessarily your own) and then expects dirtyfb or a flip to upload all the bits. Otherwise Rob Clark wouldn't need his patch. Given that I think we need to make general semantics follow that requirement - I don't expect it'll harm vmwgfx since it doesn't render into the frontbuffer anyway?
IIRC the reason for working with the fb, is that it's much easier for user-space, which doesn't have to care where planes are scanning out and why. "Present my new content on any screen that's affected".
Yeah, dirtyfb makes tons of sense for frontbuffer-rendering X, which also doesn't do per-scanout pixmaps. But for atomic flips you really want to flip on the crtc (or well plane), since otherwise with multiple planes it comes up all teared up. vmwgfx doesn't care I guess since you only have 1 primary plane, but all the SoC chips very much do.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - https://urldefense.proofpoint.com/v2/url?u=http- 3A__blog.ffwll.ch&d=DwIBaQ&c=uilaK90D4TOVoH58JNXRgQ&r=zOOG28inJK 0762SxAf-cyZdStnd2NQpRu98lJP2iYGw&m=XKgN7GPElFapBWdozPSC- 9rcfKmDvQC1QHhsFghexWc&s=SH9q5tw- UqpUBJVrr2v1mLpRo28Aau7iJ3YWlrgbPmU&e=