Please improve the glSlang spec !

[Jan]

I´ve been working with glSlang ever since ATI released their first drivers with support for it.

All in all, i think it´s quite a nice language, but then having a high-level language is always "quite nice" compared to an assembler-language.

But now i am trying to do a bit more complex stuff than only bumpmapping, and pretty fast i stumbled across annoying limitations of glSlang.

One thing is, that i cannot get the inverse matrix of something (for example the modelview-matrix).

In ARB_fp this is implemented natively, so the data is there anyway, glSlang simply does not give you the ability to access it ! Why is that? glSlang is supposed to be future-proof, but how can it be future-proof, if it doesn´t even expose everything CURRENT hardware is capable of ??

BTW: I tried to compute that inverse by myself, but i get horrible calculation-errors, due to floating point errors (or "double"-point errors )

I know this has been said before, but seeing how slow the ARB works sometimes, they might have forgotten about it already.

And since i am going to buy a Geforce 6 anyway, someday, i wouldn´t mind, if nVidia would add such stuff on their own.

Do i have to go back to ARB_fp now, to get my app running? Seems so. It´s really sad.

Jan.

[Korval]

In ARB_fp this is implemented natively, so the data is there anyway, glSlang simply does not give you the ability to access it ! Why is that? glSlang is supposed to be future-proof, but how can it be future-proof, if it doesn´t even expose everything CURRENT hardware is capable of ??

That's not a hardware feature.

BTW: I tried to compute that inverse by myself, but i get horrible calculation-errors, due to floating point errors

Then you're probably doing it wrong.

[S&W]

Yeah, I have the same thought about that, Jan.

I want GLSL to implement a instruction of the inverse matrix computation too, for example, Projective Texturing or Shadow Mapping.

[Ffelagund]

Hello, I think that is very easy compute the inverse or the traspose of every matrix in the host application, and load it as a uniform, this taked me about 15 minutes, because I haven't the invert rutine coded in my source, and I have no rounding errors caused by floating point, (at least, noticable errors). It would be nice that glsl will provide us a built in uniform that does the inverse/transpose for us, but isn't a hard task do it with our hands

P.S: I'm almost sure that the inverse/transpose calculation isn't done in the gpu.

[Jan]

Originally posted by Korval:

In ARB_fp this is implemented natively, so the data is there anyway, glSlang simply does not give you the ability to access it ! Why is that? glSlang is supposed to be future-proof, but how can it be future-proof, if it doesn´t even expose everything CURRENT hardware is capable of ??

That's not a hardware feature.

Does that change anything ?

Then you're probably doing it wrong.

The only way i know is the Gaussian algorithm. I do it correctly, that´s for sure, but i know that algorithm is not the most stable one.

Wait, i just found something with Kramer´s rule, i´ll have to try that.

Anyway, wouldn´t it be absolutely logical to give the programmer all the data which is available anyway?

The glSlang-spec definitely has to be improved. There are other threads, which adress several other issues. I only wanted to make clear, that there is need for certain functionality and that people are not satisfied with its current state.

I hope the ARB doesn´t see that completely different.

Jan.

[yooyo]

You can use gl_NormalMatrix.

gl_NormalMatrix is mat3 and it's represent as ModelView.Inverse.Transpose.

When you rumbling with a math in vertex shader you will see that gl_NormalMatrix very usefull in computations.

yooyo

[Jan]

Ok, with Kramer´s rule, i get perfect inverse matrices. One problem solved.

Yooyoo, thanks, but i cannot use that matrix, i actually need the Inverse of (Modelview*Projection), which is not available in glSlang.

Anyway, this is not about one specific problems, but about glSlang in general. It´s not perfect (although it´s a very good start already) and everyone should agree on that and try to make it perfect.

Jan.

[Korval]

Does that change anything ?

I was correcting a factual error in your post.

Anyway, wouldn´t it be absolutely logical to give the programmer all the data which is available anyway?

Is it available? How do you know that specific code didn't have to be written for ARB_vp in each implementation to allow for inverse matrices and so forth to be exposed to the user?

The glSlang-spec definitely has to be improved.

This is certainly true. Glslang is not a good shading language. It is adiquate, but not good. Some bad choices were made.

Though I doubt any of them are going to be fixed in the near future.

[plasmonster]

The driver would most certainly need some logic to detect *relevant* changes in the variuos matrices, so it could produce timely inverses, and so on. I doubt that this is a trivial task for the driver to perform.

[yooyo]

Originally posted by Jan:

Yooyoo, thanks, but i cannot use that matrix, i actually need the Inverse of (Modelview*Projection), which is not available in glSlang.

Im not sure, but I try to dump nvoglnt.dll and I found gl_ModelViewProjectionMatrixInverse
string. It seems that nVidia driver expose this matrix in GLSL. I can't check is this true, because I don't have FX based board right now .

Here more strings:
gl_ModelViewMatrixInverse
gl_ProjectionMatrixInverse
gl_ModelViewProjectionMatrixTranspose
gl_ModelViewProjectionMatrixInverse
gl_TextureMatrixInverse

yooyo