Re: GLSL: brw_eu.h assertion setting uniform variable

On 05/23/2011 04:09 PM, Jason Tiller wrote:
> Hi, Brian, :)
>
> On Fri, 13 May 2011, Brian Paul wrote:
>> On 05/11/2011 04:48 PM, Jason Tiller wrote:
>
>>> When trying to use a uniform value in a simple GLSL vertex shader, I
>>> am getting the following abort:
>>>
>>> brw_eu.h:177: brw_reg: Assertion `nr < 128' failed.
>>> Aborted
>>>
>>> I've tried this using raw GLUT (glGetUniformLocation/getUniform1i) as
>>> well as implementing this in Qt 4.7 (setUniformValue). The shader
>>> does dead simple Gouraud shading. I link it along with a super-simple
>>> passthrough fragment shader. I'm using the uniform variable to pass
>>> in the number of lights in the scene. I declare the variable at the
>>> top of my shader:
>>>
>>> uniform int numlights;
>>>
>>> If I turn the variable into a const:
>>>
>>> const int numlights = 2;
>>>
>>> then it works perfectly. Of course, I need to pass uniforms into my
>>> shader...
>>>
>>> Any ideas? I'm running:
>>>
>>> Kubuntu 11.04 (turned off all effects in KWin)
>>> KDE 4.6.3
>>> Qt 4.7.2
>>> Intel i5 430M w/i915 embedded graphics
>>> OpenGL 2.1, Mesa 7.10.2
>>> Xorg 1.10.1-1ubuntu1
>>>
>>> I'm desperate! This makes no sense at all to me, and I have no idea
>>> where to go from here.
>>>
>>> Thank you!
>>>
>>> ---Jason
>>>
>>> P.S. - I've tried fiddling with MESA_GLSL=... and can see my shaders
>>> getting compiled, the program being used, and the uniform variable
>>> being set... but still the abort. HELP!
>
>> You should file a bug for this. Or, try the latest Mesa code from
>> git.
>
> I've determined the problem - I was attempting to use a feature in my
> shader that isn't supported by my graphics chipset. Specifically, I
> was using non-constant conditions in my for loop, which isn't
> implemented in any of these extensions:
>
> GL_ARB_fragment program
> GL_ARB_fragment shader
> GL_ARB_fragment_program_shadow
> GL_ARB_vertex_program
> GL_ARB_shader_objects
> GL_ARB_vertex_shader
> GL_ARB_shading_language_100
> GL_EXT_gpu_program_parameters
> GL_EXT_separate_shader_objects
> GL_NV_vertex_program1_1
> GL_NV_vertex_program
>
> I should have realized that was the problem, but I'm *really* new to
> shaders, and I didn't understand how wildly varied all the chipsets
> are in what they support.
>
> However, I really wish that Mesa had given me a better error
> diagnostic. "brw_eu.h:177: brw_reg: Assertion `nr < 128' failed" was
> completely useless.
>
> I ended up switching over to using Cg, which worked fine. There were
> three things that sold me on using Cg for my class project:
>
> 1. The Cg compiler told me *immediately* what my problem was:
>
> "error C5013: profile does not support 'for' statements and 'for'
> could not be unrolled."
>
> In other words, the loop has to have a constant test for it to be
> unrolled.
>
> 2. The Cg runtime comes with an *excellent* set of example shaders
> and runtime examples that run with GLUT (lowest common
> denominator). All but two of the examples ran out of the box for
> me.
>
> 3. The Cg Tutorial. There's nothing like this book for GLSL. The
> SuperBible, Orange Book, etc.... none of these approach shading
> programming in the simple and straightforward way that The Cg
> Tutorial does.
>
> So, while the actual failure was pilot error in this case, Mesa
> certainly didn't help me narrow down the possibilities.
>
> Thanks for the suggestion, Brian! I'm still interested in trying
> GLSL, but I think I may wait until I have a laptop with a *real* GPU.
> For now, Cg/Qt is enough for my feeble investigations.

I haven't worked on the i965 driver in well over a year.  You should 
file a bug report for this so the i965 developers can address it.

Were you still working with an i965 GPU when you switched to Cg?

-Brian