I have a Compaq V6103EA laptop with an Intel GMA 950 graphics card. Its running Ubuntu 8.10, with the “xserver-xorg-video-intel” driver package and the mesa3d implementation.

I’ve been doing some OpenGL programming, and up until now, everything has worked very well. Currently I’ve been trying to learn a bit of GLSL, mainly by studying a source I got hold of. Here is a couple of issues have appeared:

When I compiled and executed the the code (which was originally written for windows/VC++), first I got a segfault at a call to glCreateShaderObject. I spend a long time trying to figure out what was wrong with the call, until I found something regarding the tests of GLEW_ARB_fragment_shader and GLEW_ARB_vertex_shader respectively. I tried changing them to GL_ARB_… , and then I the test failed. What does all of this mean? Which is the right one? And do I have capabilities of using these or not?

I not, as far as I know, this can have a couple of different reasons:

my graphics card doesn’t support it

my graphics card driver doesn’t support it

my opengl implementation (mesa) doesn’t support it.

How can I tell which?

I know from this table, that my graphics card supports vertex/fragment shaders, so 1. shouldn’t be the problem. And according to the official mesa website, the 7.x version implements OpenGL 2.1 which includes GLSL.

So how can I go about finding out what is causing my problem?
I’ll happily supply you with additional information.

Thanks!

I also forgot to show you this. It’s the output of glxinfo. I think something seems strange with the OpenGL Version String (1.4 ?).

To run GLSL you need the GL_ARB_shading_language_100 extension.
It does not looks like it is exposed by your card+driver.
I am not sure what are the best Intel drivers to use on Linux.
Maybe someone more used to Intel can help ?

GLSL in Mesa is actually not there yet, even though your Intel GPU exposes SM 3.0, you’ll not be able to use GLSL then. The DRI driver you’re using might give you access to the GL_ARB_fragment_program extension so that you can write pixel shaders using a set of low level assembly instructions. Seeing that in D3D10 assembly shaders have been removed, that really sounds a bit rough nowadays, but it’s still currently the only solution to ship software that works almost everywhere on Linux.

That document is nearly two years old. It does not represent the current state of Mesa. I’m too lazy to completly check the current situation with Mesa, but this is the first example I found:

The document you linked to lists, among others:

The inverse trig functions asin(), acos(), and atan() are not implemented
Three month after that document was written Mesa 7.0 was released, which does support these functions. From the release notes:
Implemented GLSL asin(), acos(), atan() functions.

GLSL in Mesa is actually not there yet, even though your Intel GPU exposes SM 3.0, you’ll not be able to use GLSL then. The DRI driver you’re using might give you access to the GL_ARB_fragment_program extension so that you can write pixel shaders using a set of low level assembly instructions. Seeing that in D3D10 assembly shaders have been removed, that really sounds a bit rough nowadays, but it’s still currently the only solution to ship software that works almost everywhere on Linux.

To see it seems it’s just the other way round: GLSL in Mesa is there (and works on newer hardware like the GMA965), but the GMA950 hardware does not support SM 3.0, only SM 2.0. There’s an Intel hardware comparison chart in the article at http://en.wikipedia.org/wiki/Intel_GMA

GSL has control structures like if/else for, etc. AFAIK SM3 added branch instructions which are needed for such control structures. OR in the words of the main Mesa developer, as posted on a Mesa mailing list: “The 945 hardware does not support loops/conditionals/etc which are needed for fragment shaders.”