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. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
