Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: glGetTexSubImage

  1. #1
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Location
    California
    Posts
    188

    glGetTexSubImage

    I have a need for a glGetTexSubImage command. I won't explain how it should work, because it's obvious.

    We perform terrain editing on the GPU using shaders:
    http://www.youtube.com/watch?v=t1OOxpO-bZA

    Since the heightmap modification occurs on the GPU, we have to retrieve that data back to system memory, for physics and raycasting. Modifying a small section of terrain requires that we retrieve the entire heightmap, when we really only need a subsection of it. This creates a noticeable delay that is unnecessary.

  2. #2
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    315
    Did you try using an FBO to read the texture data? ie, Attach the texture to an FBO, bind it as the read-FBO, then call glReadPixels() on the area you want to retrieve. It's not a single API call, but it can be bundled up into a convenient function.

  3. #3
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Did you try using an FBO to read the texture data? ie, Attach the texture to an FBO, bind it as the read-FBO, then call glReadPixels() on the area you want to retrieve.
    The thing is, if they're doing shader work to compute this texture, then either:

    A: It's already bound to an FBO, since they're rendering to it to compute its data.

    B: They're using Image Load/Store. In which case, they could be writing to a buffer texture, thus giving them much better access to the data (ie: being able to map the buffer for reading).

    This is probably why the ARB hasn't bothered to add such a function.

  4. #4
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    Taking the point of time it would have been senseful to add GetTexSubImage into account I strongly doubt that.
    I'd have appreciated to see the "new extension" been written against the 1.0-spec

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,183
    It would probably be faster to keep a copy of the heightmap data on the CPU and modify it there instead. Readbacks suck.

  6. #6
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    149
    Maybe. Doesn't have to be. But not an argument for not including it in the first place,

  7. #7
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    469
    http://www.opengl.org/registry/specs/ARB/copy_image.txt the region of interest into a separate texture and then GetTeximage that?

  8. #8
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Why would you do that? It'd probably be faster to just get the whole image and pick out the part you want.

  9. #9
    Junior Member Regular Contributor
    Join Date
    Dec 2009
    Posts
    206
    Don't forget that there's extension for sparse textures which may be impractical to transfer as a whole. The bind to FBO/ReadPixels workaround may also fail, because FBOs usually aren't capable to handle all texture formats, e.g. compressed textures.

  10. #10
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Don't forget that there's extension for sparse textures which may be impractical to transfer as a whole.
    Sure. But... if you wanted that data, you should have kept some of it, instead of deleting the memory after the upload. Asking for stuff you already sent OpenGL is a waste of time. Generally speaking, sparse textures are not used as render targets or the output of processes that compute information. Sure, they could be, but I can't really imagine why one would want to.

    The bind to FBO/ReadPixels workaround may also fail, because FBOs usually aren't capable to handle all texture formats, e.g. compressed textures.
    If it's a compressed texture, then that data could only have gotten there in one of two ways:

    1: You uploaded it. Again, if you wanted it, you should have kept it instead of deleting the memory.

    2: You wrote to an unsigned integer texture and use texture copying to copy the bits into a compressed texture.

    The likelihood of doing the latter case and needing to read from it on the CPU? It seems rather unlikely.

    Plus, getting subimages of compressed formats is... difficult. Even moreso since glCompressedTexSubImage* themselves are only ever guaranteed to work if you upload the entire mipmap level. Otherwise, the implementation can throw a GL_INVALID_OPERATION error for arbitrary, unspecified reasons related to the format.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •