Bug detailed description:
Start the game nexuiz, it is very slow with incorrect rendering. Errors appears in screen output:
i915_program_error: Exceeded max nr indirect texture lookups (6 out of 4)
i915_program_error: Exceeded max nr indirect texture lookups (7 out of 4)
i915_program_error: Exceeded max nr indirect texture lookups (5 out of 4)
This issue happens on pineview. It works well on piketon. This is regression.
The last known good commit is following:
1. start nexuiz
Created attachment 38739 [details]
xorg log file
Created attachment 38740 [details]
scrot of incorrect rendering on nexuiz
If this is a regression, where's the bisect?
We don't have resource/time to do bisect at this point.
Bisect shows a58514cc9c5cc5867f9140700462c5ac5749550d is the first bad commit.
Author: Eric Anholt <firstname.lastname@example.org>
Date: Tue Aug 17 15:07:22 2010 -0700
i915: Enable ARB_fragment_shader by default.
Now that we have glsl2 with if flattening in place, most shaders will
just work. Remaining failing shaders will mostly be due to loop
unrolling (in progress), some possible if flattening failures in
inlining functions (planning on fixing), and the register/instruction
While the GLSL and GLSL-ES specs say that shaders shouldn't fail to
compile/link due to register/instruction limits, in practice we're not
the first vendor to expose GLSL on hardware with these limitations.
The benefit to application developers of providing a better language
for GPU programming is greater than the pain of having to handle
instruction limits (which they had to for ARB_fp on this hardware
OK, the game "took advantage" of the GLSL without falling back when the GLSL failed to link. This will be an enhancement to make nexuiz's GLSL work on i915 if possible.