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: Mon, 11 Aug 2014 15:07:33 +0300 Message-ID: <20140811150733.39a664c7@gmail.com> References: <20140811133855.77ab3f93@gmail.com> <20140811105710.GB21988@strange.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by gabe.freedesktop.org (Postfix) with ESMTP id 580C16E3C9 for ; Mon, 11 Aug 2014 05:07:39 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pn19so6568420lab.38 for ; Mon, 11 Aug 2014 05:07:38 -0700 (PDT) In-Reply-To: <20140811105710.GB21988@strange.ger.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Damien Lespiau Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org On Mon, 11 Aug 2014 11:57:10 +0100 Damien Lespiau wrote: > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote: > > Hi, > > 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. > > This looks like a fallback that would use GL to compose the intermediate > buffer. Any reason why that fallback can't be kicked from userspace? It is not GL, and GL might not be available or desireable. It is still the same 2D compositing engine in hardware, but now running with off-screen target buffer, because it cannot anymore keep up with the continous pixel rate that the direct scanout would need. If we were to use the 2D compositing engine from user space, we would be on the road to OpenWFC. IOW, there is no standard API for the user space to use yet, as far as I'm aware. ;-) I'm just trying to avoid having to design a kernel driver ABI for a user space driver, then design/implement some standard user space API on top, and then go fix all compositors to actually use it instead of / with KMS. Thanks, pq