On Mon, May 02, 2016 at 09:40:45PM +0300, Ville Syrjälä wrote: > On Mon, May 02, 2016 at 11:01:19PM +0530, Thulasimani, Sivakumar wrote: > > basic question, the old code had linear_offset calculated first and then > > x & y > > were updated if rotation was set. the new code looks better since we handle > > it after rotation but why not do the same for gen >= 4 too ? i.e move the > > intel_compute_tile_offset after considering rotation ? > > The hardware gets upset it you ask it to walk backwards past DSPSURF, > so DSPSURF must be below the entire scanned out surface. Hence we must > compute it before considering 180 degree rotation. Should probably add > a comment somewhere to explain that... > > Hmm. Now that I think about this, the old code tried to play tricks to > compute both the linear and tiled offsets probably so that we could > switch tiling modes with CS flips without reprogramming the linear/x/y > offsets. But that can't actually work correctly unless the tile offset > is tile row aligned, which it might not be. So yeah, I think the > "change tiling mode with CS flips" thing was broken already, and still > will be after this patch. It is for a slightly different reason: emulating large (>8192 e.g.) CRTC x/y offsets. Changing tiling mode through flips should have been exercised (and I guess a missed opportunity now would be to use i915.mmio_flips to force that test case to exercise both CS and mmio flips explicitly). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
