The 915 driver is counting texture indirections incorrectly. See ARB_fragment_program question (24) for details on texture indirection accounting -- they match our hardware quite well. A simple summary of the failure would be a sample program that looks like: ---------------- phase 0 mul r0 t0 c0 mul r1 t1 c1 ---------------- phase 1 texld r2 r0 s0 texld r3 r1 s1 mul oC r2 r3 Our driver would count this as ---------------- phase 0 mul r0 t0 c0 mul r1 t1 c1 ---------------- phase 1 texld r2 r0 s0 ---------------- phase 2 texld r3 r1 s1 mul oC r2 r3 We also fail to count indirections when the destination is write masked, and when the destination has already been read or written in the current phase.
Addded regression test to piglit commit 94dac46a5c45e09c7163591435b3f4195b66175f Author: Eric Anholt <eric@anholt.net> Date: Sat Oct 4 18:35:48 2008 -0700 Add a test for ARB_fp texture indirection accounting. and a fix for the testcase to mesa: commit 91d0020eecb78ef2984fd0afafc5d555c0e957d8 Author: Eric Anholt <eric@anholt.net> Date: Sat Oct 4 18:20:35 2008 -0700 i915: Refine the texture indirect lookup accounting. Without this, we would reject programs which sampled multiple times from registers defined in the same phase (block of instructions with the same texture indirection count), as each sample would count as a new phase beginning. Instead, keep track of which phases registers were written in, and only bump phase when we're reading from one generated in this phase. On the other hand, we failed to count oC or oD texture samples as being new phases.
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.