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: strategy for glMakeTextureHandleNonResidentARB(...)

  1. #1
    Member Regular Contributor
    Join Date
    May 2016
    Posts
    435

    strategy for glMakeTextureHandleNonResidentARB(...)

    hi,

    i've just read about how to use GL_ARB_bindless_texture, he key is to make a texture "resident" before using it in shaders. "resident" means that it is on the "server-side" memory (gpu). i tried to figure out how to query how much gpu memory is "remaining" but apparently that is not possible in openGL (right?). so, the question is: what to do if i have many big textures ? at first i'd just let them all be resident ... but is there a guideline on how to temporary make textures non-resident ?

    let's say i want to draw 20 different models with many textures that exceed the video memory of my graphics card. should i divide the batches in smaller parts, and if so how many ?

    thanks in advance !!

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,155
    Quote Originally Posted by john_connor View Post
    i tried to figure out how to query how much gpu memory is "remaining" but apparently that is not possible in openGL (right?).
    As part of the GL spec, no. However, some of the GPU driver vendors have provided extensions to help with this. For instance:



    I've used the former (not the latter), and it's pretty useful. Besides telling you how much device (GPU) memory is installed, it tells you how much is still available, and how much the GPU/GL driver has had to spill (evict) off the GPU back onto CPU memory since a given point in time. If you see evicted counting up, that's a strong indicator that you are overrunning GPU memory.

    NVidia has also recently released these extensions in their GL drivers:



    which provide memory consumption at the per-object level rather than for all of GPU memory. Haven't used these yet, but I plan to soon.

    so, the question is: what to do if i have many big textures ? ... let's say i want to draw 20 different models with many textures that exceed the video memory of my graphics card. should i divide the batches in smaller parts, and if so how many ?
    That's going to depend on your application. First thing is to get the minimal available GPU memory you need to fit into, and estimate whether everything will just fit as-is. Just use simple heuristics on GPU texture size. Ensure that you're using GPU texture compression sensibly to save space and bandwidth, not just using RGB8 and RGBA8 for everything.

    If your textures (along with all your buffer objects, framebuffers, and other GPU resources) won't fit, then....

    With bindless texture, there's less of a reason to have super-big texture arrays to batch things together. So you probably don't need those anymore.

    Do you have a lot of textures with very high pixel dimensions? You only need the highest-res MIPmap levels when those textures are going to be very large in screen-space (and if your screen space dimensions in pixels are large). So perhaps you consider paging in LODs progressively based on how large they can be on-screen (or never, depending on your screen dimensions).

    Or do you just have a lot of textures and that's the problem? Perhaps you need to implement some runtime paging support to dynamically load from disk and upload to the GPU just those textures that could be needed around the eyepoint at any given time.

    To your main question though:

    strategy for glMakeTextureHandleNonResidentARB(...)
    I'd be very leery of expecting any/all GL drivers to so something that performs really well when you flip textures between resident and non-resident. When the driver pages textures between CPU and GPU memory (e.g. when you're overrunning GPU memory), the results are not pretty. Long frame hangs while the driver goes out-to-lunch moving data around en-mass.

    Instead, I'd suggest the strategy of creating what textures you need (those that you know should fit in GPU memory), make them resident, and be done with it.
    Last edited by Dark Photon; 11-15-2017 at 08:32 PM.

Tags for this Thread

Posting Permissions

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