On Mon, 11 Aug 2014 07:37:18 -0700 Matt Roper <matthew.d.roper@xxxxxxxxx> wrote: > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > > Hi, > > > > there is some hardware than can do 2D compositing with an arbitrary > > number of planes. I'm not sure what the absolute maximum number of > > planes is, but for the discussion, let's say it is 100. > > > > There are many complicated, dynamic constraints on how many, what size, > > etc. planes can be used at once. A driver would be able to check those > > before kicking the 2D compositing engine. > > > > The 2D compositing engine in the best case (only few planes used) is > > able to composite on the fly in scanout, just like the usual overlay > > hardware blocks in CRTCs. When the composition complexity goes up, the > > driver can fall back to compositing into a buffer rather than on the > > fly in scanout. This fallback needs to be completely transparent to the > > user space, implying only additional latency if anything. > > Is your requirement that this needs to be transparent to all userspace > or just transparent to your display server (e.g., Weston)? I'm > wondering whether it might be easier to write a libdrm interposer that > intercepts any libdrm calls dealing with planes and exposes a bunch of > additional "virtual" planes to the display server when queried. When > you submit an atomic ioctl, your interposer will figure out the best > strategy to make that happen given the real hardware available on your > system and will try to blend some of your excess buffers via whatever > userspace API's are available (Cairo, GLES, OpenVG, etc.). This would > keep kernel complexity down and allow easier debugging and tuning. That's an inventive proposition. ;-) I would still need to design the kernel/user ABI for the HVS (the 2D engine). As I am starting to believe, that the "non-real-time" use of the HVS does not belong behind the KMS API, we might as well just do things more properly, and expose it with a real user space API eventually. Thanks, pq _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
