Re: [RFC PATCH] drm: Add plane event

[Marcus Lorentzon <marcus.xm.lorentzon@stericsson.com>]

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