видеопамяти?
возможно из-за помех
причём в самых первых видяхах с 3D-ускорителем они таки были
ну у них тогда и частоты пониже, наверняка, были
когда-то давно были вроде
вопрос скорее в том, почему нет сейчас?
Потому что у видюх очень кастомная архитектура и прямой доступ к памяти, если сделать память изменяемой, то появится возможность устраивать очень нетривиальные segfault'ы.
+ имхо, любой слот по идее есть интерфейс передачи, что может быть боттлнеком серьезным
А это +1 уровень усложнения к компиляторами для видюх.
Так память в этом случае же всё равно постоянная, речь же не о горячей замене.. У меня в голове по крайней мере это выглядит как "при инициализации драйвера собрал инфу о памяти и учёл при работе" Понятно что там несколько больше параметров чем просто тайминги, объём, частота. Но всё равно это не кажется адекватной причиной. К тому-же можно просто ещё более анально залочить возможность комбинаций (чем на цпу) и ещё сильнее упростить. Скорее так проще зарабатывать. Да и смысла в наращивании объёма видеопамяти особо и нету.. Там же всё скорее в другие параметры упирается.
не очень понял что тут написано, но кажется, написана чепуха
Горячей замены нет, только код теперь не может полагаться на то, что объём памяти - это статически заданный параметр компиляции.
Почему не может то? Объём заранее известен и будет известен до конца работы.
Работы программы, но не во время компиляции
GL4.5 компиляет код на ходу, SPIRV ясен хер уже не зависит от объёма при выполнении, ибо переносим. О чём речь то? Какая такая компиляция?
Обсуждают сегодня