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 10:20:44 +0300 Message-ID: <20140812102044.6732c8e3@gmail.com> References: <20140811133855.77ab3f93@gmail.com> <20140811120636.GR8727@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by gabe.freedesktop.org (Postfix) with ESMTP id B038F898C7 for ; Tue, 12 Aug 2014 00:20:50 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v6so6648073lbi.38 for ; Tue, 12 Aug 2014 00:20:49 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Clark Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org On Mon, 11 Aug 2014 09:32:32 -0400 Rob Clark wrote: > On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter 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