From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: How to design a DRM KMS driver exposing 2D compositing? Date: Tue, 12 Aug 2014 11:42:53 +0300 Message-ID: <20140812114253.0095e04f@gmail.com> References: <20140811133855.77ab3f93@gmail.com> <20140811143718.GT11532@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by gabe.freedesktop.org (Postfix) with ESMTP id 4CB876E036 for ; Tue, 12 Aug 2014 01:42:59 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so6854502lbg.12 for ; Tue, 12 Aug 2014 01:42:58 -0700 (PDT) In-Reply-To: <20140811143718.GT11532@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Matt Roper Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org On Mon, 11 Aug 2014 07:37:18 -0700 Matt Roper 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