[Freedreno] [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

[Deepak Singh Rawat]

> >>> 1) Expose a dirty (or content_age property)
> >>> 2) Attach a clip-rect blob property.
> >>> 3) 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=