On Mon, 11 Aug 2014 09:32:32 -0400 Rob Clark <robdclark@xxxxxxxxx> wrote: > On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > >> What if I cannot even pick a maximum number of planes, but wanted to > >> (as the hardware allows) let the 2D compositing scale up basically > >> unlimited while becoming just slower and slower? > >> > >> I think at that point one would be looking at a rendering API really, > >> rather than a KMS API, so it's probably out of scope. Where is the line > >> between KMS 2D compositing with planes vs. 2D composite rendering? > > > > I think kms should still be real-time compositing - if you have to > > internally render to a buffer and then scan that one out due to lack of > > memory bandwidth or so that very much sounds like a rendering api. Ofc > > stuff like writeback buffers blurry that a bit. But hw writeback is still > > real-time. > > not really sure how much of this is exposed to the cpu side, vs hidden > on coproc.. > > but I tend to think it would be nice for compositors (userspace) to > know explicitly what is going on.. ie. if some layers are blended via > intermediate buffer, couldn't that intermediate buffer be potentially > re-used on next frame if not damaged? Very true, and I think that speaks for exposing the HVS explicitly to user space to be directly used. That way I believe the user space could track damage and composite only the minimum, rather than everything every time which I suppose the KMS API approach would imply. We don't have dirty regions in KMS API/props, do we? But yeah, that is starting to feel like a stretch to push through KMS. > >> Should I really be designing a driver-specific compositing API instead, > >> similar to what the Mesa OpenGL implementations use? Then have user > >> space maybe use the user space driver part via OpenWFC perhaps? > >> And when I mention OpenWFC, you probably notice, that I am not aware of > >> any standard user space API I could be implementing here. ;-) > > > > Personally I'd expose a bunch of planes with kms (enough so that you can > > reap the usual benefits planes bring wrt video-playback and stuff like > > that). So perhaps something in line with what current hw does in hw and > > then double it a bit or twice - 16 planes or so. Your driver would reject > > any requests that need intermediate buffers to store render results. I.e. > > everything that can't be scanned out directly in real-time at about 60fps. > > The fun with kms planes is also that right now we have 0 standards for > > z-ordering and blending. So would need to define that first. > > > > Then expose everything else with a separate api. I guess you'll just end > > up with per-compositor userspace drivers due to the lack of a widespread > > 2d api. OpenVG is kinda dead, and cairo might not fit. > > I kind of suspect someone should really just design weston2d, an api > more explicitly for compositing.. model after OpenWFC if that fits > nicely. Or not if it doesn't. Or just use the existing weston > front-end/back-end split.. > > I expect other wayland compositors would want more or less the same > thing as weston (barring pre-existing layer-cake mess.. cough, cough, > cogl/clutter/gnome-shell..) > > We could even make a gallium statetracker implementation of weston2d > to get some usage on desktop.. Yeah. I suppose I should aim for whatever driver-specific interface we need for the HVS to be used from user space, use that in Weston, and get a feeling of what might be a nice, driver-agnostic 2D compositing API. Thanks, pq _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
