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?

                      Bug reports

                      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

                        • Toxe replied to this.

                          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.