Wie gesagt, das kann auch daran liegen das die Engine entscheidet keine Daten zu schaufeln weil der Speicherpool große genug ist. Heißt aber im Umkehrschluss nicht das die Engine auch wirklich soviel benötigt und nicht auch mit 4GB alles problemlos darstellen kann.
Stimmt bei allen Grafik-APIs außer Vulkan und DX12 eher nicht! Denn nur da kann die Engine überhaupt selbst die Speicherverwaltung im Bezug auf VRAM vornehmen. Das ist ein großer Vorteil der LowLevel-APIs.
Code:
pD3D11Device->CreateTexture2D(&desc, nullptr, &textureptr);
Wie man sehen kann, wird im Fall von DX11 nicht gefragt, wie viel Speicher auf der Karte reserviert werden soll, sondern einfach eine Referenz auf einen Zeiger auf den Speicherbereich der Textur übergeben. Wollte die Engine mit den alten APIs Speicher frei machen, wäre es somit nur über Qualitätsreduzierung, wie austauschen von hochauflösenden Texturen gegen schlechtere, möglich, wie es ja auch bei vielen Engines stattfindet. Ich denke, dass das nicht in Deinem Sinn wäre und Du es dann auch nicht mehr "problemlos" nennen würdest, denn die Engine hat dann erhebliche Probleme, die auch auf die Spielerfahrung gehen.
Bei Vulkan kann man dagegen den Vulkan Memory Allocator benutzen, um Speicher zu reservieren. Man kann dadurch aber auch komplett grundlos Speicher ohne Inhalt reservieren
(Das tut man natürlich nicht, aber wäre möglich...)
Beim System-RAM ist das etwas anders. Natürlich musst Du aber die reservierten Speicherbereiche auch beim normalen PC-RAM trotzdem vorhalten, da rein theoretisch zu irgendeinem Zeitpunkt alle Variablen usw. gleichzeitig in Benutzung sein könnten. Hat man eine Swap-Partition, bzw. Auslagerungsdatei, kann man den RAM etwas enger bemessen, muss dann aber auch mit dem Risiko leben, dass die Performance schlechter werden kann, da eine SSD und erst recht eine Festplatte, wo die Daten dann auch hinkommen, deutlich langsamer ist.
Optimalerweise hat man folglich mindestens so viel RAM, wie das hungrigste Programm, das man laufen lässt, reserviert. Meiner Meinung nach sind 32 GiB da aktuell ungefähr die Grenze, die nur wenige Spiele überschreiten und somit wahrscheinlich der Optimalzustand im Bezug auf Bedarf/Kosten.
Gerade bei hohen Speicherpreisen mag man sich einreden, man bräuchte sowieso weniger RAM als reserviert wird und das hätte keinen Einfluss auf die Performance, aber so schön ist es dann doch nicht.
Und ja, es gibt heutzutage viele Grotten-Programmierer, die für Dinge, die z.B. mit 8 Byte gehen würden, 256 Byte verbraten. Wenn sich das dann langfristig fortsetzt, rotzt das Spiel den ganzen Hauptspeicher unnötig voll. Wobei natürlich die Programmierer häufig auch unter Zeitdruck stehen und gar nicht so viel Zeit für Optimierungen bekommen...
Aber leider ist das Kind dann nach dem Kompilieren bereits in den Brunnen gefallen und man kann nichts mehr dagegen tun, außer Patches zu liefern.
