PDA

View Full Version : glPush/PopName and GLSL



DarkProphet
07-19-2006, 07:59 AM
Hi all,
I realised that the selection stack isnt accessible from shaders and im wondering why that is? The only solution I can think of is that the name stack is implemented on the software/driver side and not in HW; But the specification say that glPushName/glPopName are valid operations while creating a display list, and display lists (most of the time) get shoved into vram. So unless the driver filters the operations out and does some trickery with the selection matrix, why can't I access them from shaders?

Regards,
DarkProphet

Relic
07-19-2006, 09:17 AM
Selection is done with SW processing normally.

Why would you need the name inside the shader?
You can also write into a uniform if you need per object data in a shader.

DarkProphet
07-19-2006, 09:39 AM
Yes, i could use uniforms; but grouping entire objects under 1 name would have been ideal...

Software processing or not, it should be accessible in shaders as its a property of an object. Whether its in SW or HW is an implementation detail IMHO.

Regards,
DarkProphet

Relic
07-19-2006, 09:58 AM
Originally posted by DarkProphet:
Yes, i could use uniforms; but grouping entire objects under 1 name would have been ideal...
What keeps you from doing that? It's just a matter of when you set the uniform. It's at the same place where you would have loaded your name. If you need a stack for that, build your own.



Software processing or not, it should be accessible in shaders as its a property of an object. Whether its in SW or HW is an implementation detail IMHO.Shaders work on vertices and fragments, not objects.
You expressed that you want more OpenGL state accessible inside the shader. So far for all state which is not, the answer was to put it into uniforms or attributes.

DarkProphet
07-19-2006, 10:13 AM
I do realise I can do it as a uniform; that wasn't the question. The question was why wasn't it available in GLSL?



Shaders work on vertices and fragments, not objects.
<sarcasm>You dont say! I must be too dumb to realise that...</sarcasm>

Yes, but each vertex/fragment belong to an object, therefore each vertex shader should have its object values available to it.

Regards,
DarkProphet

Overmind
07-19-2006, 01:21 PM
It's not available in GLSL because you can archieve the same effect with uniforms and/or attributes.

It's not entirely true that vertices and fragments belong to an object. Strictly speaking, there are no objects. You only have a "current" name on the name stack, and when something is rendered this name is recorded along with minimum and maximum z.

The current name stack content is just another GL state, nothing more, nothing less. There is no particular reason why this state should be made available in GLSL. Especially there is nothing that can be done with this functionality that can't be done equally simple with uniforms.

Korval
07-19-2006, 06:17 PM
It's not available in GLSL because you can archieve the same effect with uniforms and/or attributes.To be fair, you can achieve a lot of things with uniforms/attributes without any state mirroring in glslang. There's no specific need to have light state, material state, or matrix state be mirrored in glslang; the user can do the mirroring on their own.

So I can't say that this is a compelling argument against mirroring this name stack in glslang.

Mroe than likely, they just forgot about it. It's not like you see extensions that deal with selection much. And since nobody would dare use shaders and selection at the same time, it became irrelevant.

DarkProphet
07-20-2006, 04:47 AM
I agree with Korval, just because it can be done through uniforms and/or attributes, doesn't mean that it doesn't need an official reserved keyword for it to indicate its a valid state available in GLSL.

Do you honestly think that "we forgot" is a valid excuse for not integrating this feature? From what I have understood, GLSL is meant to be able to access most things that are available to the fixed functionality pipe, but that doesnt' seem to be the case.

Why wouldn't anybody dare to use selection and shaders at the same time? I dont see a correlation...

Regards,
DarkProphet

Relic
07-20-2006, 06:01 AM
Because OpenGL implementations normally don't offer hardware accelerated selection and emulating vertex shader transformations to calculate the selection result doesn't make it faster. Give it a try.
Even worse if the input geometry data is stored inside the video memory.
For most uses there are faster ways to do selection higher up in the scene representation.

V-man
07-20-2006, 07:22 AM
Why wouldn't anybody dare to use selection and shaders at the same time? I dont see a correlation...The question is, what is the fastest solution for your app?

For GL, the question is, does this belong in a 3D API?
For GL ES, they canned it.
For "Next OpenGL", they want to place it in the dark corner
http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233

mrbill
07-20-2006, 07:52 AM
Nobody "forgot." This isn't even a close or arguable call.

The fixed-function state available to the GLSL is the state that GLSL *subsumes*. See section 7.5 of the language spec.

The GLSL vertex shader and fragment shader do not *subsume* selection. So you don't get access to the bottom of the selection name stack. Just like you don't get access to the display LIST_BASE. (Just an example of fixed-function state pulled out of a hat at random.)

Note - OpenGL ES 2.0 has a very elegant solution to what fixed-function state to provide to GLSL. It doesn't provide *any* fixed-function state.

If you want a "selection name" accessable to your shader, *you* should send it as an attribute or uniform yourself.

-mr. bill

DarkProphet
07-20-2006, 09:05 AM
Good point mr.bill :)

Korval
07-20-2006, 12:16 PM
Why wouldn't anybody dare to use selection and shaders at the same time?Because OpenGL selection, as a feature, is a bad idea. Using it at all is dubious, but doing so with shaders (and VBOs) is just not wise.


The fixed-function state available to the GLSL is the state that GLSL *subsumes*. See section 7.5 of the language spec.We don't need you and your wicked spec reading here. We'll do just fine with wild speculation. ;)

Relic
07-21-2006, 12:59 AM
ROFL! That cracked me up. :D
Now I have to remember that all the times I cite the specs...

mrbill
07-21-2006, 09:38 AM
Originally posted by Korval:
We don't need you and your wicked spec reading here. We'll do just fine with wild speculation. ;) That would be me and my wicked spec writing.
(7.3 & 7.4 of the spec, and a few other sections.)

[insert smiley face here]

-mr. bill