NVIDIA releases OpenGL 4.0 drivers

[Chris Lux]

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

[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?

[Rob Barris]

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.

[Chris Lux]

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.

[elFarto]

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

[Chris Lux]

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.

[Chris Lux]

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

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

[Chris Lux]

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

shader snippet:

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:

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

[Aleksandar]

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.

[Aleksandar]

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.