I have been reading lots of source code lately, and have never seen anyone yet using glTexStorage in their work. They seem to bypass that entirely. If glTexStorage is supposed to be faster and safer, then why are they still using the deprecated functionality? Are vendors providing sub-par implementations, or are all these graphics programmers wrong?
Not an expert on the subject but I would throw a guess that it was introduced in 4.2 making it a bit newish if I read this right https://www.opengl.org/sdk/docs/man/html/glTexStorage2D.xhtml. The tutorials you might be reading could be created before 4.2 so they don’t use it at all. Plus using the latest OpenGL version might lower your sales depending on the target audience i.e normal consumers with possibly lower end GPUs which don’t support 4.0 version of OpenGL vs tech companies with high demands such as,… well I don’t know any. Renderfarms don’t really care if they are paid and the old tech achieves the same result about the same cost. It might just be too new or small incremental between OpenGL versions.
why are they still using the deprecated functionality
glTexImage is not deprecated. Not by any sense of that word.
As for why some particular codebase still uses it, it’s more than like one of the following:
Why rewrite perfectly functioning code? The only thing that’s going to do is break something. If your existing code correctly creates working textures, and you’re not using view textures, you have nothing to gain from texture storage.
Texture storage is only core in OpenGL 4.2. While the extension even (shockingly) has MacOSX support (even more shockingly, also on 3.3 implementations), it still only came out 3 years ago. Online examples of actual 4.x programming are fairly rare. That’s not to say you can’t find some with a simple Google search, but the vast majority of OpenGL you’ll find via Google is 3.x or below.
Most online example code are effectively orphaned. They’re not kept up to date, so they were never updated to use modern stuff.
Because someone wants their code to be able to run without texture storage, and thus is compatible with older hardware and drivers that never implemented it.
all these graphics programmers wrong?
Yes, but it does what they need, so they don’t care.
Are there any techniques that may only be doable with old-style glTexImage* calls?
Related: Are there any techniques that can be done in both ways that benefit more from glTexImage* as opposed to glTexStorage*?
I’ll add to the great feedback you’ve already gotten with: I’ve never seen anyone say that glTexStorage improves frame-to-frame performance. It’s just a much cleaner, less error-prone way to do the same darn thing.
glTexStorage also has the advantage that, if you use it to allocate storage for a texture initially, and someone then comes along and tries to upload new content with glTexImage as opposed to glTexSubImage (a performance goof), you get a helpful GL error on that call marking the mistake. Whereas if you initially created it with glTexImage, the performance goof doesn’t generate an error.
I’ll just add to this; the only advantage of glTexImage is that it lets you fully respecify a texture while continuing to use the same texture object name. You can’t do that with glTexStorage - you need to glDeleteTextures then glGenTextures again in order to achieve the same result. Just to be absolutely clear: I’m talking about cases where the internal format, width and height may be different between the two textures.
Also just to be absolutely clear: the probability is that using glTexImage for this will ultimately end up doing the same thing internally as you have to do in your code with glTexStorage, so the advantage is theoretical at best, is confined to the API level, and is only actually an advantage in cases where you know you need to do this.
Just one more difference: glTexImage takes unsized internalformate types. glTexStorage does not.
In Theory texture storage should be faster at bind because there is less validation going on. I never tested that, so I don’t know.
I just use a wrapper that uses storage when available and imposes the same limitations even when storage is not available. E.g. deleting and creating a new ID on changing resolution/format. Not accepting unsized internalformate.
Beside GL_ARB_texture_storage (Core in 4.2) there also is GL_ARB_texture_storage_multisample (Core in 4.3). While there are not many drivers out there only supporting the first one, you still have to consider such corner cases.
I think every driver keeps a flag per texture that is set on validation and reset on modification, so that further validations are not done until the texture is changed.