Results 1 to 9 of 9

Thread: Why do people still use glTexImage instead of glTexStorage in modern engines?

  1. #1
    Junior Member Newbie
    Join Date
    Dec 2014
    Posts
    5

    Why do people still use glTexImage instead of glTexStorage in modern engines?

    Hi,

    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?


    Colin

  2. #2
    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/...torage2D.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.

  3. #3
    Senior Member OpenGL Lord
    Join Date
    Mar 2015
    Posts
    6,674
    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.

  4. #4
    Junior Member Newbie
    Join Date
    Dec 2014
    Posts
    5
    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*?

  5. #5
    Senior Member OpenGL Lord
    Join Date
    Mar 2015
    Posts
    6,674
    Are there any techniques that may only be doable with old-style glTexImage* calls?
    No.

    Related: Are there any techniques that can be done in both ways that benefit more from glTexImage* as opposed to glTexStorage*?
    No.

  6. #6
    Senior Member OpenGL Guru
    Join Date
    Oct 2004
    Posts
    4,654
    Quote Originally Posted by ColinG View Post
    If glTexStorage is supposed to be faster and safer, then why are they still using [it].
    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.

  7. #7
    Newbie OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789
    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.

  8. #8
    Senior Member Regular Contributor
    Join Date
    May 2013
    Posts
    149
    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.

  9. #9
    Senior Member Regular Contributor
    Join Date
    Mar 2015
    Posts
    256
    Quote Originally Posted by Osbios View Post
    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 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.

Similar Threads

  1. glTexStorage - was not declared in this scope
    By sajis997 in forum OpenGL: Basic Coding
    Replies: 3
    Last Post: 03-27-2014, 10:41 AM
  2. glTexStorage* 'levels' param, and bad texture rendering.
    By holland01 in forum OpenGL: Advanced Coding
    Replies: 3
    Last Post: 01-28-2014, 05:52 PM
  3. internal format in glTexImage*()
    By sguTiger in forum OpenGL: Basic Coding
    Replies: 2
    Last Post: 06-29-2009, 08:09 AM
  4. glTexImage & .pgm
    By baconbeastnz in forum OpenGL: Basic Coding
    Replies: 5
    Last Post: 09-07-2008, 11:12 PM
  5. Libraries, 3D Engines, Game Engines ...
    By in forum OpenGL: Basic Coding
    Replies: 1
    Last Post: 12-10-2000, 10:23 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean