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.
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.
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.
@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.
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?
The new 280.36 driver addresses at least the following issues reported in this thread:
glTexStorage has been fixed to correctly created all mipmap levels.
Storage is allocated upfront when glTexStorage is called to address a performance issue that Chris reported.
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.
But when I enable the mipmaps then creating textures with glTexStorage2D is about 10 times slower then calling glTexImage2D(…, NULL) for each level. The slowdown in previous drivers was caused by glGenerateMipmap. In this drivers any simple call to OGL stalls a bit. (5-7ms)
On the client side i just bind the textures with according sampler objects to the unit 0 and 1 without setting the according uniform values to 0 an 1. When using the 2D sampler in the shader i get the results, but when using the 3D texture and thus eliminating the 2D sampler in the link process i get no results.
> But when I enable the mipmaps then creating textures with glTexStorage2D is about 10 times slower then calling glTexImage2D(…, NULL) for each level.
With the latest 280.36 driver the glTexStorage2D will allocate the hardware surfaces upfront instead of deferring it to the glTexSubImage2D calls. The older style glTexImage2D(,NULL) calls won’t create the hardware surface.
Overall, calling glTexStorage2D and then glTexSubImage2D for each level should be about the same performance as glTexImage2D(,NULL) then glTexSubImage2D for each level. And they should both be faster than using glGenerateMipmaps or glTexParameter(GL_GENERATE_MIPMAP, TRUE). The advantage of glTexStorage2D is that the surface allocation happens immediatly and the texture is immutable (except for image data).
If this is not the performance what you’re seeing in your app, could you paste some code/pseudo-code to explain where performance is falling short. Thanks.
I am also seeing some strange performance hits when using TexStorage. In the following log example i am generating two volume textures and one 1D texture:
using TexStorage3D to allocate the texture image including mipmaps
then i upload the first level using TexSubImage3D
after that i use GenerateMipmap to generate the missing mipmaps
As you can see the first volume is completed very fast. Then the second takes a huge amount of time for TexStorage3D. What is most interesting is that TexStorage+TexSubImage on the 1D texture after the two volume textures takes also extremely long…
This was tested on Windows 7 x64, GeForce GTX 480 1.5GiB, 280.36. The times were taken using QueryPerformanceCounter.