On Wed, Apr 18, 2012 at 05:55:15PM +0200, Marcus Lorentzon wrote: > On 04/18/2012 05:27 PM, Daniel Vetter wrote: > >On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote: > >>On 04/18/2012 04:36 PM, Daniel Vetter wrote: > >>>Last time around I've discussed with people we've ended up with 2 new > >>>ioctls: > >>> > >>>- atomic modeset, to configure the output state on more than one crtc at > >>> the same time. This is useful to get pll assignement, memory bandwidth > >>> constrains and similar stuff right. This ioctl is synchronous. A > >>> testmode can be used to inquire the driver whether the proposed mode > >>> actually works. This could be used for gui interfaces to automatically > >>> grey out unsupportable configurations, e.g. if you have 3 crtc but on 2 > >>> pll and 2 modes need to have the same pixelclocks to drive all 3 crtcs. > >>> > >>>- an atomic pageflip. This one would be like the current pageflip ioclt, > >>> i.e. run asynchronously and deliver a drm event upont completion. The > >>> idea is that compositors can use this to make flicker-free compositition > >>> with drm planes possible. I think we want drivers to be able to indicate > >>> which crtc properties they can switch with this ioctl, e.g. I expect > >>> some yuv->rbg color space properties might not work. All the changes > >>> should be applied on the same vblank, obviously. > >>Why an atomic pagefilp? How is this different from an atomic modeset > >>where only fbs change? Can't drm frmwrk "optimize" this like SETCRTC > >>does today with base/full modeset helpers? > >The important difference is that the pageflip should happen vsynced on one > >single crtc. So it can't do anything which takes longer than a vsync > >(usually you need to wait a frame for the clocks to stabilize before > >switching on the next stage in the output pipeline), so any output > >configuration changes are pretty much out of the window. We also want > >pageflip to run asynchronously and return immediately after emitting all > >relevant commands. That's not really important for modeset. > > > >So yeah, you could smash all this into one giant ioctl, but I think the > >split is useful and would simplify things quite a bit on the > >implementation side. Otherwise you need to add funny queries so that > >userspace can figure out which modeset ops run asynchronous, which can be > >vblank synced. And it needs to tell the kernel for which it wants an > >event. Especially when you have multiple crtc and want to drive all of > >them with a compositor, this can get funny. > > > >Also, I'm toying around with ideas to split up the big modeset lock such > >that operations that only touch the crtc (like pageflip, plane changes and > >cursor changes) do not take the big modeset lock but only a per-crtc > >mutex. This way a compositor running on crtc A could run without hiccups > >while we do a modeset operation on crtc B, or while a hotplug detection is > >reading back the edid from a unused connector (which can easily take > >longer than a few frames). We have tons of bug reports from users that > >complain that every 10s their cursor stalls (due to hotplug detect). > > > >If you smash everything into one ioctl, I imagine you have plenty of fun > >implementing all this. Which is why I prefer to split this up. > >-Daniel > > The async vs sync makes sense as reason for splitting them. My > problem lies somewhere in between sync modeset and async flip - > async crtc/plane/fbs modeset. > In Wayland and Android HW composer I need to asynchronously flip and > do crtc/plane modeset, but no connector/crtc modeset (so it is a > fast operation). Because I don't consider enable/disable/move a > plane to be a full synchronous modeset (same mode different > fbs/planes). But I still want the same async events to tell me the > new plane setup is activated at vsync. But as you say, maybe the > biggest issue here is the "big drm lock". So maybe user space would > be ok to do this crtc-modeset in sync mode, if it doesn't block > other operations on other crtcs. But I would prefer to be able to do > the crtc modeset async so I don't have to have a thread per crtc. Or > am I missing the obvious solution to this? Changing moving planes would be part of the big new async monster pageflip. Generally everything that the hw can change vblank-synced and asynchronously up to the logical point where the pixeldata is generated. Ans yes, Wayland/SF is exactly the use-case for this, so that you can dynamically switch surfaces to be rendered with planes, all async and properly vblank-synced. -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
