On Fri, 4 Jan 2013 18:42:00 +0200, Imre Deak <imre.deak at intel.com> wrote: > The gtt space needed for tiled objects might be bigger than the linear > size programmed into the correpsonding fence register. For example for > the following buffer on a Gen5+ HW: > > - allocation size: 4096 bytes > - tiling mode: X tiled > - stride: 1536 > > we need (1536 / 512) * 4096 bytes of gtt space to cover all the pixels > in the buffer, but at the moment we allocate only 4096. This means that > any buffer following this tiled buffer in the gtt space will be > corrupted if pixels belonging to the 2nd and 3rd tiles are written. > > Fix this by rounding up the size of the allocated gtt space to the next > tile row address. The page frames beyond the allocation size will be > backed by the single gtt scratch page used already elsewhere for similar > padding. > > Note that this is more of a security/robustness problem and not fixing any > reported issue that I know of. This is because applications will normally > access only the part of the buffer that is tile row size aligned. There should not be any reported issues because all userspace already allocates up to the end of tile-row and stride should be enforced to be a multiple of tile-width. So the use of DIV_ROUND_UP implies a programming error that should have been reported back to userspace earlier. We can extend that by checking to make sure userspace has allocated a valid buffer, that is, it has allocated sufficient pages for the sampler access into the tiled buffer (or reject the set-tiling). -Chris -- Chris Wilson, Intel Open Source Technology Centre
