PDA

View Full Version : Vertex program & p-buffer



Joel
07-15-2002, 08:03 AM
Hi,

i just ran into problems when trying to use vertex programs while rendering into a p-buffer.
With a GeForce4 4400 all that should be rendered with the vertex program enabled aren't rendered at all.
With a Radeon 8500 (last drivers) my app simply crashes in atioglxx.dll

Of course i've called wglShareList...
The rendering to the p-buffer works when no vertex program is used and the vertex programs work when not rendering to p-buffer.

Do you have any ideas of what i could be missing ?
Or has anyone encountered the same problem ?

Joel.

PH
07-15-2002, 08:08 AM
The Radeon 8500 drivers don't implement the NV_vertex_program extension. You should use EXT_vertex_shader on the Radeon.

Joel
07-15-2002, 08:48 AM
Originally posted by PH:
The Radeon 8500 drivers don't implement the NV_vertex_program extension. You should use EXT_vertex_shader on the Radeon.


I know that ATI doesn't use NV_vertex_program, I was just too lazy to make the difference between nVidia vertex program and ATI vertex shader as for me they are quite the same (in functionnality).
So i use EXT_vertex_shader on the radeon.

Both cards work well when not rendering into a p-buffer. My only thought for now is that in some way the problem comes from the different openGL contexts.

I just thought that someone else must have already rendered into a p-buffer while using vertex program to make sure that i've done something wrong... and by the way if this person has met the same problem and could help me i would be really pleased http://www.opengl.org/discussion_boards/ubb/wink.gif

I don't see anything else that a problem with the different openGL context.
I know ATI drivers aren't the best but a crash makes me think that i must be guilty in some way http://www.opengl.org/discussion_boards/ubb/wink.gif

Joel.

PH
07-15-2002, 09:05 AM
I've used NV_vertex_program's on GeForce3 while rendering into pbuffers without problems. I haven't tried on the Radeon 8500 ( with EXT_vertex_shader that is http://www.opengl.org/discussion_boards/ubb/smile.gif ).

But, I've had lots of problems with pbuffers on both cards. In my case it was related to some pbuffer implementation differences in the drivers. There has been a few discussion on this on the board ( well, I at least posted some differences between NVIDIAs and ATIs implementations http://www.opengl.org/discussion_boards/ubb/smile.gif ), but none of the driver writers responded.

Anyway, in my case it wasn't just related to vertex programs but something else ( that I don't remember, sorry ).

There are several pbuffer demos from various people that work on NV hardware and fail on ATI hardware ( and vice versa ). So it might not be your fault alone.

Joel
07-16-2002, 03:49 AM
I finally found where the problem comes from. It was just that i didn't set the program registers correctly for all the openGL contexts created. It was only set for the current one. The modelview and projection matrices weren't tracked in the other context.
But i've still got a problem remaining with the ATI's vertex shader. As the parameters are defined at the vertex shader creation I don't know how to initialize them.



modelview = glBindParameterEXT( GL_MODELVIEW_MATRIX);
projection = glBindParameterEXT( GL_PROJECTION_MATRIX);
[...]
glShaderOp2EXT( GL_OP_MULTIPLY_MATRIX_EXT, eyeVertex, modelview, vertex );
glShaderOp2EXT( GL_OP_MULTIPLY_MATRIX_EXT, GL_OUTPUT_VERTEX_EXT, projection, eyeVertex );


How can i make these variables valid through all contexts ? As i can't do :



glTrackMatrixNV(GL_VERTEX_PROGRAM_NV, 0, GL_MODELVIEW_PROJECTION_NV, GL_IDENTITY_NV);


I'll make myself more clear :
with nVidia i have control on which register i use to do what i want, but with ATI it is hidden by the way we declare variables. So i can't (don't know how http://www.opengl.org/discussion_boards/ubb/wink.gif to specify these variables elsewhere than at the vertex shader creation.

My only thought for now is to create a vertex shader for all contexts !!!!
As i don't want to do this, i'm opened to all suggestions.

Thanks for yours replies so far.

Joel.

PH
07-16-2002, 08:24 AM
The state is contained within the symbols. Changing the contents of a symbol affects the state of the symbol for the currently bound shader.

In the case of glBindParameterEXT( GL_MODELVIEW_MATRIX ), the state of the symbol is automatically updated as you know. The name is confusing - I think glBindParameterEXT is meant to be interpreted as generating a binding between a symbol and a state ( as opposed to _changing_ a state ).

This is my interpretation of the spec and may of course be incorrect http://www.opengl.org/discussion_boards/ubb/smile.gif.

Joel
07-16-2002, 10:43 PM
Originally posted by PH:

The state is contained within the symbols. Changing the contents of a symbol affects the state of the symbol for the currently bound shader.

In the case of glBindParameterEXT( GL_MODELVIEW_MATRIX ), the state of the symbol is automatically updated as you know. The name is confusing - I think glBindParameterEXT is meant to be interpreted as generating a binding between a symbol and a state ( as opposed to _changing_ a state ).

This is my interpretation of the spec and may of course be incorrect http://www.opengl.org/discussion_boards/ubb/smile.gif.

I hope you're not, cause that's my interpretation too http://www.opengl.org/discussion_boards/ubb/wink.gif
My problem is that when creating a new context, even though the vertex program (or shader) is shared, the registers are not. It is not big problem with a GeForce as we can access these registers directly.
My opinion is that when creating a new context with a Radeon, the registers aren't shared neither AND that the binding between the registers and (e.g.) the model view matrix is no longer valid.

That looks like an ATI bug to me as the nVidia code path is working correctly. Either I'm doing something wrong with vertex shaders or not I think a crash in the ATI dll is not meant to make me belief in the stability of their drivers.

I find quite strange that registers aren't shared between openGL contexts as it don't match the way i thought it could be done in hardware but that's the way it behaves...

If someone with a Radeon 8500 could only tell me that he has succedeed in sharing vetex shaders between different openGL contexts that will prove that the man with little-faith i am is blaming ATI wrongly http://www.opengl.org/discussion_boards/ubb/wink.gif
And BTW if he could send me an example http://www.opengl.org/discussion_boards/ubb/smile.gif

Thanks PH for your answers.
Don't you think it's strange that the registers aren't shared within all contexts ?

// edit : i forgot to tell that pbuffer aren't the cause of this problem as i encounter the same when creating another "standard" openGL window, it's just new contexts....

[This message has been edited by Joel (edited 07-17-2002).]

PH
07-17-2002, 09:19 AM
I did a few tests and I get a crash too. I'm not convinced that even the shader object is shared between contexts ( since it isn't mentioned in the EXT_vertex_shader spec, like it is in the NV_vertex_program spec ).

Korval
07-17-2002, 09:42 AM
since it isn't mentioned in the EXT_vertex_shader spec, like it is in the NV_vertex_program spec

If they don't explicitly say that it is shared, then it almost certainly isn't.

Joel
07-17-2002, 12:42 PM
Ok, thanks for your help.
I think that nVidia should add "We can share our vertex programs" in their spec. http://www.opengl.org/discussion_boards/ubb/smile.gif

So i'm bound to upload the vertex shader for all contexts. Sounds boring...
I definitively prefer nVidia cards http://www.opengl.org/discussion_boards/ubb/wink.gif
I hope i'll live until I see a ATI driver that doesn't crash in their own DLL, that will mean i've got a long life ahead of me http://www.opengl.org/discussion_boards/ubb/wink.gif

About the fact that the program parameters (c[XX]) seem not shared between contexts maybe the parameters are but the tracking of the matrix is not.
I'll make a few tests tomorrow when i'll be back to work and post what i've found in case some could be interested.

Thanks again.

Joel.

jwatte
07-17-2002, 05:14 PM
You can re-use a HGLRC with different HDCs so you don't have to share/re-do objects. As long as the DC and the HGLRC are "compatible". Pbuffers make pretty good use of this.

Joel
07-17-2002, 10:40 PM
Originally posted by jwatte:
You can re-use a HGLRC with different HDCs so you don't have to share/re-do objects. As long as the DC and the HGLRC are "compatible". Pbuffers make pretty good use of this.

That's a good idea. Unfortunately I'm using a engine made by our enterprise... I'll have to look how to change the managing of our windows, sounds less painfull than monitoring if a new context has been created.

For those who are interested, the program parameters are _not_ shared between contexts. I made a test with a parameter that is constant and for the new context it contains [0 0 0 0] as the spec says for an un-initialized register.

After a re-read of the spec that's how it is supposed to work :


The program parameter registers are shared to all vertex program invocations within a rendering context


I thank you all.