NVIDIA releases OpenGL 4.4 beta drivers

To coincide with the release ofOpenGL 4.4, NVIDIA is pleased to announce our OpenGL 4.4 beta driversare available for immediate download for Windows and Linux fromhttps://developer.nvidia.com/opengl-driver.
These drivers provide full OpenGL4.4 and GLSL 4.40 functionality and implement all the ARB extensionsreleased today. They also include a new extension calledGL_NV_blend_equation_advanced, which adds many new advanced blendingequations.
For OpenGL 3 capable hardware, thesenew extensions are provided:

[ul]
[li]GL_ARB_enhanced_layouts (OpenGL4.4)[/li][li]GL_ARB_multi_bind (OpenGL 4.4)[/li][li]GL_ARB_texture_mirror_clamp_to_edge (OpenGL 4.4)[/li][li]GL_ARB_texture_stencil8 (OpenGL 4.4)[/li][li]GL_ARB_vertex_type_10f_11f_11f_rev (OpenGL 4.4)[/li][/ul]
For OpenGL 4 capable hardware, thesenew extensions are provided:

[ul]
[li]GL_ARB_buffer_storage (OpenGL4.4)[/li][li]GL_ARB_clear_texture (OpenGL 4.4)[/li][li]GL_ARB_compute_variable_group_size[/li][li]GL_ARB_indirect_parameters[/li][li]GL_ARB_query_buffer_object (OpenGL 4.4)[/li][li]GL_ARB_shader_draw_parameters[/li][li]GL_ARB_shader_group_vote[/li][li]GL_ARB_sparse_texture[/li][li]GL_NV_blend_equation_advanced[/li][/ul]
For GeForce 6xx capable hardware,these new extensions are provided:

[ul]
[li]GL_ARB_bindless_texture[/li][li]GL_ARB_seamless_cubemap_per_texture[/li][/ul]
For downloads and more informationplease visit our OpenGL 4.4 pagehttps://developer.nvidia.com/opengl-driver.

GLEW 1.10.0 is now available, including GL 4.4 support.
http://glew.sourceforge.net/

  • Nigel

Is there a reason why ARB_buffer_storage isn’t available on 3.x-class NVIDIA hardware? Or ARB_clear_texture for that matter? Is this just a beta thing, or is that how it’s going to be when these release?

Possibly because of the coherent mapped mode? The immutable part seems straightforward enough to be implemented on even GL1.5 hardware, but persistent/coherent mapping likely requires hardware support. Too bad the features in ARB_buffer_storage isn’t split into two extensions.

That really should be trivial to implement - I assume, at least …

Is there any reason why GTX 660 is not supported? I bought one thinking it will work for several ogl 4.x generations… :frowning:

it’s most likely, an editorial mistake. even very low-end 6xx’s are supported.

Has anyone seen any issues with the beta driver and tessellation shaders?

When compiling separable shaders the OpenGL 4.4 the beta driver is giving the following error (both Windows and Linux)

Error C3008: unknown layout specifier ‘patch’

Here are the structs it is complaining about:

Controller:
patch out patchData
{
int i;
vec2 v;
}patchData_out;

Evalulation:
patch in patchData
{
int i;
vec2 v;
}patchData_in;

The shaders compile and run with OpenGL 4.3 drivers.

Thanks for reporting this issue. I have reproduced the problem and identified the bug. We’ll fix it asap and include the fix in a new beta driver. Unfortunately there is no work around for the OpenGL 4.4 beta driver, other than to remove the usage of “patch” until the bug is fixed.

This bug is still present on OGL 4.4 beta drivers:

Also on a Fermi GPU I see

[ul]
[li]NV_bindless_multi_draw_indirect[/li][/ul]
and that’s a bug as bindless ext is Kerpler only right?

[QUOTE=oscarbg;1253474]This bug is still present on OGL 4.4 beta drivers:
http://www.opengl.org/discussion_boards/showthread.php/181214-NV-bug-(tested-on-314-14)-using-storage-buffer-objects?p=1253473#post1253473
Also on a Fermi GPU I see

[ul]
[li]NV_bindless_multi_draw_indirect[/li][/ul]
and that’s a bug as bindless ext is Kerpler only right?[/QUOTE]

Sorry, I was unaware of the compute compiler bug until now. I was able to reproduce it and will investigate the issue.

With regards to NV_bindless_multi_draw_indirect, that should work fine on Fermi. It’s only “bindless texture” that requires Kepler.

326.29 does not allow swap interval control from the code. While WGL_EXT_swap_control extension is properly listed, (PFNWGLSWAPINTERVALEXTPROC)[b]wglGetProcAddress/b returns NULL. Vsync can be turned on/off from the control panel, so only problem is in returning function address.

Hi,
I ran into a quite serious bug with the OpenGL 4.4 beta driver which I was able to reproduce with all 326.x drivers available from the NV website.

I have a fragment shader which is doing some quite complex things (ray casting a height field). I have these things wrapped into a nice function so the shader does look something like this (broken down to illustrate issue):


#version 420 core

#extension GL_ARB_shading_language_include : require


#include </scm/data/horizon/ray_cast.glslh>
#include </scm/data/horizon/ray_cast/uniforms.glslh>


// input/output definitions ///////////////////////////////////////////////////////////////////////
in per_vertex {
   [...]
} v_in;


// attribute layout definitions ///////////////////////////////////////////////////////////////////
layout(location = 0, index = 0) out vec4 out_color;
//layout(depth_any)               out float gl_FragDepth;


// implementation /////////////////////////////////////////////////////////////////////////////////
void main()
{
    out_color.rgba = vec4(1.0, 0.0, 0.0, 1.0);
    
    ray_cast_something(ray_cast_restult);

    //if (ray_cast_restult._t > -1.0) {
    // [...] output something from the result
    // } 


    out_color.rgb = vec4(0.0, 0.0, 1.0, 1.0);
}


The problem I have is that where the ray does hit a surface I get red color and everywhere else blue. However, with this shader code I should get blue everywhere.

The problem seems to be that the shader is terminating the ray casting function but is not returning control to the main function somehow. I know that the function is working because I write per-pixel feedback into texture images (image load store) and I can see the intersection results are fine. I tried to break down the ray casting function to get it to return some debug values. However everything I tried failed to get control back in the main function to write even just a plain color. To rule out blending or depth testing these options were disabled.

With driver versions up the the 326+ line everything worked as expected and understandable.

I was not able to reproduce this. [b]wglGetProcAddress/b seems to return a non-NULL pointer for me. What GPU are you using?

We have published an updated version of the Windows OpenGL 4.4 beta drivers to version 326.58. You can download it from the usual place:

This update fixes the following bugs reported in this forum thread:
Comment #8: Error C3008: unknown layout specifier ‘patch’
Comment #10: Access to matrix member of an SSBO

Also fixed:
Uses of samples in structs and the “uniform” keyword
Fix some bugs with ARB_sparse_texture on XP

[QUOTE=Piers Daniell;1253851]We have published an updated version of the Windows OpenGL 4.4 beta drivers to version 326.58. You can download it from the usual place:

This update fixes the following bugs reported in this forum thread:
Uses of samples in structs and the “uniform” keyword[/QUOTE]

What does this refer to?

I did a lot of changes in my project to remove samplers from structs (strictly used as uniform) after testing the OpenGL 4.4 beta driver. After reading the spec it seemed as that this was ‘more’ clarified in the current GLSL spec as when i implemented it first and samplers were somewhat allowed in uniform structs. Is this allowed again? Is this behavior conformant to the spec? It seems a bit of a grey area…

[QUOTE=Chris Lux;1253880]What does this refer to?

I did a lot of changes in my project to remove samplers from structs (strictly used as uniform) after testing the OpenGL 4.4 beta driver. After reading the spec it seemed as that this was ‘more’ clarified in the current GLSL spec as when i implemented it first and samplers were somewhat allowed in uniform structs. Is this allowed again? Is this behavior conformant to the spec? It seems a bit of a grey area…[/QUOTE]
The OpenGL 4.4 beta driver had a regression where we became too restrictive with samplers in structs. Basically the spec, in the absence of bindless texture, only allows samplers to be declared as part of a uniform-qualified variable. However, there is no restriction that the sampler can’t be in a struct which is declared as a uniform-qualified variable. The bug we fixed is that we forbid this by mistake, where in previous drivers we allowed it.

Here are some examples:
uniform sampler2D tex; // legal

struct S {
uniform sampler2D tex; // illegal to put “uniform” in struct
};

struct S {
sampler2D tex; // legal
};
S foo; // illegal - “samplers” must be uniform
uniform S bar; // legal - the sampler in S is now part of a uniform-qualified variable (the bug we fixed between 326.29 and 326.58 is to allow this)

uniform Buffer {
sampler2D tex; // illegal - without bindless texture this is not allowed
};

Hope that helps.

[QUOTE=Piers Daniell;1253886]The OpenGL 4.4 beta driver had a regression where we became too restrictive with samplers in structs. Basically the spec, in the absence of bindless texture, only allows samplers to be declared as part of a uniform-qualified variable. However, there is no restriction that the sampler can’t be in a struct which is declared as a uniform-qualified variable. The bug we fixed is that we forbid this by mistake, where in previous drivers we allowed it.

Here are some examples:
uniform sampler2D tex; // legal

struct S {
uniform sampler2D tex; // illegal to put “uniform” in struct
};

struct S {
sampler2D tex; // legal
};
S foo; // illegal - “samplers” must be uniform
uniform S bar; // legal - the sampler in S is now part of a uniform-qualified variable (the bug we fixed between 326.29 and 326.58 is to allow this)

uniform Buffer {
sampler2D tex; // illegal - without bindless texture this is not allowed
};

Hope that helps.[/QUOTE]
Thanks for the clarification.

However, does the spec really allow this. I read the part about opaque and sampler types and it seems to be quite picky about these types, where and how they can be declared. I mean it is really useful, but is it legal according to the spec?

-chris

Yes, the GLSL spec allows this. I confirmed with the spec editor. This sentence on page 27 of the GLSL 440 spec:
They [opaque values] can only be declared as function parameters or uniform-qualified variables.

doesn’t just mean basic-type variables, it means any variable, including structs.

[QUOTE=Piers Daniell;1253892]Yes, the GLSL spec allows this. I confirmed with the spec editor. This sentence on page 27 of the GLSL 440 spec:
They [opaque values] can only be declared as function parameters or uniform-qualified variables.

doesn’t just mean basic-type variables, it means any variable, including structs.[/QUOTE]
Thanks for this fast bug fixing!
Now some questions hope you can answer some of them:
I found references about NVX_shader_thread_group and NVX_shader_thread_shuffle and on twitter Pat Brown said that he thought were already implemented on driver.
Are specs coming soon jointly for also new WGL_NV_delay_before_swap extension?

Release notes of new 325 drivers mention TXAA support on OpenGL… I obtained TXAA SDK (v2.1) contacting Lottes… question is if TXAA on OpenGL is already present for Linux 325 driver or Windows driver only?.. if Linux support is present I would like to test but my TXAA SDK libs aren’t compiled for Linux…
Also we get now GL_NVX_nvenc_interop extension reported but current NVENC 2.0 SDK June 2013 release on web doesn’t mention support yet for NVENC encoding from OGL buffers/texes (only CUDA pointers and DX support presently)… any clue?

Latest Intel drivers seems to ship with new exts:
GL_INTEL_fragment_shader_span_sharing
Lottes commented “GL_INTEL_fragment_shader_span_sharing might be sharing across the threads in a 2x2 pixel quad?”
Eric Penner’s “Shader Amortization using Pixel Quad Message Passing" (Gpu Pro 2) talks about some usage cases
In case Fermi/Kepler HW supports that is NV interested on implementing/exposing this functionality…
GL_INTEL_compute_shader_lane_shift
That also seems like new warp SHUFL intrustion in PTX parlance in Kepler might NV also expose that?

thanks…