On Sat, Sep 1, 2012 at 5:58 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: > yeah, nuclear-pageflip would be associated only w/ a single crtc. > Actually I was kinda assuming atomic-modeset was too.. ie. moving a > plane from one crtc to another would be two ioctls, one to remove it > from first crtc, one to add to the other. Although maybe one big > ioctl is better. > > I do think there is a bit of a grey area between the two. Ie. > enabling/disabling a crtc, or changing what encoder->connector it is > hooked to might be taking several vblank cycles, and is a relatively > infrequent operation so ok to block. Enabling/disabling a plane could > be much more frequent and should not block. Returning EINVAL or EBUSY > in the transient case where it isn't ready quite yet seems like a good > approach.. EBUSY might be better for "it might succeed if you try > again in next vblank" and EINVAL for "it won't ever work with current > setup, don't bother trying again". > > Infrequent, can be slow: > + enabling/disabling a new output > > Semi-frequent, should not block but -EBUSY ok: > + enabling/disabling a plane > + resizing a plane > > More frequent, should not block, should not need extra "test" ioctl > step, but should just work > + page flip, update plane position > > So for that middle group, I'm a bit fuzzy on where those operations > should fit in.. My idea is that the nuclear pageflip should support those since they only affect a single crtc. The compositor would simply assume it will work out, and the kernel can then succeed, or return either the transient or definite -EINVAL if it doesn't work out. In the later case the compositor can retry in the next frame (and fall back to gpu compositing for the current one). [snip] >> - Also a rather practical one: The lack of nuclear pageflip is the reason >> that Wayland/Weston can't use sprites atm (since set_plane is can be >> synchronous and can't be synced with a pageflip). Kristian therefore >> wants the atomic modeset (which I think is much more invasive) not to >> stall the nuclear pageflip support. And the implementation effort is imo >> really a big difference: For i915.ko I expect the nuclear pageflip to >> mostly boil down to wiring up async plane/cursor updates through the >> latch register (with keeping all the other setup code around since we >> only allow at most one outstanding pageflip per crtc currently anyway) >> and wiring that up with the existing crtc pageflip handler. atomic >> modeset otoh requires an invasive rewrite of the driver code to properly >> handle these shared resources (and support the test mode). The beginning >> of that is happening with the modeset rework, but that's just the first >> step. > > Hmm, I was thinking Ville's atomic fxns would be useful, but maybe I > can still bits from that and try and put nuclear-pageflip beneath > atomic-modeset in the stack. At least in i915 I expect that the atomic modeset and the nuclear pageflip would take rather different paths. I'm not even sure whether we should support enabling planes in the amotic modeset (userspace can always composite the first frame after a modeset with the gpu) and handle enabling planes with only the nuclear pageflip. I guess we /could/ add a few things to the crtc helper code to facilitate drivers using them to support atomic modeset. I'm thinking of a simple ->check callback at the beginning, which checks whether the global configuration can be supported. This checking would be in addition to the ->mode_fixup checking we already have in place at the encoder/crtc layer. Then we could add a simple atomic_modeset implementation for using these interfaces. For the nuclear pageflip I guess we'll just add a new crtc interface (not in the helper func pointer) which gets all the new parameters and let drivers sort things out. Since the flip needs to happen synced to the same vblank for everything, I don't see how we could compose this without some in-depth hw knowledge (which only the driver has) in some generic framework. And we do not yet support pageflip on planes (at least not in full glory with drm events and timestamps) anyway. Cheers, Daniel -- Daniel Vetter daniel.vetter@xxxxxxxx - +41 (0) 79 364 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
