Complains regarding GLSL limitations

Hi,

I have been going through different threads and seeing a lot of people complain about GLSLs limitations but none of the threads actually mention these limitations. I would like you all to share what you feel are the limitations of GLSL so we can identify what are genuine limitations and do something about them. Please be a little more descriptive in your posts so we can understand clearly what is the issue and what can be done about it, if it’s an issue for most of the people or anly a few, How do other languages (CG,HLSL) handle that issue.

Thanks,
Fastian

The only GLSL limitations I’ve seen discussed are the following:

  • Lack of an extension mechanism (which people are working on).
  • Lack of type casting (complicates compiler interpretation, though most common usages are supported, e.g. vector*float).
  • Lack of transpose operation (isn’t needed for vector with matrix stuff, but could be for other things… not really that big a deal).
  • The global main shader organization vs. D3D effect organization. It makes things that effects provide harder… backward compatibility, fallback mechanisms… also can be solved to some extend my making your own management system.
  • There was something mentioned about dealing with texture units rather than objects, or visa versa (I don’t remember).

See the recent arb notes for other things being discussed integrated (e.g. draw_buffers).

Personally, my biggest beef is the current lack of extension stuff and that I prefer the D3D paradigm (though effects certainly leave things to desire). All in all there certainly is many things that would be nice, but people seem to be noticing many of them :wink: .

Also the lack of built-in transpose/inverse matrix types was discussed here. But I also like to see non-built-in transpose/inverse matrices. For example:

uniform mat4 my_matrix;

my_vec = my_matrix.inverse * gl_Vertex;

Or something like that. This would REALLY be cool!

[EDIT]
Another thing what I’d like to have is more information about textures for example texture sizes like:

uniform sampler2D my_texture;

float TexelSizeX = 1.0 / my_texture.size_x;
float TexelSizeY = 1.0 / my_texture.size_y;

Add something like dot2 and dot3 so that one doesn’t have to construct a vec4 to vec3 just to do a dot3.

Originally posted by KRONOS:
Add something like dot2 and dot3 so that one doesn’t have to construct a vec4 to vec3 just to do a dot3.
Actually you can do that by using swizzling:

vec4 a;
vec4 b;

float c = a.xyz * b.xyz;

This will do a dot3, instead of a dot4.

Jan.

I miss ARB_vp´s ability to access Modelview, ModelviewProjection and their inversed/transposed counterparts. Also, I´d like to be able to share some uniforms between different GLSL program objects (ARB_vp called that program environment variables). I currently abuse some unused OpenGL state variables (like texgen planes) for that, which doesn´t feel very well.

Maybe a set of predefined sampler uniforms. Like gl_Texture0, gl_Texture1…

Its a bit annoying to have to send down a uniform when you know you just want whats in the second texture unit.

This way shaders are also more portable, the program dosen’t need to know the name for the uniforms.

> Maybe a set of predefined sampler uniforms. Like gl_Texture0, gl_Texture1…

Hmmm… I like this one :slight_smile:
Each could be declined _2D, _Rect, _3D, etc.

They could simply add inverse() and transpose(= functions. The driver will then detect if the oparand matrix is a buil-in one and accordingly precompute the co-matrices
I think is more elegant then M.inverse or so on.

Yes, the concept of preshaders is interesting (next version upgrade for the effect system in DX this summer). Basically just removing all invariant expressions from a shader would be great.

It also could lead to better state transmission. If GL could keep track of all the dependencies and state changes logged and transmit all change information on an UpdateState call or something (also in next DX update), it could be a lot more pipelined (who knows, perhaps that’s how the drivers do it already :stuck_out_tongue: ).

Oops, kind of off topic… this certainly isn’t a complaint about OpenGL, but it would be cool :slight_smile: .

Originally posted by Plasma8:
[b]Maybe a set of predefined sampler uniforms. Like gl_Texture0, gl_Texture1…

Its a bit annoying to have to send down a uniform when you know you just want whats in the second texture unit.

This way shaders are also more portable, the program dosen’t need to know the name for the uniforms.[/b]
Thirded :slight_smile: This would be really handy.

Originally posted by Adruab:

Oops, kind of off topic… this certainly isn’t a complaint about OpenGL, but it would be cool :slight_smile: .

We all can accept suggestions as well so don’t worry :slight_smile:

So I can see a lot of suggestions/complaints regarding GLSL. It seems it is somewhat more restrictive as compared to some of the other shading languages (and even ARB_VP/FP in terms of matrices). AFAIK a lot of community feedback was requested when GLSL specs were being finalized but I guess they didn’t consider these to be important enough issues. I’m not sure how many of these complaints/suggestions are being looked at by ARB at the moment. The speed at which we see the changes is so slow that I doubt we’ll be seeing anything in this matter from them anytime soon. HLSL has already gone through quite a few revisions and they have added a lot of community suggestions to it to ease the development process. I hope GLSL follows the same path.

Fastian

I really want Shader Interfaces, like CG 1.2.

This comes from another thread (in case some of you missed it)

John Kessenich :

FYI, The following matrices have been added to an interim version of the shading language spec. Hopefully, you’ll see them in reality sometime soon.

uniform mat4 gl_ModelViewMatrixInverse;
uniform mat4 gl_ProjectionMatrixInverse;
uniform mat4 gl_ModelViewProjectionMatrixInverse;
uniform mat4 gl_TextureMatrixInverse[gl_MaxTextureCoords];

uniform mat4 gl_ModelViewMatrixTranspose;
uniform mat4 gl_ProjectionMatrixTranspose;
uniform mat4 gl_ModelViewProjectionMatrixTranspose;
uniform mat4 gl_TextureMatrixTranspose[gl_MaxTextureCoords];

uniform mat4 gl_ModelViewMatrixInverseTranspose;
uniform mat4 gl_ProjectionMatrixInverseTranspose;
uniform mat4 gl_ModelViewProjectionMatrixInverseTranspose;
uniform mat4 gl_TextureMatrixInverseTranspose[gl_MaxTextureCoords];

the only problem is, unless we get told which extension to look for to see if we have them avalible its going to be a shot in the dark as to when we’ll get them, as afaik neither ATI nor Nvidia bother telling devs what they have fixed/added to their drivers on the API side of things (at least, not to people like myself who arent registered with them), which is very annoying, it would be nice if at driver updates both companies could release a document, or have a page or something, which details fixes at an API level and not just at a game fix level, it would make everyones life better i feel…

not really glsl but i would really like to see more texture channels available, over the last month ive run into issues of rgba not being enuf, nowadays im sure a lot of ppl want to store more info in textures than just colors+alpha

Can’t you just use another texture?

Originally posted by bobvodka:
the only problem is, unless we get told which extension to look for to see if we have them avalible
Hell are you talking about?

ARB_shading_language_100 <—

Yeah, for more than 4 texture elements, using more than 1 input texture, and using multiple element render targets should work just fine. In the end, making it so you can have an arbitrary number of components doesn’t make sense, because graphics hardware is limited and optimized for 4 components max.