CODEWITHSUNDEEP
openglmemory-leakstextures
Dolda2000
Dolda2000

Reputation: 25855

OpenGL: Out of texture memory?

I'm writing a little game using OpenGL (in Java through JOGL, but I hardly think that matters), and I have lately been getting quite some error reports of people getting OpenGL errors "1285", which seem to indicate "out of memory". I catch this when checking glGetError after having created new textures, which lends me the feeling that I'm running out of texture memory.

However, this surprises me a bit. Isn't OpenGL supposed to manage texture memory for me, swapping textures between the GPU and process memory as necessary? The specifications for glTexImage2D, for sure, does not include any "out of memory" error as any of the possible error conditions.

Is this generally accepted practice for OpenGL drivers in spite of the specifications? Are only some drivers doing this in spite of the specifications? Do I need to take care to delete textures that haven't been used for a while if I catch this error after glTexImage2D? Or am I perhaps seeing something completely else here that OpenGL's error reporting doesn't quite concisely convey to me?

Edit: For further information, I cannot, unfortunately, debug the problem myself, because I'm not getting it. Reading from the reports people send me, the vast majority of those afflicted by this appear to be using Intel cards, but I've spotted a few nVidia cards as well (even a 680).

Upvotes: 3

Views: 2451

Answers (1)

datenwolf
datenwolf

Reputation: 162164

It's only a guess, but your program may suffer from address space fragmentation. And if that is the case it indeed matters, that you're running in a Java runtime.

OpenGL, namely the implementation, must keep copies of all data objects, so that it can swap them out on demand. But those copies, they need address space of your process. And if your process environment does a lot of allocations/deallocations, which is the very nature of Java (creating an object for just about everything) it can happen that your address space gets fragmented to the point, that larger chucks can not longer be allocated.

A few points to check: Is your program running on a 32 bit or a 64 bit JRE. If it's a 32 bit executable, try out what happens if you use a 64 bit JRE. If the issues vanish in a 64 bit environment, while on the same machine in a 32 bit environment they are there, it's a address space fragmentation issue for sure.

Upvotes: 1

Related Questions