Именно по-этому, свой говно код я пишу на сервере 1С с 196 ОЗУ и 2 х Xeon Gold 5218.
*ничего не понял, но восхищается*
А может кто-нибудь пояснить что это за "память процессора" исячисляющаяся гигабайтами?
снизу это график заполненности памяти на протяжении определённого времени. и эта память не процессора а ПРОЦЕССА, то-есть приложения. А исчисляется гигабайтами потому что для упрощения диспатчинга ресурсов GPU в VulkanAPI используюется дескриптор сеты, для которых нужно заранее подготовить память. В последствии это превращается в сильную боль потому-что для рендера большой сцены где много динамических и статических объектов требуется много ресурсов и соотвественно много дескриптор сетов (указателей на ресурсы, текстуры и буферы в которых хранятся данные). Старые API такие-как DX11 и OpenGL сами занимаются оптимизацией памяти и диспатчинга, соответственно они подбирают оптимальный объём памяти для сцены. в Vulkan это сделать очень сложно так-как весь data менеджмент ложится на программиста графического конвейера а он там low-level. Чтобы справится с этой задачей быстро, программисты на Vulkan обычно принимают решение заранее проалоцировать огромный descriptor pool в который можно пропушить кучу ресурсов без особых напрягов в оптимизации. Это выходит в такую копеечку, в виде 100мб на 1024 дескриптора, что просто **здец. (Ходят слухи что для сокращения памяти нужно отключить validation layers, ну я же мем делал)
Процесса. Ясно.
Чтобы написать коммент, необходимо залогиниться