NVIDIA releases OpenGL 4.2 drivers

[pbrown]

when using the binding layout qualifier for images as follows:

#version 420 core
 
layout(rgba16ui, binding = 0) writeonly uniform uimage2D _stuff;
...

the following glsl error is generated:

error C1315: can't apply layout to global variable '_stuff'

This is legal according to the GLSL 4.20 spec, but in the ARB_shader_image_load_store extension the binding is not listed.

It is legal. The "binding" part isn't covered in the ARB_shader_image_load_store extension, because the binding feature for samplers and images is in ARB_shading_language_420pack.

I'll be investigating further tomorrow, but it appears that the problem involves a combination of qualifiers. A test shader I wrote based on your example above, fails with the declaration as above, but compiles successfully without the "writeonly" qualifier.

[mfort]

Could you check that you really see trilinear or anisotropic filtering on your tests?

I've visually verified that mipmaping and anisotropic filtering works fine with glTexStorage2D. But there is a difference between your and my code. I load only the base level and generate all the others using glGenerateMipmap. I do not use sampler objects.

[Chris Lux]

I've visually verified that mipmaping and anisotropic filtering works fine with glTexStorage2D. But there is a difference between your and my code. I load only the base level and generate all the others using glGenerateMipmap. I do not use sampler objects.

Yes. I can confirm that glGenerateMipmap works!

Further this allows for the following workaround to be able to load custom mipmap levels:

glTexStorage2D(object_target(),
               init_mip_levels,
               util::gl_internal_format(in_desc._format),
               in_desc._size.x, in_desc._size.y);
// no error reported
for (unsigned i = 0; i < init_mip_levels; ++i) {
    math::vec2ui lev_size      = util::mip_level_dimensions(in_desc._size, i);
    const void*  init_lev_data = in_initial_mip_level_data[i];
    glTexSubImage2D(object_target(),
                    i,
                    0, 0,
                    lev_size.x, lev_size.y,
                    gl_base_format,
                    gl_base_type,
                    init_lev_data);
    // WORKAROUND /////////////////////////////////////
    if (i == 0) glGenerateMipmap(object_target());
}
// still no errors reported

Ugly yes, but a workaround to play with immutable textures until we get a bug fix. Which i am sorry to say lately takes very long, but lets hope for the final OpenGL 4.2 driver!

Edit: Until we require mipmapped integer textures... Then this workaround can not work, as glGenerateMipmap does not work on integer textures. So back to the old way to init our textures for now .

@nvidia: which release is targeted for the OpenGL 4.2 final implementation? r285?

-chris

[mfort]

I can also report that usage of glTexStorage2D has very negative impact on performance.

It looks like the glTexStorage2D does not allocate the mipmap levels at all. Later when calling glGenerateMipmap the driver realizes that there are no mipmap levels and allocates them by doing the same patch work as the older drivers. Essentially loading the texture back to memory, reallocating it with mipmaps and loading it back again. This round trip takes about 40ms for some large textures.

@nvidia: could you confirm this bug?

[Groovounet]

@mfort It's maybe really early to expect performance.

[pbrown]

@Chris Lux: I've dug into our GLSL compiler and root caused your issue related to the "binding" layout qualifier and have a fix undergoing testing. As I mentioned above, you may be able to get further with current drivers if you omit the "writeonly" qualifier.

I expect that one of my colleagues will be looking at the TexStorage* issue described here soon.

[Chris Lux]

@Chris Lux: I've dug into our GLSL compiler and root caused your issue related to the "binding" layout qualifier and have a fix undergoing testing. As I mentioned above, you may be able to get further with current drivers if you omit the "writeonly" qualifier.

great to hear...

I expect that one of my colleagues will be looking at the TexStorage* issues described here soon.

fixed that . there are two issues that need to be addressed, the mipmap access problem and the performance problem. the texture storage should immediately be allocated at the glTexStorageXD call to be an improvement over the old way to allocate texture.

will there be an updated 4.2 dev driver or will we have to wait for the public release?

[Piers Daniell]

We'll fix these issues asap. There will be a new developer driver released as soon as these issues are fixed.

[Piers Daniell]

Updated OpenGL 4.2 drivers can be found at the usual location:
http://developer.nvidia.com/opengl-driver

The new 280.36 driver addresses at least the following issues reported in this thread:
1) glTexStorage has been fixed to correctly created all mipmap levels.
2) Storage is allocated upfront when glTexStorage is called to address a performance issue that Chris reported.
3) The problem with mixing the binding layout qualifier and writeonly with images has been fixed so the shader text "layout(rgba16ui, binding = 0) writeonly uniform uimage2D _stuff;" now compiler correctly.

[Chris Lux]

Thanks for the update Piers!

In my tests the bugs to no occur anymore . Great work with the quick fixes...