Re: Patches for performance improvement

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Sun, Aug 25, 2013 at 04:35:52AM +0000, Kannan, Vandana wrote:
> Hi,
> 
>             For sprite performance improvement, instead of the patch "drm/i915: Don't wait for vblank for sprite plane flips", we made use of Chris Wilson's patches from "RFC asynchronous vblank tasks" and verified that it gives the expected performance boost.
>             Chris's patches have not been merged yet, specifically,
>             drm/i915: Introduce vblank work function
>             drm/i915: Asynchronously unpin the old   framebuffer after the next vblank
>             drm/i915/sprite: Make plane switching     asynchronous
> 
>             Will the updated patches for these be coming any time soon ? We require these patches as it gives us a very good performance improvement.
>             Please let me know, I can verify with the updated patches.

I don't seem to have said patches in my mailbox, so I can't comment on
the details, but...

My main concern is again the contents of the old fb after the setplane
ioctl returns. Due to the current synchronous nature of the ioctl,
userspace knows that when the ioctl returns the flip has completed, and
so can write the old fb again.

If the ioctl is async, userspace has to guess whether the old fb can
be safely written. We could solve this with a new event that gets sent
from setplane. We do have plenty of flags left in setplane so it's
certainly doable.

Also with the async ioctl userspace can issue another setplane before
the previous flip has completed. I personally think that's a nice
feature that allows no-fps-limits triple buffering, but it does make it
a bit more difficult to know which fb is actually being used at a given
time. I have it solved in my atomic page flip code though, as the
drm_flip_helper contraption knows how to track this stuff.

Maybe someone should just start pulling in the drm_flip_helper and
associated code from the atomic code to make this feasible. The new
event type I added there would also be suitable for this purpose as
it carries the plane id and information on which fb is freed by the
operation. The other option is to just add a new event, and disallow
another setplane until the previous has completed (maybe try to
generalize the current page flip code a bit to handle sprites as
well as primary planes?)

-- 
Ville Syrjälä
Intel OTC