Hi there,
when running the latest build long enough it starts to fail displaying the textures.
Also this fails not always, but i noticed on my system the per frame arena space is shrinking over time, at around 30900kb remaining this error starts showing up.
Is this a fail on my gpu memory? I play other opengl games just fine. Also, how could i debug if this is a fail on gpu memory (can visual studio do that?) or at copying from disk to gpu via cpu/pcie?
thanks for the tips!
when running the latest build long enough it starts to fail displaying the textures.
Also this fails not always, but i noticed on my system the per frame arena space is shrinking over time, at around 30900kb remaining this error starts showing up.
Is this a fail on my gpu memory? I play other opengl games just fine. Also, how could i debug if this is a fail on gpu memory (can visual studio do that?) or at copying from disk to gpu via cpu/pcie?
thanks for the tips!
Yes, this is what I have been saying for a while about how we have not actually done the texture download stuff yet. Right now we just download textures on demand, and never free them, which means that eventually we will use up all the space on the card and then that will be that.
This coming week, as we work on getting textures to download in the background, we will move it out of the on-demand loop and then there should be no more problems with memory overusage. Keep in mind that the per-frame arena is a debug arena and it is not involved here at all. It is designed to shrink consistently until it gets to 0, when it will start getting reused.
- Casey
This coming week, as we work on getting textures to download in the background, we will move it out of the on-demand loop and then there should be no more problems with memory overusage. Keep in mind that the per-frame arena is a debug arena and it is not involved here at all. It is designed to shrink consistently until it gets to 0, when it will start getting reused.
- Casey
Thank you for the clarification, i already forgot about that, now when this is running so fast.
One question though: So when the memory is over filled, iam still able to run other opengl programs in the background without a hassle. Does that mean every program only gets a fraction of the GPS memory to use up?
One question though: So when the memory is over filled, iam still able to run other opengl programs in the background without a hassle. Does that mean every program only gets a fraction of the GPS memory to use up?
Edited by robby
on
GPS memory :)
Driver allocates GPU memory in a similar way how your OS allocates virtual memory for processes - when processes needs more memory than you have physically, it pages out least used memory to pagefile. In GPU case page file is main memory.
In simplified explanation terms - if there is application A that uses most of GPU and then application B requests 128MB (or something), the driver takes 128MB from A process and copies it to main memory (or if main memory contains copy of this data, then it simply discards it from GPU), and then it can allocate this 128MB to B process. After that if process A requests to use memory that is swapped out, the process is reversed - 128MB from process B gets swapped out to main memory and the needed memory for process A is copied to GPU.
This happens even if you have only one process. If your process requires more memory than GPU has (for textures, buffers, shaders, etc...) then your rendering will be very slow. So even if your GPU has 2GB memory, you still can allocate in total 3GB for various GPU objects. But in such case driver will need constantly copy out and copy in from main memory the textures or other data you currently use. Very inefficient. FPS will be terrible.
GPU driver is pretty complex thing. It needs to manage not only memory that is used by different processes, but also execution is shared.
Driver allocates GPU memory in a similar way how your OS allocates virtual memory for processes - when processes needs more memory than you have physically, it pages out least used memory to pagefile. In GPU case page file is main memory.
In simplified explanation terms - if there is application A that uses most of GPU and then application B requests 128MB (or something), the driver takes 128MB from A process and copies it to main memory (or if main memory contains copy of this data, then it simply discards it from GPU), and then it can allocate this 128MB to B process. After that if process A requests to use memory that is swapped out, the process is reversed - 128MB from process B gets swapped out to main memory and the needed memory for process A is copied to GPU.
This happens even if you have only one process. If your process requires more memory than GPU has (for textures, buffers, shaders, etc...) then your rendering will be very slow. So even if your GPU has 2GB memory, you still can allocate in total 3GB for various GPU objects. But in such case driver will need constantly copy out and copy in from main memory the textures or other data you currently use. Very inefficient. FPS will be terrible.
GPU driver is pretty complex thing. It needs to manage not only memory that is used by different processes, but also execution is shared.
Yeah sorry mobile autocorrection. ;) Also thank you for your long explanation :)
GPU execution memory is where the driver stores shader code? Sounds indeed complex.
What tools would I use then to debug? I mean when my allocated cpu memory is overrun by my application's virtual page size, some of the unused parts gets swaped out and the needed goes in, resulting in loading stalls.
Now on the GPU side it simply did not load the texture. This behavior is really different from the cpu version of memory management.
For me it looks now like a black box. How does my application knows when it should stop asking for more GPU memory?
GPU execution memory is where the driver stores shader code? Sounds indeed complex.
What tools would I use then to debug? I mean when my allocated cpu memory is overrun by my application's virtual page size, some of the unused parts gets swaped out and the needed goes in, resulting in loading stalls.
Now on the GPU side it simply did not load the texture. This behavior is really different from the cpu version of memory management.
For me it looks now like a black box. How does my application knows when it should stop asking for more GPU memory?
There is no easy answer to that.
Just figure out your minimum requirements (X MB of GPU memory) for game and assume you'll have those X MB available. And just ignore support for hardware if it has less than X MB memory.
There are some vendor specific extensions that could provide more detailed info about memory usage, but they are not always present in system:
NVX_gpu_memory_info
ATI_meminfo
(sorry I cannot post direct links, because forum forbids to have too many links in post)
For debugging OpenGL stuff you can use:
CodeXL from AMD: http://developer.amd.com/tools-and-sdks/opencl-zone/codexl/ (this is former gDEBugger)
Nsight from Nvidia: https://www.nvidia.com/object/nsight.html
Graphics Performance Analyzers from Intel: https://software.intel.com/en-us/gpa
All tools are free and they work best when run on their own hardware (Nsight on Nvidia GPU, etc...). They might work when run on different hardware, but will provide less detailed information.
From open-source software apitrace is the best GL debugging tool: https://apitrace.github.io/
There was also promising tool vogl from Valve, but it seems to be abandoned for almost a year already: https://github.com/ValveSoftware/vogl
There's also very good Direct3D debugging tool RenderDoc from Crytek: http://cryengine.com/renderdoc But currently it doesn't support OpenGL. They have said it might support GL in future.
Just figure out your minimum requirements (X MB of GPU memory) for game and assume you'll have those X MB available. And just ignore support for hardware if it has less than X MB memory.
There are some vendor specific extensions that could provide more detailed info about memory usage, but they are not always present in system:
NVX_gpu_memory_info
ATI_meminfo
(sorry I cannot post direct links, because forum forbids to have too many links in post)
For debugging OpenGL stuff you can use:
CodeXL from AMD: http://developer.amd.com/tools-and-sdks/opencl-zone/codexl/ (this is former gDEBugger)
Nsight from Nvidia: https://www.nvidia.com/object/nsight.html
Graphics Performance Analyzers from Intel: https://software.intel.com/en-us/gpa
All tools are free and they work best when run on their own hardware (Nsight on Nvidia GPU, etc...). They might work when run on different hardware, but will provide less detailed information.
From open-source software apitrace is the best GL debugging tool: https://apitrace.github.io/
There was also promising tool vogl from Valve, but it seems to be abandoned for almost a year already: https://github.com/ValveSoftware/vogl
There's also very good Direct3D debugging tool RenderDoc from Crytek: http://cryengine.com/renderdoc But currently it doesn't support OpenGL. They have said it might support GL in future.