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 ?
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
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
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 ).
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 ), 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.
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.
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 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.
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 .
Originally posted by PH:
[b]
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 .[/b]
I hope you’re not, cause that’s my interpretation too
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
And BTW if he could send me an example
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).]
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 ).
Ok, thanks for your help.
I think that nVidia should add “We can share our vertex programs” in their spec.
So i’m bound to upload the vertex shader for all contexts. Sounds boring…
I definitively prefer nVidia cards
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
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.
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.
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
).