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.
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 .
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:
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:
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.
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 ).
Oops, kind of off topic… this certainly isn’t a complaint about OpenGL, but it would be cool .
Originally posted by Adruab:
Oops, kind of off topic… this certainly isn’t a complaint about OpenGL, but it would be cool .
We all can accept suggestions as well so don’t worry
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.
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
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?
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.