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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
