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.

Re: NVIDIA releases OpenGL 4.2 drivers

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.

Re: NVIDIA releases OpenGL 4.2 drivers

Originally Posted by mfort

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:

Re: NVIDIA releases OpenGL 4.2 drivers

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.

Re: NVIDIA releases OpenGL 4.2 drivers

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

Re: NVIDIA releases OpenGL 4.2 drivers

Originally Posted by 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.

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?

Re: NVIDIA releases OpenGL 4.2 drivers

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.