This week end, I still found some bugs in the ‘Software’ or ‘Hardware’ ARB_vertex_program implementation.
I’ve searched a bit the mailing list and here what I found:
Thoses bugs might be fixed by now, but if someone can have a more complete list.
My idea is to write a function that get an known valid ARB vertex program and ‘patches’ it in order to make the shader works.
For example, if it find an ‘ARB_position_invariant’, replaces by 4 DP4, if it find an MAD, replaces by a MUL + ADD on Geforce4, etc…
Actually even in 10.3.6, I’ve got some situation like when I uses vertex program, geometry is rendered everywhere. I’m pretty sure it came from the vertex program because slightly modify it, ‘fixes’ it.
Without trolling, I understand why GLSL is not yet out, even they are not still able to make the ARB_vertex_program works correctly.
Here a small list, if anyone can post more information, in order to have in this thread the complete list of known bugs of ARB_vertex_program on MacOS X.
First, ARB_vertex_program on a Radeon 9000 is broken beyond belief. A simple pass-through type shader (below) produced geometry everywhere. I gave up with this hardware pretty quickly.
MOV result.color, vertex.color;
(bug ID 3092875)
Second, the MAD instruction on the GeForce4Ti is broken. Replacing it with a MUL and an ADD works fine, as long as you don’t need the extra instruction space for anything.
(bug ID 3093026)
Third, on a GeForce4Ti, certain vertex programs are capable of changing internal state such that subsequent programs do not behave correctly, or as they would in isolation. I’ve had much less success putting my finger on precisely what’s going on here, but it appears that accessing certain pieces of OpenGL state can cause this. The program causing the problem does not always show incorrect behavior.
(bug ID 3093442)