PDA

View Full Version : Complains regarding GLSL limitations



Fastian
05-29-2004, 11:50 AM
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
05-29-2004, 06:45 PM
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
05-30-2004, 02:27 AM
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
05-31-2004, 02:10 AM
Add something like dot2 and dot3 so that one doesn't have to construct a vec4 to vec3 just to do a dot3.

Jan
05-31-2004, 11:07 AM
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
05-31-2004, 11:56 AM
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
06-10-2004, 04:25 AM
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
06-10-2004, 04:50 AM
> 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
06-10-2004, 07:24 AM
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
06-10-2004, 08:07 AM
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 :p ).

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

OneSadCookie
06-10-2004, 05:00 PM
Originally posted by 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.Thirded :) This would be really handy.

Fastian
06-10-2004, 07:45 PM
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 :)

Fastian
06-10-2004, 08:10 PM
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

Sunray
06-11-2004, 03:30 AM
I really want Shader Interfaces, like CG 1.2.

V-man
06-11-2004, 06:47 AM
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];

bobvodka
06-13-2004, 02:07 AM
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..

zed
06-13-2004, 11:53 AM
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

Humus
06-13-2004, 03:54 PM
Can't you just use another texture?

V-man
06-14-2004, 06:59 AM
Originally posted by bobvodka:
the only problem is, unless we get told which extension to look for to see if we have them avalibleHell are you talking about?

ARB_shading_language_100 <---

Adruab
06-14-2004, 01:40 PM
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.

Foxbat
06-15-2004, 09:21 AM
I haven't gotten that deep into GLSL but...

How about the ability to work with multiple vertices ( lines, triangles ) at one time? I've essentially been doing 'vertex programs' for a few years while doing space weather vis. It is necessary to render the data using a variety of projections. But it is not enough to merely transform individual points ( which GLSL does ) but also necessary to clip primitives ( lines, triangles ) and render the different parts separately. But this clipping will be different depending upon the projection used. It would be great to move this to the graphics hw and free up the CPU as much as possible for the scientific computing.

Adruab
06-15-2004, 12:27 PM
The only geometry clipping that occurs at all is clipping by planes which you can change by using states (I'm not even sure that it actually clips the geometry, it might just reject outside pixels or something...).

Dealing with multiple vertices at once won't be here for a while (topology processing, and even then it's not guaranteed to be GPU side). It is unrealistic to ask for something that no graphics card can do.

zed
06-15-2004, 03:01 PM
sure you can use another texture (if available) though its not as convient eg for a rgba trexture u use the one texture + not 4x textures. i also believe working with vertices aint flexible anuf , eg wouldnt it be gret to supply a single vertice (as a base point) + then from there let the vertice program create a whole bunch of vertices. these are a couple of real limitations that ive run into over the last month (ok the hardware at present mightnt be capable of it but its gotta be forward thinking) the days of using graphics cards as plain old 3drenderers are over.

Foxbat
06-15-2004, 03:49 PM
Originally posted by Adruab:
It is unrealistic to ask for something that no graphics card can do.Then nothing new would ever happen!

Seriously - and I'm no low level OGL implementor - how hard would it be to have, on the CPU side, a call like 'glBegin( GL_VERTEX_PROGRAM )' followed by all the usual calls to glVertex*, glTex* etc. Everything is transformed as usual down to the vertex program. By default, when using GL_VERTEX_PROGRAM, nothing would happen. The geometry would just fall off the end of the Earth. But if there is a vertex program loaded allow the vertex program to call glBegin/End to define the primitive type. And then you'd need a new call - at the vertex program level - say 'glShaderVertex*'. This would be kinda sorta like the glVertex* we know and love but would send the geometry ( texcoord yadda-yadda ) directly to the shader iself.

It seems to this uninformed brain that somthing like this should be doable on mondern HW. No?

Jan
06-16-2004, 08:16 AM
Originally posted by Foxbat:

Originally posted by Adruab:
It is unrealistic to ask for something that no graphics card can do.Then nothing new would ever happen!

It seems to this uninformed brain that somthing like this should be doable on mondern HW. No?Of course we all need to have "visions" about what we would like to have, thatīs true.

But on current hardware your demands are impossible to satisfy. The pipeline is strictly "one in - one out". If fpīs it can also be "one in - none out".
But thatīs it. We all have to live with it.

Jan.

Chris Lux
06-16-2004, 08:55 AM
Originally posted by Jan:
float c = a.xyz * b.xyz;

This will do a dot3, instead of a dot4.
correct me if i am wrong, but your c will only be a.x * b.x (if this code does work), but not the dot3 of a and b, because vec3 multiplication is componentwise.

Corrail
06-16-2004, 10:25 AM
[quote]Originally posted by Chris Lux:
[B]
float c = dot(a.xyz, b.xyz);

Jan
06-16-2004, 10:30 AM
Well, i thought about operator-overloading, but i might have missed something.

Anyway, the point was, to show, that a dot3 is possible with 4-component vectors, without modifications of glSlang.

Jan.

Adruab
06-16-2004, 11:24 AM
Heheh, yes I have no problem with impelementing a level above the GPU on the CPU in order to more flexible vertex operations. However, the question was focused on offloading the CPU. That would certainly not occur unless the operation was GPU accelerated.

As for GPU accelerating these things... right now the GPU is very pipelined and optimized for stream processing. This totally breaks if you start wanting random access for everything in the mesh (I believe it will be a while until full topology processing is fully accelerated on GPU hardware). Simple stuff, like generating triangles from points still fit the bill (other simple examples). Anything too expensive and it will likely break the pipeline's efficiency.

I might be misinterpreting something but that's what it sounds like you want to do. Cheer up though :) . A topology processor of some sort is planned for the next revision of DirectX, which means it will likely be added to OpenGL too in some form or another. The real question is if it will be completely GPU based, or only partly....

mrbill
06-16-2004, 11:35 AM
Originally posted by Chris Lux:
correct me if i am wrong, but your c will only be a.x * b.x (if this code does work), but not the dot3 of a and b, because vec3 multiplication is componentwise.
float a = a.xyz * b.xyz;Shouldn't even compile.
The Lvalue is a float, the Rvalue is a vec3.
But you are correct that it isn't a dot. It's a per component multiply.

The user-defined functions to do a dot3 are:


float dot3( vec4 x, vec4 y ) { return dot( x.xyz, y.xyz ); }
float dot3( vec3 x, vec3 y ) { return dot( x, y ); }-mr. bill

DirtyHenry
06-18-2004, 04:53 AM
I think gl_ModelMatrix would be useful (for cubemap lookups in environment mapping for example)...

Corrail
06-23-2004, 08:57 AM
GLSL 1.1 is out! ;)
http://oss.sgi.com/projects/ogl-sample/registry/ARB/GLSLangSpec.Full.1.10.59.pdf

Adruab
06-23-2004, 09:27 AM
You beat me to it :) . Hooray for extension semantics! :)

glitch
06-23-2004, 02:46 PM
hi,

looking at the new version of glsl specs and i'm always stuck on section 4.1.9, last line :
"There is no mechanism for initializing arrays at declaration time from within a shader."

is there a trick to avoid the ugly array initialization:
array[0] = 1.0; array[1] = 0.5; array[2] = 0.2; ...

if not, consider that as a complain ;)

John Kessenich
06-29-2004, 12:38 AM
Collecting several responses here...

* I am interested in community feedback for the next version of the language. Version 1.1 reflects some of this over version 1.0. Not all features were included in version 1.1 though, so that a quality standard could be delivered on schedule.

* Arrays should become first class objects. This will bring initializers and other array features.

* If you want to initialize an array in a shader, consider whether you can do something with a uniform array initialized by the application instead. It may be higher performing as well.

* If you want

uniform mat4 u;
u.inverse;
or
inverse(u);

also consider doing this in the application. If did this in the shader, then you'd also better hoping the compiler notices it's the same inverse each time and moves the work to the application side at uniform load time anyway. I'm sure compilers will eventually get that smart.:-)

* An extension mechanism "#extension" is available now.

* Future GL may virtualize texture objects and avoid much of the complexity of manually mapping them to units. If this happens, the API will bind texture objects to samplers instead of units. The language will remain as is.

JohnK

V-man
06-29-2004, 06:23 AM
There isn't a new glGetUniformLocation for samplers?

And since in the API, textures are treated as beeing bound to units (image units), and in the GLSL shader, there is no indication of which texture should be bound to which unit, it can be a problem.

In my case, I scan the shader for "sampler1D" "sampler2D" "sampler3D" "samplerCube" and assign texture unit number in order in which the sampler declarations are made.

uniform sampler2D This; // unit 0
uniform samplerCube That; // unit 1
uniform sampler3D TheOther; // unit 2

And in case the user wants all three to be bound to the same units, then that's a problem.

It would be simpler if GL was changed not to allow this. What's the point of this if one can't access all three.

barthold
06-29-2004, 07:12 AM
Originally posted by V-man:

uniform sampler2D This; // unit 0
uniform samplerCube That; // unit 1
uniform sampler3D TheOther; // unit 2

And in case the user wants all three to be bound to the same units, then that's a problem.

It would be simpler if GL was changed not to allow this. What's the point of this if one can't access all three.The fundamental behavior of how textures are bound to texture targets on a texture image unit has not changed. Before GLSL came along you were not able to access textures bound to different targets on the same texture image unit at the same time. You have to disable one target and enable another. If multiple targets are enabled, the "highest" enabled one wins. In GLSL the texture enable state is ignored. Instead, you use samplers of different types (sampler2D etc) to select the texture target. What hasn't changed is that multiple targets cannot be active at the same time.

I don't think this is such a big deal anymore, current hardware supports 32 texture image units. If you need access to textures of different dimensionality, just use another texture image unit.

Barthold

Korval
06-29-2004, 10:21 PM
current hardware supports 32 texture image units.Whose current hardware?

As I was looking through the new glslang spec, I noticed the following line:


The goal of this work is a forward looking hardware independent high-level language that is easy to use and powerful enough to stand the test of time and drastically reduce the need for extensions.Anyone get the idea that the ARB failed miserably at this? The language isn't much more forward looking than Cg, and it's more complicated and less easy to use (partially due to bonehead language decisions that go against established C/C++).

V-man
06-30-2004, 06:16 AM
In GLSL the texture enable state is ignored. Instead, you use samplers of different types (sampler2D etc) to select the texture target. What hasn't changed is that multiple targets cannot be active at the same time.

I don't think this is such a big deal anymore, current hardware supports 32 texture image units. If you need access to textures of different dimensionality, just use another texture image unit.

Barthold I think this is GL's fault (1.0 or 1.1) for allowing multiple texture types to be bound to the same unit. It's never been useful.

Unless if it is useful for accessing textures from vertex shader. What happens when one tries to access a 2D texture from VS and a 1D in FS from the same unit? Is it possible on the fancy NV40?

But having a function that returns a list of sampler names and location, that would be useful.