I’ve got a program that crashes on glCompileShaderARB. The problem seems to be related to the use of gl_TexCoord in a GLSL fragment shader. I’ve reduced it to the following minimal example:
This crashes on my Mac Mini. It does not crash on any other computer I’ve tried, but I’ve only tried one other computer. The Mac Mini has OS X 10.3.8 installed, and identifies its video card as ATY,RV280, vendor ATI. This looks like a driver bug to me, although I don’t want to rule out other possibilities.
Questions: Can anybody confirm this bug? How widespread is it? Are there any known workarounds?
Upgrading my hardware isn’t really a solution, since other people will still be running on old hardware. BTW, my Mac Mini might be very low end crap, but it isn’t actually more than a couple of months old.
Actually my program runs fine on most OpenGL cards, including very old cards. I use GLEW_ARB_fragment_shader to detect if GLSL fragment shaders are supported, use a fragment shader if available, and use a workaround if not. My Mac Mini reports that GLSL fragment shaders are supported.
If the RV280 erronously claims to support fragment shaders, then I have the following options:
[ul][li]Never use fragment shaders and always use the workaround.[]Try to somehow detect if the hardware erronously claims to support GLSL fragment shaders.[]Leave the decision up to the user.[*]Fail to run on hardware that erronously claims to support GLSL shaders.[/ul][/li]None of these options seem very attractive to me.
The current release of Mac OS X doesn’t really support GLSL on any card (any your specifically will never run ARB_fragment_shader in hardware) but does advertise most of the GLSL extensions, which the exception of GL_ARB_shading_language_100.
They support the GLSL API, but the actual shader compiler isn’t in there.