komandor_353 In general, loading the game and its operation requires 6-7 GB of RAM. I gave this code to 3 friends:
I can see the crash on weak NV cards. Apparently video memory is needed here. The most interesting thing is how Iris Xe takes memory — any stats?
Tomcat
I can't give any statistics yet, but as far as I understand, Godot can't automatically "swap" files from RAM and VRAM and back.
That's why when Forward+ initially loads, it tries to shove everything into VRAM, it fails and it breaks. And if that's the case, then the only way to do it is to write to the developers so that they add automatic swap, or tell from them to us about methods for controlling file loading. But I could be wrong about all this.
komandor_353 Godot can't automatically "swap" files from RAM and VRAM and back.
Godot can't. But Iris XE, as far as I understand, that's exactly how it works — the video driver does it.
Tomcat I think in case of integrated graphics core everything is simpler. For it RAM and VRAM are the same, so everything works well
komandor_353 For it RAM and VRAM are the same, so everything works well
Then it turns out that for the game, you need VRAM to avoid crashing.
Tomcat Yes, or somehow learn to control loading and unloading in VRAM, until the Godot developers themselves do automatic swap, like in UE5
komandor_353 until the Godot developers themselves do automatic swap, like in UE5
It can be suggested
Toxe Might be best to report on GitHub.
Tomcat But to be honest I don't know where to write. Is there some kind of developer email or how to specifically contact them?
komandor_353 good luck, just open an issue on github and hope for the best.
So there was no issue at all, the godot did what it was supposed to do, warn people that run out of juice. And maybe you need to optimize the code to run on potatos?
kuligs2 Well, the funny thing is that if you use gl_compatibility, there are no problems with rendering (there is another one), it just loads all the meshes into RAM and doesn't complain about anything, but with Forward+ the problem above appears
komandor_353 but with Forward+ the problem above appears
Apparently, with Forward+ he expects you to have a decent video card (well, one that he considers worthy) and gets very offended if it is not.
Tomcat XD. That's what I'm going to go complain to the developers with
komandor_353 But to be honest I don't know where to write. Is there some kind of developer email or how to specifically contact them?
As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.
im no expert but isnt the compatibility uses the CPU and forward+ uses the GPU then you just get into the bottlenecks in rendering perfomance. So either optimize your scene or get a better gpu.. I dont see the reason to complain
kuligs2 Either way there's a problem because it's stupidly trying to cram the whole scene into VRAR, which it shouldn't do. Clearly there must be some restrictions to load some of it into VRAM and some into RAM
komandor_353 How big are your scenes and your assets? I mean, 6 GB is pretty big.
Also can you try to reduce the number of scenes or assets a bit and then check the profiler to see where all this resource usage is coming from and if you can reduce it somehow by for example manually unloading scenes or something along those lines?
Toxe I've been running tests so far. Just for fun I loaded the models even more in weight. I'm only running the models, no textures, audio, etc. They weigh 8.07 GB on HDD
Here are the results from gl_compability:
Property Value Min Max Difference
Private bytes, 17.41 GB, 17.41 GB, 17.41 GB, 17.41 GB, 68 kB
Virtual size, 22.29 GB, 22.29 GB, 22.32 GB, 32 MB
Working set, 12.18 GB, 12.17 GB, 12.32 GB, 155.37 MB
GPU:
GPU Dedicated memory 4.39 GB (stable)
GPU Shared memory 2.33 GB
GPU Commit memory 8.18 GB
And for Forward+
Property Value Min Max Difference
Private bytes, 9.39 GB, 9.39 GB, 9.39 GB, 9.39 GB, 96 kB
Virtual size, 14.33 GB, 14.33 GB, 14.36 GB, 24 MB
Working set, 4.88 GB, 4.48 GB, 4.88 GB, 403.89 MB
GPU:
GPU Dedicated memory 5.04-5.48 GB (needle chart, jumps)
GPU Shared memory 3.3 GB
GPU Commit memory 8.82 GB
kuligs2 but isnt the compatibility uses the CPU
What? No! Of course not. It just uses an older more widely 'compatible' graphics API.
OpenGL was the 'does everything for you(but almost never optimally)' API. Vulkan is the low-level 'you get access to everything, better know what you are doing or you'll be very veeery sorry' API.
Now if you want to software render OpenGL on a CPU you can use a special driver for it, slow as that would be. But that's a whole separate matter.
