Quote:Original post by theMachinimator

Quote:Original post by OrangyTang

Quote:Original post by theMachinimator
Dang... we're using Java and we need to support PC, Mac and Linux with no special-case code.

Why do you think you need to know the vram size? OpenGL deliberately doesn't expose this information because you're not supposed to know (or care) where textures actually live and what your actual server/vram size is. I suspect you don't actually need to know, you just think you do. [grin]

On the other hand, if you really really want to know then you can mess around with the glAreTexturesResident function.

Our app needs to manage resources. For instance, we'd like to know how big and how many auxiliary render buffers / textures we can allocate. Users are free to load as many assets as they wish, so we definitely need to keep a track on how much we're using.

I care where textures live because the reality is that (IIRC) the ones that are system-RAM resident start causing bus contentions when they're accessed.

Quote:Original post by theMachinimator
Our app needs to manage resources. For instance, we'd like to know how big and how many auxiliary render buffers / textures we can allocate.

Quote:Original post by theMachinimator
Users are free to load as many assets as they wish, so we definitely need to keep a track on how much we're using.

Quote:Original post by theMachinimator
I care where textures live because the reality is that (IIRC) the ones that are system-RAM resident start causing bus contentions when they're accessed.

Quote:Original post by Krohm

Quote:Original post by theMachinimator
Our app needs to manage resources. For instance, we'd like to know how big and how many auxiliary render buffers / textures we can allocate.

I just feel the need to point out that AUX buffers are seldom HW-supported. There's no problem if you took this as an example, but if you really mean to use them... be warned!

Quote:What is not is to keep track of the remaining resources. I want to recall that new[] or malloc() don't give you this info. They'll simply ret NULL when running out. Why you need a more involved approach?

Quote:Original post by OrangyTang
Aux buffers have been hardware supported since the GF6xxx and later (and equivilent ATi cards). Support is quite widespread now.

Quote:Original post by OrangyTang
While malloc() does returns NULL when out of memory, new/new[] throw an exception (unless you explicitly use the no_throw version).

Quote:theMachinimator
Well we can detect the presence of FBOs. We have a basic fixed-function GL path in our code for the situations where our cleverer code can't operate. It's not at all clear to me how many off-screen render target textures I can allocate though. Many graphics techniques pretty much require one on their own.

Quote:Original post by OrangyTang
Running till you can't run any more doesn't seem like a good strategy. We want to know what sort of facilities we can offer the user with their machine from the moment the code boots up.

Our product - Moviestorm - is a tool for creating machinima, virtual movies on your PC. Our users can be anyone from a teenager to a pro in the movie business. We have terabytes of assets and users are free to load as many as they like into a set. We offer effects like depth-of-field and shadows which require copious resources, and as I said, deferred rendering is there awaiting switch-on. Not all users will have access to all functionality, and we want to be able to work out what we can offer when the launcher app kicks in.