Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 2 of 2

Thread: glBlitFramebuffer() from (or to) specific texture layer

  1. #1
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,399

    glBlitFramebuffer() from (or to) specific texture layer

    Is it still true that the only way to blit from (or to) a specific layer in a layered texture is to bind that specific layer to the framebuffer and then call blit?

    An extension of glBlitFramebuffer which took a source/dest layer index would be useful here.

    Use case: Say you have a layered texture of say 2 or 6 layers. Each frame you render those layers with layered rendering and resolve them into another texture or the system framebuffer. So you have an FBO where entire textures (color, depth, and possibly stencil) are bound as FBO attachments for drawing. Then you want to resolve/blit each face into other textures or the system framebuffer. What do you do? Reconfigure the FBO 2-6 times before each Blit, and then put it back the way it was afterwards? FBO reconfigs are expensive. Or do you have 2 or 6 FBOs (one per layer) which you pre-configure, and then cycle through binding each "layer FBO" calling Blit for each? Neither of these seem like great options.

    Yes, I realize I could just chuck glBlitFramebuffer and render quads with the layered texture bound to a sampler as input to resolve/blit, iteratively assigning different layer indices to each quad, but this seems like overkill.

    Any simpler methods I'm missing? I'm open to any GL extensions as answers too.

  2. #2
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,008
    For what it's worth, Vulkan's blit and resolve functions work with 3D coordinates.

    The OpenGL issue here is likely an outgrowth of the fact that glBlitFramebuffer was written before layered framebuffers existed. The effective solution would probably be to use multiple FBOs, to avoid the overhead of re-validating the framebuffers.

Posting Permissions

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