PDA

View Full Version : severe ARB_vertex_program problem on ATI



McBain
12-30-2002, 01:28 AM
I have the following severe problem with the ARB_vertex_program on ATI 9700 Pro

When i call a glVertexAttrib*ARB my entire system crashes (hang up, corrupted files, ...).

The program only seems to manifest itselve when two thing happen at the same time:
1) i call glVertexAttrib*ARB in a displaylist
2) i reference generic attributes in my vertex program

* calling glVertexAttrib*ARB(2 with a normal and referencing vertex.normal does not crash my system, but lighting is totally wrong. Lighting is correct with the *same* vp and glNormal*

* the only time glVertexAttrib*ARB( works in a display list is when i use it to program vertex.position, instead of glVertex, but then my framerate drops about 10 times (1500 -> 120 fps).

because i need to pass a local frame instead of a vector (normal, binormal and tangent) i need the glVertexAttrib*ARB. tangent and binormal should arrive in registers 6 and 7, and there is no other way to get something in there.

i experienced this problem with different drivers

although i have over one year experience with vertex programs (NV_vertex_program) i have never experienced problems like this one.

I would very much appreciate any kind of help

best regards
McBain

Licu
12-30-2002, 02:19 AM
I have same problems with vertex attributes in display list but on Radeon 8500. The program locked. I suspected that the extension was implemented in software and have something to do with the compilation on the display list. Anyway, strange thing, in Catalyst < 3 the extension was reported to run in software for r200, but with the new Catalyst 3 there seems to indicate native implementation.

Didn't tried on a vertex array objects. It's there possible to update ARB vertex program generic attributes in a VAO ?

zed
12-30-2002, 07:36 AM
honestly i havnt looked at vertex_program
but certain things aiont allowed (perhaps they will work though) in DL's.
vertex array points etc perhaps setting vertex_program data is anther thing not allowed

bashbaug
12-30-2002, 12:57 PM
Originally posted by McBain:
* calling glVertexAttrib*ARB(2 with a normal and referencing vertex.normal does not crash my system, but lighting is totally wrong. Lighting is correct with the *same* vp and glNormal*

* the only time glVertexAttrib*ARB( works in a display list is when i use it to program vertex.position, instead of glVertex, but then my framerate drops about 10 times (1500 -> 120 fps).

because i need to pass a local frame instead of a vector (normal, binormal and tangent) i need the glVertexAttrib*ARB. tangent and binormal should arrive in registers 6 and 7, and there is no other way to get something in there.


What you're trying to do should work. You should be able to put any of the VertexAttrib calls in a display list.

A couple of quick comments though. First, calling VertexAttrib(2, ...) is not the same as calling Normal(). Setting vertex attrib 2 leaves contents of the normal undefined. On some implementations this means that the normal gets the value of vertex attrib 2, while on others, the normal is left alone. I suspect that in the experiment where the lighting was messed up you were expecting the first type of behavior but were getting the second.

The one exception to the rule that the 'generic' vertex attribs leave the corrosponding conventional attribute undefined is that vertex attrib 0 is the same as the vertex position. If you think about this it kind of makes sense, since otherwise it's impossible to guarantee that you'll provoke a vertex using only the 'generic' vertex attribs. I can't explain the drop in FPS when using vertex attrib 0, but at least this explains the behavior you're seeing.

To work around the problem in the short term, can you pass in the tangent and binormal as unused texture coordinates?

McBain
12-30-2002, 01:09 PM
i know calling VertexAttrib(2, ...) is not the same as calling Normal(). I changed the vertex program accordingly, but it still went crazy.

(BTW, i think with NV hardware it will have the same effect).

in the meantime, im pretty sure it is a driver bug

(see thread http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008361.html)