On Fri, 2014-12-19 at 08:26 +0000, Chris Wilson wrote: > On Fri, Dec 19, 2014 at 12:14:00AM +0200, Imre Deak wrote: > > On Thu, 2014-12-18 at 22:19 +0100, Daniel Vetter wrote: > > > On Thu, Dec 18, 2014 at 11:04:11PM +0200, Ville Syrjälä wrote: > > > > On Thu, Dec 18, 2014 at 09:37:37PM +0100, Daniel Vetter wrote: > > > > > On Thu, Dec 18, 2014 at 09:51:26AM -0800, Bob Paauwe wrote: > > > > > > When creating a fence for a tiled object, only fence the area that > > > > > > makes up the actual tiles. The object may be larger than the tiled > > > > > > area and if we allow those extra addresses to be fenced, they'll > > > > > > get converted to addresses beyond where the object is mapped. This > > > > > > opens up the possiblity of writes beyond the end of object. > > > > > > > > > > > > To prevent this, we adjust the size of the fence to only encompass > > > > > > the area that makes up the actual tiles. The extra space is considered > > > > > > un-tiled and now behaves as if it was a linear object. > > > > > > > > > > > > Testcase: igt/gem_tiled_fence_overflow > > > > > > Reported-by: Dan Hettena <danh@xxxxxxx> > > > > > > Signed-off-by: Bob Paauwe <bob.j.paauwe@xxxxxxxxx> > > > > > > > > > > Presuming this indeed blows up (I didn't try your test) this is one for > > > > > Jani. > > > > > > > > Hmm. Wasn't this problem discussed a few years ago already? My recollection > > > > is that Imre had patches but you said you don't care about the problem. > > > > > > Imre had patches iirc to resize the allocation , which would have caused > > > major havoc with moving stuff around I think. > > > > It did that only for old GENs where the POT fence size constraint gives > > you no other choice to fix this issue. On new HW I also rounded down the > > fence size. > > If we were to be consistent, then we would pad in the GTT so that no > other object fitted in the full fenced region. Yes, I did that. In v2 I changed this (based on your feedback) so the padding happens only on old GENs with the POT constraint, since on new GENs we can instead reduce the fence region size. The end of the buffer couldn't contain even a single whole pixel line, so would display incorrectly anyway. Btw, why are we not doing the fixup on old GENs too in this patch? --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
