Chris Wilson <ch...@chris-wilson.co.uk> writes: > On Thu, May 02, 2013 at 07:26:06AM -0700, Paul Berry wrote: >> Can you provide a documentation reference for why the value we're >> currently programming (0xfffff001) is unsafe, and why 0x7fff0001 is >> correct?� I don't see anything in the bspec. > > The largest GTT size for gen6 is 2GiB (it can be smaller on the whim of > the BIOS, though we try to reset it back to 2GiB in i915.ko). The upper > bound is used by the hardware to prevent invalid reads and return 0, > this is the value we program to ~4GiB. The cause of these hangs is the > constant data being read from addresses above 2GiB i.e. beyond the end > of the GTT - and so prevented by programming the upper bound to the end > of the GTT. Those with access to the simulator can hopefully verify > this, and perhaps we should add this to the set of known bad commands in > igt.
The simulator has no complaints about these batches. I don't think your model of how the constants work (that there's some undefined, possibly >2gb address being loaded at shader dispatch time, which is fixed by sending these packets) is actually how they work -- From my reading, the constants are loaded at constant packet time into a small buffer on the GPU. If the last packet and the shader disagree about that buffer, the GPU sometimes blows up.
pgpXPKLuE4xLk.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
