On Wed, Nov 07, 2012 at 02:29:45PM -0600, Rob Clark wrote: > On Thu, Nov 1, 2012 at 5:39 PM, Daniel Vetter <daniel@xxxxxxxx> 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älä <ville.syrjala@xxxxxxxxxxxxxxx> 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 <daniel@xxxxxxxx> wrote: > >> > > > >> > > > On Thu, Oct 25, 2012 at 8:05 PM, <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > >> > > > > > >> > > > > Send completion events when the atomic modesetting operations has > >> > > > > finished succesfully. > >> > > > > > >> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > >> > > > > >> > > > I have to admit I'm not on top of the latest ioctl/interface > >> > > > discussion, but one new requirement for the modeset (not the pageflip > >> > > > part) of the all this atomic stuff I've discovered is that the kernel > >> > > > needs to be able to select the crtcs for each output completely > >> > > > unrestricted. I think userspace should simply pass in abstract crtc > >> > > > ids (e.g. 0, 1, 2, ...) and the kernel then passes back the actual > >> > > > crtcs it has selected. > >> > > > > >> > > > We can't do that remapping internally because the crtc abstraction 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->pipe > >> > > > 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 == > 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 == 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
