Am working on a graphics application which requires me to create
Textures at run-time. Here are some interesting scenarios that I
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
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
A crash due to non-availability of Video memory is preferable than
Please log in or register to post a reply.
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
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
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
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.
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
The memory savings are quite huge, so it’s worth looking into.