Re: [PATCH] drm/i915: Only fence tiled region of object.

[Dan Hettena <danh@ghs.com>]

> > > > 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.
> >
> > Maybe they allocated one very large object for a mipmap, each level of
> > varying pitches but uploading through a single fence with a single
> > pitch, and so carefully wrote the trailing levels to account for the
> > different tile row size (but it knew the individual pages would be
> > correct).
> >
> > Technically reducing the fenced region size is an ABI change... :p
> 
> Well the last incomplete tile-row couldn't ever really be used anyway
> since writes just go somewhere. So I don't think this is a user-observable
> ABI change. And it's simpler than enlarging the tiled gtt size on gen4+,
> which might result in some more gtt thrashing. So I only want to do that
> if we really need it.

That was my thinking. Also, I tracked this particular issue down by adding padding and adding assertions that the scratch page was still all zeroes. If it's truly the case that the scratch page is only clobbered on error, I think it would be best to keep it that way for future debugging. That's the reasoning behind shrinking the fenced region as opposed to just working around the problem with padding.

Dan

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx