whizkid667 at June 13th, 2013 13:40 — #1
Am working on a graphics application which requires me to create Textures at run-time. Here are some interesting scenarios that I encountered.
1) If initially, I use Low Resolution textures (say 256x256), the texture Creation (and hence interactivity) is pretty fast
2) The moment I switch to High resolution textures (say 2048x2048), the texture creation slows down. This is pretty much understandable
3) I delete all the high res textures and start going back to the creation of Low res textures.
The funny part is that, even upon deletion of these High Res textures I never get the same speed (interactivity) back.
I monitored the GPU memory usage using GPU-Z. I have Nvidia GTX 460 (1GB VRAM) card
1) Initially, on Low res texture creation the memory usage reaches around 650-700MB 2) Upon converting to High Res Textures (the memory jumps to around 850-900MB (should have gone further up), and then keeps hovering around the mark.
3) Upon deletion of the High Res Textures it comes back to around 350-400 MB back
But it never acquires the same speed or performance again.
Is the sluggishness due to usage of any Shared memory (instead of the dedicated memory) by the Card?
If so, then why is it still using the Shared memory when all the textures have been released and only about 350MB is being used?
Have been predominantly using the OpenGL Rendering System.
Haven't tried on DirectX. Issue has been noted on Win7 and Win8 OS.
Haven't tested it out on MacOS.
Is there anyway to ensure that the Texture Usage is confined to the dedicated memory?
A crash due to non-availability of Video memory is preferable than sluggish interactivity.
reedbeta at June 13th, 2013 14:37 — #2
I'm not sure the GPU-Z actually gives you a completely accurate readout of video memory allocated in Vista and higher versions of windows - see this forum post for a discussion of why.
Do you have the latest drivers for your video card? And have you checked for overheating issues? (That's a common cause of getting slower performance after an app has been running for a little while - the card may switch to a lower clock speed to keep the temperature down. You should be able to monitor this in GPU-Z.)
Assuming those aren't the issue, it definitely sounds odd that you're seeing a semi-permanent slowdown after using the high-res textures. If you restart your app, does the performance regain its original level? How precisely are you creating and deleting your textures? Is it possible that your high-res textures are still there, linked to other OpenGL objects such as framebuffer objects or some such, even though you've deleted your own handles to them?
If you're a brave soul and don't mind getting your hands dirty, you could try analyzing your app using a tool such as gDEBugger, NVIDIA Nsight, or GPUView. This will give you extremely detailed information on the performance of your app, but it is often difficult to wade through all the data and figure out what's going on. Still, it's better than blundering around in the dark.
stainless at June 14th, 2013 05:40 — #3
Something doesn't sound right there.
A 2048 by 2048 texture uses 64 times as much memory as a 256 by 256 one
If you were around 700Mb at 256 by 256, then it should have gone to 44,800Mb I don't know any graphics cards with 48Gig of memory.
thenut at June 14th, 2013 09:48 — #4
Using up most of your video memory for textures is quite a serious design problem. You have to keep some space for mipmaps, VBOs, shaders, and frame buffers. You might want to sit down and analyze your requirements in more detail and consider scaling back. Set upper limits for yourself like never using more than ½ your video memory for storing textures on any given scene and if you need to exceed that, you should stream data as needed.
Also take a look at texture compression. It won't compress data as much as JPG on disk, but in video memory it will consume up to 8x less space. Reed posted an article about that you can read here. The memory savings are quite huge, so it's worth looking into.