inverse and transpose of matrices in glSlang state

in this topic this issue is discussed: http://www.3dlabs.com/support/forum/thread.jsp?forum=32&thread=4419&tstart=0&trange=15

in scene graph libraries state tracking can be a real pain so a uniform state var would be very productive like in the ARPFP1 extension.

I do ofcourse concur to that
I also want to add some way to find out if an uniform is a sampler or a normal ordinal.

the ’ glGetActiveUniform’ returns GL_INT as type for a sampler2D, and there is as far as i know no specification or constant that applies in this case.

Also the whole structure/array stuff i pretty strange since you get every single ‘case’ back instead of the real types. This should be redesigned. A structure should get one description and an id, and the getActive… should return that ID as the type, and arrays should only occur once ( even if they are structs ). Or remove the whole own struct thing, since its doesnt help as it is now.

(or ive missed something when i tried glslang ut)

Yeah, why not returning GL_SAMPLER1D_ARB, GL_SAMPLER2D_ARB, … in glGetActiveUniform*() for 1D-, 2D-, … Samplers? Why using an INT?

Originally posted by Hampel:
Yeah, why not returning GL_SAMPLER1D_ARB, GL_SAMPLER2D_ARB, … in glGetActiveUniform*() for 1D-, 2D-, … Samplers? Why using an INT?

Because the names should be GL_SAMPLER_1D_ARB, GL_SAMPLER_2D_ARB, … in glGetActiveUniform* for 1D-, 2D, … samplers. [insert smiley face]

This small change is strongly under condsideration, but please be slightly patient while the change is made and documented.

Heads up - for the applications using glGetActiveAttributesARB, active samplers may return something other than GL_INT.

-mr. bill

How did glslang make it out of committee with errors like this in it? No matrix inverse/transpose/inverse-transpose. No separate enums for sampler types. Obvious things like this that clearly ought to have been in the spec from the beginning.

What were you guys doing all that time? Debating whether or not glslang should mandate framebuffer access?

When will these changes goes public? What other changes will there be?
Are there any ideas on extending GLslang for framebuffer access and matrix stages?

I do agree on that such errors shouldnt have been in the spec when it became final… I also think that the ARBgroup listens to little to the users of the APIs they are building.

releasing beta of the specifications and put up (moderated) discussions here should give better input, and hopefully dont slow down the work to much.

Lastest example - the Superbuffers… there was some small preview examples of the interface, but thats all. If we could have a look at the drafts we might add something ( us, the users that is). Many people here adopts the latest stuff much faster than the average gamedeveloper… they have their titles to work on and will look into new techniques when a new title starts, not before that.

The superbuffers prelimiary spec talked about ANOTHER way of binding vertexdata. Whats wrong with the current VBO bindings, and why cant superbuffer memory be used as VBO memory? I thought the opengl 2.0 draft that 3dlabs wrote was there to unify the handleing of data, not give 3-4 different ways to handle each thing ( like textures that are handled different if they are a superbuffer or a texture, or can you skip the normal texures and just go for superbuffers as textures with some flags for if it should be updateable or not?)

Let us in on the plans NOW, not when its to late.

Whats wrong with the current VBO bindings, and why cant superbuffer memory be used as VBO memory?

Effectively, the likely reason behind that was because VBO was still an extension at the time. In general, having two extensions rely on each other isn’t the best way to handle things, unless you have no choice. With VBO’s current inclusion into the 1.5 core, this problem disappears.

I thought the opengl 2.0 draft that 3dlabs wrote was there to unify the handleing of data, not give 3-4 different ways to handle each thing

Superbuffers isn’t OpenGL 2.0. VBO wasn’t either.

Yet another reason why there won’t be a GL 2.0. At least, not in a totally-new-API kind of way.

Let us in on the plans NOW, not when its to late.

I agree with the idea that the OpenGL public should see various parts of a specification in progress and be able to comment on them.

Base an extension uppon another has happend before, and they was pretty sure that they should promote it to the core very early.

and i do know that the way the VBO and superbuffers looks right now isnt exacly what the ogl2.0 draft was, and the chance that we see that progress in those papers are very slim, but unified buffers where proposed, and supebuffers are the ‘new’ way of handeling that. What i dont understand is why we cant get a uniformed way of dealing with example textures if we use them as rendertarget or not, and it would be nice to hear from the arb members about their thoughts about that ( maybe its not doable in current HW and they want to delay that kind of things, or they havent thought about it, what do we know?)

The problem is that we discuss this amongst ourself and get very little information from the ARGB so we just throw guesses at eachother and hope that we’re right. The real ‘source’ in this case isnt as visible as i would like to. They do a nice job, but somtimes they should get external impressions as well. And what about the meetingnotes… the septembernote took what? 6 month to publish?

What i dont understand is why we cant get a uniformed way of dealing with example textures if we use them as rendertarget or not

If you’re talking about basic render-to-texture functionality, we have that: ARB_Render_Texture.

If you’re talking about why superbuffers takes so long, that’s a different issue. That’s one of the failings of rule-by-committee: it takes a long time to do anything.

I am talking about the superbuffer, but the question is not why it takes so long time. If you look the information that they shown at various conferances you see that they introduce a completely new way of dealing with memory buffers, but that it looks like they only think about ‘new’ stuff. To include the old texturehandling as well, like bind the buffermemory and then do a teximage2d and that texture will be bound to that memory, and that you can bind that memory as an array later if you want to should be nice to have… a uniform way of dealing with all this. Not having one set of texture commands for superbuffers and another set for ‘static’ textures.

But as I said before, we can pass ideas/questions back and forth how much we want, if non of the ARB members looks at this and actually answers we are going nowhere

( or maybe you are a ARB member, in that case im sorry for the ‘arb not listens’ part of my messages)

If you look the information that they shown at various conferances you see that they introduce a completely new way of dealing with memory buffers, but that it looks like they only think about ‘new’ stuff. To include the old texturehandling as well, like bind the buffermemory and then do a teximage2d and that texture will be bound to that memory, and that you can bind that memory as an array later if you want to should be nice to have…

That’s what the API looks like. The original paper let’s you bind memory to the currently active texture, and thereafter all texturing calls refer to that piece of memory.

Though I recently looked at the presentation. They said at the end “Getting close”. This was at GDC last year. Clearly, not close enough