Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39

Thread: Complains regarding GLSL limitations

  1. #1
    Junior Member Regular Contributor
    Join Date
    Feb 2001
    Posts
    134

    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

  2. #2
    Intern Contributor
    Join Date
    Apr 2004
    Location
    Bellevue, WA
    Posts
    73

    Re: Complains regarding GLSL limitations

    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 .

  3. #3
    Member Regular Contributor
    Join Date
    Apr 2002
    Location
    Austria
    Posts
    328

    Re: Complains regarding GLSL limitations

    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;
    There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

    There is another theory which states that this has already happened...

  4. #4
    Junior Member Regular Contributor
    Join Date
    Jun 2000
    Location
    Portugal
    Posts
    214

    Re: Complains regarding GLSL limitations

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

  5. #5
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Complains regarding GLSL limitations

    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.
    GLIM - Immediate Mode Emulation for GL3

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    661

    Re: Complains regarding GLSL limitations

    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.

  7. #7
    Junior Member Newbie
    Join Date
    Jun 2004
    Location
    Melbourne, Australia
    Posts
    5

    Re: Complains regarding GLSL limitations

    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.

  8. #8
    Intern Contributor
    Join Date
    Jul 2002
    Posts
    66

    Re: Complains regarding GLSL limitations

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

  9. #9
    Senior Member OpenGL Pro Zengar's Avatar
    Join Date
    Sep 2001
    Location
    Germany
    Posts
    1,932

    Re: Complains regarding GLSL limitations

    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.

  10. #10
    Intern Contributor
    Join Date
    Apr 2004
    Location
    Bellevue, WA
    Posts
    73

    Re: Complains regarding GLSL limitations

    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 .

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •