On 04/18/2012 06:06 PM, Ville Syrjälä wrote:
> 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.
I don't think there's that much differnce. You build up the full device
state, check it, and when you're ready to commit it you decide whether
to go with the blocking approach or not.
Yes, this is exactly what I do in our driver today. It doesn't cost much
CPU to do it. Just copying a few values to a device state struct and
verifying it is ok on commit. Then just wait for vsync and apply. All
"heavy" calculations are done before vsync. If modeset come late (just
before vsync) it could just as easily have come just after, so it makes
no difference. Plane/fb/crtc modeset should be expected to come before
vsync since most rendering is async today. So user is probably spending
most time waiting for vsync of previous modeset/flip and will issue the
next as soon as the previous is complete. And the app rendering
complexity probably outweighs the state tracking CPU load by far.
And I do like the idea of one single modeset ioctl that is async and
atomic. I think this could make things simpler, not more complex. Having
to support multiple paths depending on what ioctl is used by an app
doesn't seem much easier (already 3 helper callbacks - base, full,
flip). But I don't have the solid experience with drm frmwrk to make
that decision.
/Marcus
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
