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 20:27:56 +0300 Message-ID: <20120912172756.GG9227@intel.com> References: <20120912085927.GA9227@intel.com> <20120912142354.GB9227@intel.com> <20120912143448.GC9227@intel.com> <20120912151233.GD9227@intel.com> <20120912153253.GE9227@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 211709E830 for ; Wed, 12 Sep 2012 10:28:19 -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 10:48:16AM -0500, Rob Clark wrote: > On Wed, Sep 12, 2012 at 10:32 AM, Ville Syrj=E4l=E4 > wrote: > > On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote: > >> On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrj=E4l=E4 > >> wrote: > >> > On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote: > >> >> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj=E4l=E4 > >> >> wrote: > >> >> > 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 wrote: > >> >> >> >> >> > 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 ta= king for atomic- > >> >> >> >> >> >> > modeset, in that it is switching over to using proper= ties for everything. > >> >> >> >> >> >> > The advantage of this approach is that it makes it ea= sier to add new > >> >> >> >> >> >> > attributes to set as part of a page-flip (and even op= ens the option to > >> >> >> >> >> >> > add new object types). > >> >> >> >> >> >> > >> >> >> >> >> >> oh, and for those wondering what the hell this is all a= bout, > >> >> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates = the CRTC layer > >> >> >> >> >> >> and zero or more attached plane layers, optionally chan= ging various > >> >> >> >> >> >> properties such as z-order (or even blending modes, etc= ) atomically. > >> >> >> >> >> >> It includes the option for a test step so userspace com= positor can > >> >> >> >> >> >> test a proposed configuration (if any properties not ma= rked as > >> >> >> >> >> >> 'dynamic' are updated). This intended to allow, for ex= ample, weston > >> >> >> >> >> >> compositor to synchronize updates to plane (sprite) lay= ers with CRTC > >> >> >> >> >> >> layer. > >> >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > Can we please name this something different? I complaine= d about this 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 r= esponse shows > >> >> >> >> >> > :-) > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> 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 modes= et2 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 bef= ore I can > >> >> >> >> > show it to anyone. > >> >> >> >> > >> >> >> >> I do think the atomic-pageflip ioctl really should take the c= rtc-id.. > >> >> >> >> so probably should be two ioctls, but nearly identical > >> >> >> > > >> >> >> > But then you can't support atomic pageflips across multiple cr= tcs even > >> >> >> > if the hardware would allow it. I would hate to add such limit= ation to > >> >> >> > the API. I can immediately think of a use case; combining seve= ral > >> >> >> > smaller displays to form a single larger display. > >> >> >> > > >> >> >> > With a unified API you could just add some kind of flag that t= ells the > >> >> >> > kernel that user space really wants an atomic update, and if t= he > >> >> >> > driver/hardware can't do it, it can return an error. > >> >> >> > >> >> >> well, that is really only a problem for X11.. and atomic flip a= cross > >> >> >> 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 anyway= s 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. > >> >> > >> >> that was basically my thinking.. separate ioctls for each crtc. The > >> >> way my branch works currently, you can do this. A page-flip on crtc > >> >> #2 won't care that there is still a flip pending on crtc #1. > >> >> > >> >> I guess that doesn't strictly guarantee that the two pageflips happ= en > >> >> at the exact same time, but unless you have some way to vsync lock = the > >> >> two displays, I don't think that is possible anyways. > >> > > >> > Sure you need hardware to keep the pipes in sync. > >> > > >> >> So I'm not > >> >> really sure it is worth over-complicating the ioctl to support two > >> >> crtc's. The error checking in case a vsync is still pending is much > >> >> easier in the driver if you know the crtc up-front at the > >> >> atomic_begin() point. Which is why I prefer to pass the crtc_id as= a > >> >> field in the ioctl. > >> > > >> > Doing such checks in atomic_begin() is way too early. Unless you want > >> > to block/return immediately if there's a pending flip. > >> > >> I want to return -EBUSY immediately if there is a pending flip. > >> > >> > I want to allow user space to force feed the driver with flips at > >> > speeds greater than the display refresh. The last frame to finish > >> > rendering before the vblank is the one that should end up on the > >> > screen. That way you can do tear-free triple buffering without > >> > throttling to screen refresh, which is great for benchmarks. It's > >> > also a nice way to support cases where you want to throttle to a > >> > 60 Hz display, but you still want to clone the content to say a > >> > 24 or 30 Hz display. > >> > >> Hmm, I still think that userspace should handle this. > >> > >> Keeping the existing semantics of -EBUSY when there is a pending flip > >> makes it easier to implement legacy page_flip on top of the atomic > >> APIs so the driver doesn't have to care about the difference. I don't > >> really see the problem w/ userspace dropping frames (depending on egl > >> swap-interval) if there is still a pending page-flip. > > > > It will have to drop the most recent frames, whereas the kernel > > implementation can drop the older frames, while keeping the latest > > one. This will help minimize latency. > = > Hmm, ok.. that is a good point. Well, I suppose we could pass > page_flip->flags in to atomic_begin(), and add a flag to specify > drop-behavior if you are trying to flip faster than vsync. Probably > also need to add a driver cap to indicate whether or not the hw is > capable of this. You could implement the "drop most recent" behaviour without issuing the ioctl at all. You just check whether you already received the completion event for the previous flip. BTW there's a one extra complication in the "drop oldest" behaviour. The completion event should somehow carry information telling which fbs became idle when the flip completed. > But I think we could still do this w/ one ioctl per crtc for atomic-pagef= lip. We could, if we want to sacrifice the synced multi display case. I just think it might be a real use case at some point. IVI feels like the most likely short term cadidate to me, but perhaps someone would finally introduce some new style phone/tablet thingy. I have seen concepts/prototypes of such multi display gadgets in the past, but the industry apparently got a bit stuck on the rectangular slab with touchscreen on one side design. -- = Ville Syrj=E4l=E4 Intel OTC