On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian Høgsberg wrote: > One thing that's not clear to me is how we would enable a sprite > without going through the atomic modeset again. If the atomic modeset > is all about calculating bandwidth requirements etc, then enabling a > sprite will affect that and it may or may not be possible based on the > current configuration. However, enabling a sprite from one frame to > another is something that we would want to do as part of the nuclear > pageflip. So I'm not sure how this would work... maybe we could have > a prepare_sprite_enable type ioctl that verifies that it's possible to > add the sprite plane to the current configuration. Then if that > succeeds, we can use the nuclear pageflip to enable the sprite plane. Sprites also have an ugly issue wrt finer-grained locking: If we move to per-crtc locking, the nuclear pageflip would only need to take the crtc mutex it operates on. But the if we move a sprite from one crtc to another one, we'd need to lock both crtcs, and the easiest solution for the lock ordering problem this causes is to require that all code which needs more than one crtc look needs the big modeset lock. Which would be painful for pageflip. Also, most sprites/overlays can't be switched in one step from one crtc to another, so these pageflips would run synchronous. Which is not the point of pageflipping. So I think a prepare_sprite ioctl which changes the crtc association (and checks memory bandwidth and other constrains) but does not display anything would be good to support the nuclear pageflip without jumping through too many hoops in the kernel. Nuclear pageflip would need to support pageflippping from/to NULL framebuffers on planes then to signal switching a plane on/off. Maybe we could even do that for the main crtc fb (and add a background color), e.g. for video watch to avoid scanning out black bars. -Daniel -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
