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?
/BR
/Marcus
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
