On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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älä >> <ville.syrjala@xxxxxxxxxxxxxxx> 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älä >> >> <ville.syrjala@xxxxxxxxxxxxxxx> 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älä >> >> >> <ville.syrjala@xxxxxxxxxxxxxxx> 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 <ben@xxxxxxxxxxxx> wrote: >> >> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500 >> >> >> >> > Rob Clark <rob@xxxxxx> wrote: >> >> >> >> > >> >> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: >> >> >> >> >> > From: Rob Clark <rob@xxxxxx> >> >> >> >> >> > >> >> >> >> >> > This is following a bit the approach that Ville is taking for atomic- >> >> >> >> >> > modeset, in that it is switching over to using properties for everything. >> >> >> >> >> > The advantage of this approach is that it makes it easier to add new >> >> >> >> >> > attributes to set as part of a page-flip (and even opens the option to >> >> >> >> >> > add new object types). >> >> >> >> >> >> >> >> >> >> oh, and for those wondering what the hell this is all about, >> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer >> >> >> >> >> and zero or more attached plane layers, optionally changing various >> >> >> >> >> properties such as z-order (or even blending modes, etc) atomically. >> >> >> >> >> It includes the option for a test step so userspace compositor can >> >> >> >> >> test a proposed configuration (if any properties not marked as >> >> >> >> >> 'dynamic' are updated). This intended to allow, for example, weston >> >> >> >> >> compositor to synchronize updates to plane (sprite) layers with CRTC >> >> >> >> >> layer. >> >> >> >> >> >> >> >> >> > >> >> >> >> > Can we please name this something different? I complained 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 response 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 modeset2 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 before I can >> >> >> > show it to anyone. >> >> >> >> >> >> I do think the atomic-pageflip ioctl really should take the crtc-id.. >> >> >> so probably should be two ioctls, but nearly identical >> >> > >> >> > But then you can't support atomic pageflips across multiple crtcs even >> >> > if the hardware would allow it. I would hate to add such limitation to >> >> > the API. I can immediately think of a use case; combining several >> >> > smaller displays to form a single larger display. >> >> > >> >> > With a unified API you could just add some kind of flag that tells the >> >> > kernel that user space really wants an atomic update, and if the >> >> > driver/hardware can't do it, it can return an error. >> >> >> >> well, that is really only a problem for X11.. and atomic flip across >> >> 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 anyways 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 happen >> 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. BR, -R > -- > Ville Syrjälä > Intel OTC > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
