On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote: > On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > >> I think the > >> proper way is to keep track of a per-plane zpos changed (or compute > >> that ad-hoc, we have both states). And only grab more planes if a zpos > >> value changed. > > > > Doesn't work with normalized zpos. The plane's actual zpos may be > > unchanged even if the normalized zpos changes. > > Well I meant to do a first loop to check for any zpos changes, and > only then add all the planes. If no one touched zpos, then also no > normalized zpos can change. I think at least ... Or what am I missing? Enabling planes can change zpos. Which is what's currently causing all the planes to be added to the state every time the cursor is enabled/disabled on i915. Which isn't nice. And anyway adding all the planes to the state when some zpos change happens is entirely pointless on i915. There's no need to run through any of .check_plane() hooks in this case. The only thing we need to do is rewrite the sprite control registers (+ base addresses of course to arm the update). So we could just add the sprite planes to state after the .check_plane() stuff has been done so that we'll just get the .commit_plane(). So knowing somehting about the hardware allows us to do a much better job of this. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
