> >>> 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= ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
