On Mon, Oct 10, 2016 at 3:32 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > 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. Ok, I buy it ;-) So we only need this if we have a driver that's using plane_state->normalized_zpos. Having all combinatorials of atomic_check_with_featureA_featureB will get ugly. I think it'd be better to just split it out and dump it only into drivers's atomic_check that need it. Plus add a very big warning to drm_plane_state->normalized_zpos that without calling that helper it will be invalid. Bit more copypaste, but I think that's actually good (since we don't want to support all combinatorial variations with pre-made helpers imo). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
