Crash with OPTION ARB_position_invariant in OpenGL?

Try with a Powerbook G4 17" with GF4 MX
ARB_vertex_program is supported as emulation.

Load OpenGL Shader Builder

Type this code:

!!ARBvp1.0 OPTION ARB_position_invariant;

The application crashes. In fact. All application using it will crash.

Can someone can try the same thing, in order to verify ?

Errm, even Doom 3 is using OPTION ARB_position_invariant, very useful.

(i’ve sent to opengl at apple dot com, hoping they will fixes that bug).

Doesn’t crash here on Radeon9600 under 10.3.5, and I’ve used it in my VP experiments OK. What version OS are you on?

I’m still a VP/FP newbie, but I don’t think that is a correct vertex program; the vertex output color is undefined. The default VP is:


ATTRIB vertexPosition = vertex.position;
OUTPUT outputPosition = result.position;

Transform the vertex by the modelview/projection matrix

DP4 outputPosition.x, state.matrix.mvp.row[0], vertexPosition;
DP4 outputPosition.y, state.matrix.mvp.row[1], vertexPosition;
DP4 outputPosition.z, state.matrix.mvp.row[2], vertexPosition;
DP4 outputPosition.w, state.matrix.mvp.row[3], vertexPosition;

Pass the color and texture coordinate through

MOV result.color, vertex.color;
MOV result.texcoord, vertex.texcoord;


ARB_position_invariant passes the vertex position through to be transformed by the fixedfunc pipeline. And you can get rid of the texture output if you’ve got texturing disabled. So that means the minimum program looks like:

!!ARBvp1.0 OPTION ARB_position_invariant;

MOV result.color, vertex.color;


I think the rule is, you are required to output any vertex attribute that is enabled in the pipeline. I.e. color, texture, fog, normal…

(Keith please jump in and correct me if I’m wrong…)

It shouldn’t crash, though… :stuck_out_tongue:

Issues of program eligibility aside, this is broken. On Mac OS X 10.3.5, use of OPTION ARB_position_invariant within a software vertex program crashes the calling application.

I’ve confirmed that this is not broken on 10.3.5’s Radeon 9000 hardware renderer.

I’ve confirmed that this is not broken on Mac OS X 10.2.8.

<rant>Not that I expect any more from Apple these days… the number of bugs I’ve submitted to them about OPTION ARB_position_invariant (and many other parts of ARB_vertex_program) in various circumstances, it’s clear that this is simply another thing they don’t bother to test.</rant>

Make a bug report. If you’re lucky, it might still get fixed for 10.3.6.

I’m using OS 10.3.5 with all the updates, and it’s a ‘Geforce 4Mx’. So, yes it using software processing.

I’ve forwarded this to opengl at apple dot com and forwarded the crash to apple.


!!ARBvp1.0 OPTION ARB_position_invariant;

MOV result.color, vertex.color;



Crash as well. In fact without MOV result.color is valid. Just try in OpenGL Shader Builder.

When it find option arb_position_invariant, it just dies.

I will just do a wrapper that will replace ARB_position_invariant by the 4 ‘dp4’ when it is using the sw vertex program (it’s easy to detect in fact).

Yes i’ve also notice other bugs like that, like the fog coordinate, whatever value you set, it doesn’t work, you have to write a fragment program in order to use it.

Not very nice when fragment program is not available.

Tried with MacOS 10.3.6 and it works. They fixed the thing !
Nice :wink:

Tried with MacOS 10.4, and it’s broken again :frowning: . Now, it simply renders nothing.

Same code, using OpenGL Shader Builder on a Geforce 4MX. I think it’s also reproducible with the ‘Apple Software Renderer’

Can someone confirm this ?

This is just absurd… the number of bugs I’ve filed against it, you’d think they’d have an automated test for it by now.

Yes, my workaround is to put hack my ‘wrapper’ that detects the ARB_Position_Invariant and replace by a vertex * mvp.

Else it is now a Radar bug #4110056.

Btw, did you reproduced that bug ? At least when using the Apple Software Renderer ?

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