Using GLSL with Mesa-6.3 problem

Hey everyone,

Having tried and failed in every way to create a simple shader using GLSL, i downloaded the GLSL version of HelloGPGPU (a simple shading program) and ran that.

[joe@helloGPGPU_GLSL-1.0.2]$ ./helloGPGPU_GLSL_linux
cpu vendor: GenuineIntel
cpu name:        Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz
MMX cpu detected.
SSE cpu detected.
Testing OS support for SSE... yes.
Testing OS support for SSE unmasked exceptions... SIGFPE, yes.
Tests of OS support for SSE passed.
Mesa: Mesa DEBUG build Jul 29 2005 10:03:17
helloGPGPU_GLSL_linux: shader/slang/slang_assemble.c:808: _slang_assemble_operation: Assertion `!"var->initializer, oper_identifier"' failed.
Aborted

And this is exactly what I got in my own application. The failure point was at glCompileShader for my app… exact same line too, 808

(gdb) bt
#0  0xffffe410 in ?? ()
#1  0x44250ec0 in ?? ()
#2  0x00000006 in ?? ()
#3  0x00000e59 in ?? ()
#4  0x40816805 in raise () from /lib/tls/libc.so.6
#5  0x408181e9 in abort () from /lib/tls/libc.so.6
#6  0x4080ff01 in __assert_fail () from /lib/tls/libc.so.6
#7  0x405bacd6 in _slang_assemble_operation (file=0x442511a0, op=0x8609e30, reference=0,
    flow=0x44251190, space=0x44251180, info=0x44251170, stk=0x4425116c)
    at shader/slang/slang_assemble.c:808
#8  0x405c40bd in _slang_aggregate_variable (agg=0x442511f0, spec=0x860a67c, array_size=0x8609e30,
    funcs=0x44251774, structs=0x44251780) at shader/slang/slang_storage.c:195
#9  0x405c21d9 in parse_init_declarator (C=0x442512e0, type=0x44251240, vars=0x44251768,
    structs=0x44251780, funcs=0x44251774) at shader/slang/slang_compile.c:1986
#10 0x405c227c in parse_init_declarator_list (C=0x442512e0, vars=0x44251768, structs=0x44251780,
    funcs=0x44251774) at shader/slang/slang_compile.c:2010
#11 0x405c261b in parse_declaration (C=0x442512e0, scope=0x44251768, structs=0x44251780,
    funcs=0x44251774) at shader/slang/slang_compile.c:2136
#12 0x405c26e8 in parse_translation_unit (C=0x442512e0, unit=0x44251768)
    at shader/slang/slang_compile.c:2167
#13 0x405c27dc in compile_binary (prod=0x4066e8e0 "\002\002\002\001\005\001gl_MaxLights",
    unit=0x44251768, type=slang_unit_fragment_builtin, log=0x442517f0, builtins=0x0)
    at shader/slang/slang_compile.c:2211
#14 0x405c2a4e in _slang_compile (
    source=0x85a2398 "void main(){    gl_FragColor = vec4(0.4,0.4,0.8,1.0);}", unit=0x44251800,
    type=slang_unit_fragment_shader, log=0x442517f0) at shader/slang/slang_compile.c:2311
#15 0x40549932 in _shader_Compile (intf=0x84e0298) at shader/shaderobjects_3dlabs.c:630
#16 0x40547249 in _mesa_CompileShaderARB (shaderObj=1) at shader/shaderobjects.c:229
#17 0x4002584a in GPUShaderPack::InitMeanShader (this=0x84e0200)
    at /home/joe/Sensor3D/src/GPU/GPUShaderPack.cpp:83

My code looks something like this:

    meanFSText = Helper::ReadFile("mean.frag");

    GLint blahlen = strlen(meanFSText);
//     glShaderSourceARB(meanFS, 1, (const GLcharARB**)&meanFSText, (const GLint*)strlen(meanFSText));

    glShaderSourceARB(meanFS, 1, (const GLcharARB**)&meanFSText, &blahlen);

    PrintInfoLog(meanFS);

    cout << "compiling" << endl;
    glCompileShaderARB(meanFS);
    cout << "compiling" << endl;
    meanProg = glCreateProgramObjectARB();
    cout << "compiling" << endl;
    glAttachObjectARB(meanProg, meanFS);

It kinda freezes for 30 secs after coutting the first “compiling” and then dumps an error msg much like the hellow GPGPU one.
On closer inspection, it gives the stack shown above.

The situation is that I’m developing on my laptop, ATI 9000 IGP card.
I’ve recently got Mesa 6.3 working and I’m trying to lay some ground work for some multipass shading.
I had been using freeglut, however, when tyring to compile hello GPGPU, it keeps giving me this

/usr/local/include/GL/glut.h:531: error: `GLAPIENTRY' does not name a type
/usr/local/include/GL/glut.h:539: error: `GLAPIENTRY' does not name a type
/usr/local/include/GL/glut.h:541: error: `GLAPIENTRY' does not name a type
...

so i had to revert back to normal glut (i cheated and only overwrote the header) and it compiled.

I’m at a loss because i don’t know enough to know where the problem is. :frowning:

Mesa doesn’t support GLSL yet.
Even when the GLSL support in Mesa is done that won’t help you with your graphics card since it can’t do any fragment shading, not even GL_ARB_fragment_program.

Philipp

actually mesa does support GL_ARB_fragment_program (and vertex_program) since the mesa demos using the low level shading language actually runs on my laptop. The extensions are there when i do a glxinfo, it’s just that since it’s all in software, it’s only useful for verification purposes :stuck_out_tongue:

About support for GLSL, i’m unclear as to whether it does or not because the extensions are there… but mesa only supports upto gl 1.5, is that a contradiction or am i missing somehting here?

Joe.

GL_ARB_vertex_program in software isn’t that slow, so it’s enabled by default even in the otherwise hardware-accelerated r200 driver. But GL_ARB_fragment_program is not in the driver for your graphics chip. If glxinfo lists GL_ARB_fragment program on your computer that means you’re using the pure software implementation and get no hardware acceleration, not even for the things you graphics chip can do in hardware. Hardware GL_ARB_fragment program is only supported for intel i915 and Radeon 9500 and above by Mesa.
GL_ARB_fragment_shader and GL_ARB_vertex shader are not supported by any variant of Mesa. These are not complete yet.
But someone once forgot an #ifdef, so for some days there was a Mesa version in CVS which would announce these extensions by default. Maybe you got that one.

Philipp

Originally posted by mordrax:
[b]About support for GLSL, i’m unclear as to whether it does or not because the extensions are there… but mesa only supports upto gl 1.5, is that a contradiction or am i missing somehting here?

Joe.[/b]
I think GLSL is under development because there was a discussion here about adding debugging support with another extension.

There is no contradiction. Before GLSL went into core in GL 2.0, it was extensions during the GL 1.5 days and it could even be implemented for older versions as well.

Originally posted by PkK:

GL_ARB_fragment_shader and GL_ARB_vertex shader are not supported by any variant of Mesa. These are not complete yet.
But someone once forgot an #ifdef, so for some days there was a Mesa version in CVS which would announce these extensions by default. Maybe you got that one.
Philipp

Now that would suck :stuck_out_tongue: hehe
I thought they’d announce something that big on their news page. I dled 6.3 just for the fbo but found that it conveniently had fragment/vertex_shaders too.
For the moment functionality is more important than hardware support as i’m only developing on my crappy ati 9000IGP, so as long as the results are the same it doesn’t matter to me whether there’s hardware support.

Thanks for the update guys, i’ve moved on to Cg now and its working fine… slowly…

Joe.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.