From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 46/51] drm/i915: Add support for atomic modesetting completion events Date: Fri, 9 Nov 2012 22:20:42 +0100 Message-ID: <20121109212042.GC5854@phenom.ffwll.local> References: <1351188354-24233-1-git-send-email-ville.syrjala@linux.intel.com> <1351188354-24233-47-git-send-email-ville.syrjala@linux.intel.com> <20121101073912.7082d1fb@jbarnes-desktop> <20121101170702.GR3791@intel.com> <20121101101221.6039ab23@jbarnes-desktop> <20121101223958.GG5755@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by gabe.freedesktop.org (Postfix) with ESMTP id 801789E768 for ; Fri, 9 Nov 2012 13:19:29 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id c1so2445642eek.36 for ; Fri, 09 Nov 2012 13:19:28 -0800 (PST) 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: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Wed, Nov 07, 2012 at 02:29:45PM -0600, Rob Clark wrote: > On Thu, Nov 1, 2012 at 5:39 PM, Daniel Vetter wrote: > > On Thu, Nov 01, 2012 at 10:12:21AM -0700, Jesse Barnes wrote: > >> On Thu, 1 Nov 2012 19:07:02 +0200 > >> Ville Syrj=E4l=E4 wrote: > >> > >> > On Thu, Nov 01, 2012 at 07:39:12AM -0700, Jesse Barnes wrote: > >> > > On Thu, 1 Nov 2012 12:12:35 +0100 > >> > > Daniel Vetter wrote: > >> > > > >> > > > On Thu, Oct 25, 2012 at 8:05 PM, wrote: > >> > > > > From: Ville Syrj=E4l=E4 > >> > > > > > >> > > > > Send completion events when the atomic modesetting operations = has > >> > > > > finished succesfully. > >> > > > > > >> > > > > Signed-off-by: Ville Syrj=E4l=E4 > >> > > > > >> > > > I have to admit I'm not on top of the latest ioctl/interface > >> > > > discussion, but one new requirement for the modeset (not the pag= eflip > >> > > > part) of the all this atomic stuff I've discovered is that the k= ernel > >> > > > needs to be able to select the crtcs for each output completely > >> > > > unrestricted. I think userspace should simply pass in abstract c= rtc > >> > > > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actu= al > >> > > > crtcs it has selected. > >> > > > > >> > > > We can't do that remapping internally because the crtc abstracti= on is leaky: > >> > > > - wait_for_vblank requires the pipe id, which could then change = on every modeset > >> > > > - similarly userspace doing MI_WAIT for scanlines needs to know = the > >> > > > actual hw pipe in use by a crtc. > >> > > > And current userspace presumes that the mapping between crtc->pi= pe > >> > > > doesn't change. > = > I don't know if it is possible, but it would be nice to try to clean > up crtc<->pipe stuff.. userspace, at least modetest, assumes crtc =3D=3D > crtc_list[pipe]. But I haven't noticed yet anywhere that this > relationship is documented. And if you are thinking about doing what > I think you are thinking about doing, then this assumption would no > longer hold for i915. This relationship does already no longer hold on i915 - on gen3 at least we sometimes switch the crtc->pipe assignement (to make fbc more useful), which means even with todays code userspace cannot assume (when running on i915), that the vblank pipe satisfies crtc =3D=3D crtc_list[pipe]. > How frequently do you emit waits for scanline? Places where the pipe > # ends up in cmdstream, would it be too crazy to handle that like a > reloc where the kernel goes and fixes up the actual value in the > cmdstream as it does it's GEM reloc pass? If you did this then you > could virtualize pipe as well as crtc. Every dri2 copyregion or Xv upload to the frontbuffer on pre-gen6 will use it. And we need old userspace to keep on working - presumably the fb layer will switch to using the new atomic modeset stuff (if available) to figure out an optimal config, so this is relevant. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch