0x0314e050: 0x61010006: STATE_BASE_ADDRESS 0x0314e054: 0x00000001: general state base address 0x00000000 0x0314e058: 0x00000001: surface state base address 0x00000000 0x0314e05c: 0x00000001: indirect state base address 0x00000000 0x0314e060: 0x00000001: instruction state base address 0x00000000 0x0314e064: 0x10000001: general state upper bound 0x10000000 0x0314e068: 0x10000001: indirect state upper bound 0x10000000 0x0314e06c: 0x10000001: instruction state upper bound 0x10000000
And if we look at some of the other auxiliary instructions buffers sent along with the batch: 0314e000 16384 0048 0000 000ab700 dirty purgeable render uncached ... 11e30000 4096 0011 0000 000ab700 purgeable render uncached 11e2b000 4096 0011 0000 000ab700 purgeable render uncached 10e43000 4096 0011 0000 000ab700 render uncached 10e44000 4096 0011 0000 000ab700 purgeable render uncached 0x10 being the instruction domain for a total of about 20 instruction buffers referenced from that batch above the upper bound (and in particular appears to have been the first batch to use addresses above 256M). This batch fits the modus operandi of the bug that was fixed in 2.14.901, it would seem sensible to address the known issue first. -Chris -- Chris Wilson, Intel Open Source Technology Centre
