On Fri, Nov 9, 2012 at 3:20 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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]. hmm, how does this not break weston compositor-drm (and modetest w/ vsync'd flipping.. although I suppose that is a less important use-case) >> 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. yeah, not quite sure how the backwards-compat should work.. you'd have to somehow only dynamically reassign crtcs if you could tell that userspace is new enough to cope.. BR, -R > -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
