On Mon, 11 Aug 2014 09:32:32 -0400 Rob Clark robdclark@gmail.com wrote:
On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter daniel@ffwll.ch 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