Complains regarding GLSL limitations

[Fastian]

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

[Adruab]

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 .

[Corrail]

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;

[KRONOS]

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

[Jan]

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.

[skynet]

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.

[Plasma8]

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.

[EG]

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

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

[Zengar]

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.

[Adruab]

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 ).

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