On Fri, Sep 14, 2012 at 4:14 PM, Jesse Barnes <jbar...@virtuousgeek.org> wrote: > On Wed, 12 Sep 2012 21:58:31 +0300 > Ville Syrjälä <ville.syrj...@linux.intel.com> wrote: > >> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote: >> > On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrjälä >> > <ville.syrj...@linux.intel.com> wrote: >> > > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote: >> > >> But I think we could still do this w/ one ioctl per crtc for >> > >> atomic-pageflip. >> > > >> > > 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. >> > >> > I could be wrong, but I think IVI the screens would normally be too >> > far apart to matter? >> >> I was thinking of something like a display on the dash that normally >> sits low with only a small sliver visible, and extends upwards when >> you fire up a movie player for example. Internally it could be made >> up of two displays for power savings purposes. >> >> > Anyways, it is really only a problem if you can't do two ioctl()s >> > within one vblank period. If it actually turns out to be a real >> > problem, >> >> Well exactly that's the problem this whole atomic pageflip stuff is >> trying to tackle, no? ;) >> >> > we could always add later an ioctl that takes an array of >> > 'struct drm_mode_crtc_atomic_page_flip's. I'm not sure if this is >> > really useful or not.. but maybe I'm thinking too much about how >> > weston does it's rendering of different output's independently. >> >> I'm just now thinking of surfaceflinger's way of doing things, with >> its prepare and commit phases. If you need to issue two ioctls to handle >> cloned displays, then you can end up in a somewhat funky situation. >> >> Let's say you have a video overlay in use (one each display naturally), >> and you increase the downscaling factor enough so that you now have >> enough memory bandwith to support only one overlay. With independent >> check ioctls for each display, you never have the full device state >> available in the kernel, so each check succeeds during the prepare >> phase. So you decide that you can keep using the video overlays. >> >> You then proceed to commit the state, but after the first display has >> been commited you get an error when trying to commit the second one. >> What can you do now? The only option is to keep displaying the old >> frame on the other displays for some time longer, and then on the >> next frame you can switch to GPU composition. But on the next frame you >> perhaps no longer need to use GPU composition, but since you can't >> verify that in the prepare phase, you have no other option but to use >> GPU composition. >> >> So when you run into a configuration that can be supported only >> partially, you get animation stalls on some displays due to skipped >> frames, and you always have to fall back to GPU composition for the >> next frame. >> >> If on the other hand you would check the whole state in one ioctl, >> you'd get the error in the first prepare phase, and could fall back >> to GPU composition immediately. >> >> Am I too much of a perfectionst in considering such things? I don't >> think so, but perhaps other people disagree. > > I don't think there's any harm in having multiple ioctls for different > things. > > I was initially hoping the nuclear page flip would be very simple. > Intended for simply updating buffers of several planes associated with > a single display. That makes the inner loop of something like Wayland > or SF simple, but obviously doesn't cover every case (in fact I had > avoided dealing with moving planes initially). > > Rob's patchset goes further than that, but obviously not as far as you > propose. > > OTOH, keeping things really simple and not very featureful means there > are fewer points of failure, which is what I think callers would expect > from a flip API... > > So where does that leave us? I'd propose we have a very simple, > stripped down, single crtc flip ioctl, along with a big atomic mode set > ioctl, and then perhaps a fancier multi-crtc flip ioctl.
well, I do think it is quite useful to be able to enable/disable planes as part as part of the flip.. you really don't want to have to block the compositor for a synchronous operation to enable/disable a plane.. even if you have to return -EBUSY for a transition (ie. if a plane is still pending vblank on other crtc to switch over, etc) I am on the fence about multi-crtc flip. Although the everything-is-a-property approach does, I suppose, means we could support it with one ioctl. Maybe we should start without. If later we want to support multi-crtc flip, we can add a driver cap to give userspace an idea about what it could expect to work. What I am leaning towards now is an ioctl a bit more like Ville's atomic-modeset ioctl, but with a single user_data, and userspace gets a single event back (if requested). If userspace wants an event per CRTC it should do multiple ioctl calls, one per CRTC. BR, -R > -- > Jesse Barnes, Intel Open Source Technology Center > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
