From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC 0/9] nuclear pageflip Date: Wed, 12 Sep 2012 17:34:48 +0300 Message-ID: <20120912143448.GC9227@intel.com> References: <1347246202-24249-1-git-send-email-rob.clark@linaro.org> <20120911141514.4b291bee@bwidawsk.net> <20120912085927.GA9227@intel.com> <20120912142354.GB9227@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by gabe.freedesktop.org (Postfix) with ESMTP id D4C409E798 for ; Wed, 12 Sep 2012 07:34:53 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Rob Clark Cc: daniel.vetter@ffwll.ch, Ben Widawsky , Kristian =?iso-8859-1?Q?H=F8gsberg?= , dri-devel@lists.freedesktop.org, patches@linaro.org List-Id: dri-devel@lists.freedesktop.org On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote: > On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj=E4l=E4 > wrote: > > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote: > >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj=E4l=E4 > >> wrote: > >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote: > >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky wr= ote: > >> >> > On Sun, 9 Sep 2012 22:19:59 -0500 > >> >> > Rob Clark wrote: > >> >> > > >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark wrote: > >> >> >> > From: Rob Clark > >> >> >> > > >> >> >> > This is following a bit the approach that Ville is taking for = atomic- > >> >> >> > modeset, in that it is switching over to using properties for = everything. > >> >> >> > The advantage of this approach is that it makes it easier to a= dd new > >> >> >> > attributes to set as part of a page-flip (and even opens the o= ption to > >> >> >> > add new object types). > >> >> >> > >> >> >> oh, and for those wondering what the hell this is all about, > >> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC = layer > >> >> >> and zero or more attached plane layers, optionally changing vari= ous > >> >> >> properties such as z-order (or even blending modes, etc) atomica= lly. > >> >> >> It includes the option for a test step so userspace compositor c= an > >> >> >> test a proposed configuration (if any properties not marked as > >> >> >> 'dynamic' are updated). This intended to allow, for example, we= ston > >> >> >> compositor to synchronize updates to plane (sprite) layers with = CRTC > >> >> >> layer. > >> >> >> > >> >> > > >> >> > Can we please name this something different? I complained about t= his in > >> >> > IRC, but I don't know if you hang around in #intel-gfx. > >> >> > > >> >> > Some suggestions: > >> >> > multiplane pageflip > >> >> > muliplane atomic pageflip > >> >> > atomic multiplane pageflip > >> >> > atomic multiflip > >> >> > pageflip of atomic and multiplane nature > >> >> > > >> >> > Nuclear is not at all descriptive and requires as your response s= hows > >> >> > :-) > >> >> > > >> >> > >> >> fair enough.. I was originally calling it atomic-pageflip until > >> >> someone (I don't remember who) started calling it nuclear-pageflip = to > >> >> differentiate from atomic-modeset. But IMO we could just call the = two > >> >> ioclts atomic-modeset and atomic-pageflip. (Or even modeset2 and > >> >> pageflip2, but that seems much more boring) > >> > > >> > My plan has been to use the same ioctl for both uses. They'll need > >> > nearly identical handling anyway on the ioctl level. I have something > >> > semi-working currently, but I need to clean it up a bit before I can > >> > show it to anyone. > >> > >> I do think the atomic-pageflip ioctl really should take the crtc-id.. > >> so probably should be two ioctls, but nearly identical > > > > But then you can't support atomic pageflips across multiple crtcs even > > if the hardware would allow it. I would hate to add such limitation to > > the API. I can immediately think of a use case; combining several > > smaller displays to form a single larger display. > > > > With a unified API you could just add some kind of flag that tells the > > kernel that user space really wants an atomic update, and if the > > driver/hardware can't do it, it can return an error. > = > well, that is really only a problem for X11.. and atomic flip across > multiple crtc's is a potential mess from performance standpoint unless > your displays are vsync'd lock. It won't be truly atomic unless they are vsync locked. But anyways more = buffers can be used to solve the performance problem. But that's a separate issue and in that case it doesn't really matter whether you issue separate ioctls for each crtc. > weston already renders each output individually, rather than spanning > a single fb across multiple displays like x11 does. So this problem > really doesn't exist for weston. It does if you want to make sure the user sees the flip on both displays at the same time. -- = Ville Syrj=E4l=E4 Intel OTC