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 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 37

Thread: NVIDIA releases OpenGL 4.0 drivers

  1. #21
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: NVIDIA releases OpenGL 4.0 drivers

    Are there any plans to support the GL_ARB_shading_language_include extension in the near future?

  2. #22
    Intern Newbie
    Join Date
    Nov 2008
    Posts
    36

    Re: NVIDIA releases OpenGL 4.0 drivers

    Seems to me it's pretty trivial to implement such functionality in the text reading portion of your code. Why do you need an OpenGL extension for it?

  3. #23
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: NVIDIA releases OpenGL 4.0 drivers

    Quote Originally Posted by Prune
    Seems to me it's pretty trivial to implement such functionality in the text reading portion of your code. Why do you need an OpenGL extension for it?
    The ease of implementation is low if your source doesn't nest includes, and particularly if your source doesn't bracket #includes with #ifs based on expressions. Bring those idioms into the mix and the problem grows in difficulty...

    GLSL already has a preprocessor, the include feature just makes it more complete.

  4. #24
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: NVIDIA releases OpenGL 4.0 drivers

    I have a custom preprocessor based on boost::wave, but this way it is really complicated if glsl internal macros are used. I am asking this because i want to get rid of the custom preprocessor.

    What i think is still missing is a way to get custom macros to the shader preprocessor (i.e. MY_CUSTOM_NUM_LIGHTS). I want to get away from fiddling with the shader source based on certain assumptions.

  5. #25
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    218

    Re: NVIDIA releases OpenGL 4.0 drivers

    Quote Originally Posted by Chris Lux
    What i think is still missing is a way to get custom macros to the shader preprocessor (i.e. MY_CUSTOM_NUM_LIGHTS). I want to get away from fiddling with the shader source based on certain assumptions.
    Can't you just declare:

    #include "internal.h"

    at the top of your shaders, then use glNamedStringARB to pass in your parameters? (i.e. generate an include file at runtime)

    Regards
    elFarto

  6. #26
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: NVIDIA releases OpenGL 4.0 drivers

    http://blogs.nvidia.com/ntersect/201...r-release.html

    OpenGL 4.0 – While we currently support OpenGL 4.0 in developer drivers, Release 256, brings full OpenGL 4.0 support to our unified consumer drivers. GeForce GTX 400 series customers can immediately take advantage of the tessellation support in OpenGL 4.0 by downloading Unigine’s latest release of their Heaven benchmark, version 2.1, which adds support for OpenGL 4.0 tessellation and 3D Vision technology. GeForce GTX 400 series GPUs are tessellation monsters, feed them highly tessellated objects and they’ll chew them up at an incredible speed.
    very nice drivers.

    but, as it always is after new releases, the requests: please support the GL_ARB_shading_language_include extension in the near future.

  7. #27
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: NVIDIA releases OpenGL 4.0 drivers

    hi,
    i found that the following calls crash on the latest OpenGL 4.0 drivers (257.15) using windows 7.

    Code :
    int                 num_comp_routines = 0;
    scoped_array<int>   comp_routines;
    glGetActiveSubroutineUniformiv(_gl_program_obj, GL_FRAGMENT_SHADER, i, GL_NUM_COMPATIBLE_SUBROUTINES, &amp;num_comp_routines);
     
    if (0 < num_comp_routines) {
        comp_routines.reset(new int[num_comp_routines]);
        glGetActiveSubroutineUniformiv(_gl_program_obj, GL_FRAGMENT_SHADER, i, GL_COMPATIBLE_SUBROUTINES, comp_routines.get());
    }


    both calls to glGetActiveSubroutineUniformiv crash with an access violation in nvoglv64.dll, i tried a very large fixed number for the number of compatible routines to get around the first crash but the second also crashed...

    -chris

  8. #28
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: NVIDIA releases OpenGL 4.0 drivers

    ok,
    after some trying to work around this issue i think subroutines are just broken in current nvidia drivers.

    shader snippet:
    Code :
    subroutine vec4 generate_output_color(in vec2 cp_tc, in vec2 pp_tc, in vec4 cp_col, in vec4 pp_col, in float b);
     
    subroutine uniform generate_output_color output_generator;
     
    subroutine (generate_output_color)
    vec4 output_blended_coordinate(in vec2 cp_tc, in vec2 pp_tc, in vec4 cp_col, in vec4 pp_col, in float b)
    {
        return (mix(vec4(cp_tc, 0.0, 1.0), vec4(pp_tc, 0.0, 1.0), b));
    }
     
    subroutine (generate_output_color)
    vec4 output_blended_color(in vec2 cp_tc, in vec2 pp_tc, in vec4 cp_col, in vec4 pp_col, in float b)
    {
        return (mix(cp_col, pp_col, b));
    }
    ...
        return (output_generator(a, b, c, d, e));

    as in my last post said, i am unable to use the reflection api to retrieve all the information i need.

    so i tried the direct way:
    Code :
    unsigned  rl = glGetSubroutineIndex(_gl_program_obj, GL_FRAGMENT_SHADER, "output_blended_color");
    rl = glGetSubroutineIndex(_gl_program_obj, GL_FRAGMENT_SHADER, "output_blended_coordinate");

    in every case glGetSubroutineIndex returns complete garbage. and when trying to force an index (0 or 1) on the subroutine uniform (for which i easily get the location using glGetSubroutineUniformLocation). i get an invalid value gl error.

    if someone got subroutines to work, please let me know if o did something wrong.

    regards
    -chris

  9. #29
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,069

    Re: NVIDIA releases OpenGL 4.0 drivers

    Subroutines work just fine with 257.15 drivers on WinXP x32!

    Indices returned by glGetSubroutineIndex are not 0 and 1. glGetSubroutineUniformLocation returns 0 if there is one subroutine uniform, and glGetSubroutineIndex-s return 2 and 1 respectively (reverse order compared to the order it is defined in the shader). Don't ask me why. I also have to figure it out. Your problem makes me curious to see what values are returned.

    I'll install Win7 x64 on the same machine and tell you if there is any problem with x64 implementation of the drivers.

  10. #30
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,069

    Re: NVIDIA releases OpenGL 4.0 drivers

    Chris, I think I have discovered what is your problem!

    Few hours ago I have installed Win7 x64, and surprisingly shader subroutines ... work perfectly.

    I have tried to gain symptoms like yours by changing the shader code making intentional errors. After a while it happened. Then I checked your cod again. In the code fragment you have posted there is no definition of subroutine uniform variable. This kind of error should be reported by the GLSL compiler. Probably you have neglected error messages posted by the compiler.

    If shader is not compiled correctly than it cannot be linked also. In that case location retrieved by functions like glGetSubroutineIndex are undetermined.

    The only thing that is not like spec says is indexing in NV drivers. Instead of 0 based it is 1 based. Further more, it seems that some kind of stack is used for storing functions' names, because the order of indices is inverted.

Posting Permissions

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