On Mon, 11 Aug 2014 07:37:18 -0700 Matt Roper matthew.d.roper@intel.com 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