Open GoogleCodeExporter opened 8 years ago
ATI gives you free memory for meshes, textures, and framebuffers, but NVIDIA
gives you free + available memory for VRAM in general.
We can expose them in the "Statistics" class (Renderer.getStatistics()) or as
methods on the Renderer interface (Renderer.freeMemory(),
Renderer.maxMemory()), or we can do both.
1) Free memory, returns the sum of param[0] for the 3 memory pools on ATI.
Returns "GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX" on NVIDIA.
2) Max memory, returns "GPU_MEMORY_INFO_DEDICATED_VIDMEM_NVX" on NVIDIA and
returns -1 on ATI (not available).
Original comment by ShadowIs...@gmail.com
on 25 Feb 2013 at 5:12
I think that the rather static information on the maximum available memory is
moot and should not be exposed via the API.
What is more interesting to the developer is the information on the currently
available free memory.
Perhaps replacing the value for the maximum available free memory with the
initially available free memory on application start or a value based on a
recurring snapshot type of thingy would allow the developer to monitor overall
graphics memory usage better than just comparing it to the maximum available
memory. For example, prior to a level load, the developer could instruct the
RenderStatistics to make a snapshot of the currently available free memory.
After loading all level relevant textures, shaders etc. the developers would
then be able to compare this to the previous snapshot, giving them an even more
acurate number.
Of course there is the fact that the memory available to the GPU is shared by
multiple processes and the information returned by the API is at best random,
unless you run your application in a very restricted environment, e.g. single
process (your game) plus operating system.
So, in favour of the getAvailableMaxMemory() API call I would recommend to
allow the user to make snapshots of the currently available free memory by
calling RenderStatistics#snapshotAvailableFreeMemory() and then have the
RenderStatistics display and return the last snapshot by a call to for example
RenderStatistics#getAvailableFreeMemoryFromSnapshot(), until a new snapshot is
being made. Or something similar to that functionality.
In addition I would add the RenderStatistics#getAvailableFreeMemory() method
for the currently available free memory.
I don't know why NVIDIA included this functionality into their extension, but
repeatedly calling upon the GL API for the same static/unchanging information
is somewhat moot, and it definitely gives the user no further value in
estimating the memory performance of the application.
And, displaying a -1 for ATI cards does not help to promote these very fine
cards :D
Original comment by axnsoftw...@gmail.com
on 18 Jan 2014 at 7:07
Well, I don't think these methods should be on RenderStatistics at all. As you
say, it's something you want to check periodically about the "renderer" so no
reason to involve this "statistics collection" class. Just ask the renderer
when you want the information.
If we want to show it in the debug HUD then that's fine but it doesn't have to
be in RenderStatistics to do that.
Original comment by PSpee...@gmail.com
on 18 Jan 2014 at 7:15
It seems that the maximum available memory can also be queried for ATI cards:
http://www.geeks3d.com/20100531/programming-tips-how-to-know-the-graphics-memory
-size-and-usage-in-opengl/
Original comment by axnsoftw...@gmail.com
on 18 Jan 2014 at 7:23
RenderStatistics was actually a place holder that came to my mind. It does not
necessarily have to be retrieved from that class unless it itself will collect
the information or the Renderer writes out the information to the render
statistics collection periodically.
Original comment by axnsoftw...@gmail.com
on 18 Jan 2014 at 7:26
Original issue reported on code.google.com by
remy.bou...@gmail.com
on 24 Feb 2013 at 9:19