Godot Version
4.5.1 - stable
Question
I am working on introducing graphical settings in my game, and I wanted to create an “auto” settings system for when the player launches the game for the first time. Currently it assesses the system based on the amount of RAM, CPU cores and type of GPU (whether it’s integrated or dedicated), however one thing I would like to include in the assessment is the amount of VRAM the GPU has. I thought that RenderingDevice.MEMORY_TOTAL would be the thing I need, however that only gets the amount of VRAM that is currently used. Is there any way in GDScript to check the total amount of VRAM the GPU has?
1 Like
I saw LMStudio somehow have this feature for LLM across windows/mac .
But be probably different for Nvidia , AMD , integrated and unified systems .
Theoretically I probably only need to do this for dedicated GPUs, since for integrated graphics/virtual GPUs I will usually set all settings to lowest. The settings can be adjusted anyway but I want the auto settings to best match the capabilities of the player’s PC.
Maybe benchmark software source could be good inspiration in this case .
This is OS / API dependent and somewhat tricky to get anyway. Afaik OpenGL doesn’t have a standard call for it and it needs to be done via vendor specific extensions. Not sure for Vulkan but it may not be straightforward there either.
There was a proposal by @Calinou a few years ago but looks like noting became of it.
1 Like
You could just get the full name of the GPU itself.
RenderingServer.get_video_adapter_name().trim_suffix("/PCIe/SSE2")
Then simply use a table / json file which contains a list of popular GPU names and fetch their memory amount.
Here’s a json with quite a lot of GPUs already included:
https://raw.githubusercontent.com/voidful/gpu-info-api/gpu-data/gpu.json
4 Likes
I know that this is possible, but it just didn’t seem like a viable solution to me, considering there are a lot of niche unusual GPUs (as well as multiple versions of GPUs with different memory sizes) out there, and the fact that the list would have to be updated in the future with new GPUs being rolled out.
1 Like
This list IS being updated. I’d include an offline version in your game, and if the user has internet access, fetch the latest one from github.
EDIT: Also a lot of niche GPUs will probably report incorrect VRAM amounts to the PC anyway, especially cheap chinese knockoffs, so even that isn’t as reliable as one would think.
2 Likes
Still it does feel like a very ‘hacky’ solution to me, although it is a solution I suppose.
1 Like
I don’t think having an up-to-date lookup table is hacky in any way, but I guess we all have different opinions.
It’s more the fact that it requires internet connection instead of being able to get the data directly. And yes as you said I can include the file offline, but that would have to be updated as well.
Would querying the renderingserver get_memory_usage work?
Maybe you could briefly flood the GPU and fill up the memory, and get the figure it spits out?
print(RenderingServer.get_rendering_device().get_memory_usage(2))
1 Like
You’re not running alone in the OS. Other processes may be allocating considerable amounts of vram.
1 Like
True , but might give a rough idea. Windows / Linux desktop isnt going to be using a massive amount.
And generally people dont run games whilst other intensive stuff is going on.
If Godot doesn’t provide it via GD Script currently, then its C++ or C# direct calls to the API in question thats being used (assume Vulkan for now).
Otherwise stressing the system and making an educated guess is the only other way.
How would you know when exactly you’ve reached the limit?
By flooding the GPU with as many draw calls as possible and then checking how much memory is being used.
There’s quite a few games that take this approach for setting ‘optimal’ settings for a game, rather than just getting API calls as they are dependant on the graphics API being used (and OS level calls) which isnt always available or accurate.
Games dont always get it right of course, but its better than nothing.
How would you determine how many is “as many as possible”?
And why draw calls? You can make infinitely many draw calls without using any additional memory.
It doesn’t matter , there will always be a limit that will fill up ANY GPU. How do you think tools like Heavy Load work or 3D Mark? Getting to those limits is easy.
In fact memory is easier because you just load up a bunch of 8K textures at once, it will soon reach 8/16/24GB limits. Draw calls is more the compute side of a GPU.
You can max out a CPU by simply creating an app that iterates over millions of calculations a seconds.
Stress testing really isnt that difficult.
The problem is not in how to “max out”, but how to determine you’ve “maxed out”.
Well if you are trying to add more textures to GPU memory and you cant then you’ve maxed it out, thats really not difficult.
Whether you can detect that in Godot or not is besides the point, if not then create a GD extension that does all this for you. (whichever way you want to do it)