Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Что печалит, так это то, что с каждой новой итерацией развития графических API — минимально рабочее приложение становится всё сложнее.
Vulkan судя по виду и не предназначен для рукопашного кодирования каждый раз. Это скорее «графический ассемблер», как когда-то называли OpenGL. Хотя в такой ситуации OpenGL переходит в лигу «графического Си».
На самом деле на ассемблере вот hello world тоже не так уж просто написать, но зато он напрямую в машинные команды транслируется. Тоже самое относится и ко всяким байткодам виртуальных машин.
Зато драйвер для вулкана смогли написать за год, а драйвер для openGL 4.5 до сих пор не все смогли.
Получается, когда наступит счастье основные вендоры реализуют поддержку Vulkan, можно будет иметь одну реализацию OpenGL поверх него?
Откуда такая уверенность в том, что драйвер для вулкана написан. В случае с NVidia, есть бета со скудным набором железа, начиная с GT6х серии, ито не полностью =) При этом моя карта хоть и должна была соответсвовать минимальным требованиям, но, что-то несраслось и ничего на заработало =) И что самое печальное, исправлять сие положение дел никто не собирается. В общем пока все плохо с дровами и обещанной совместимотью.
Кстати, в случае с ГЛ4.5 были драйверы для разработки которые моя карта поддреживала но в релиз они так и не вышли.
Итого одно растройство, вулкан не для нищебродов, покупайте современные 3д ускорители если хотите летать =)
Кстати, в случае с ГЛ4.5 были драйверы для разработки которые моя карта поддреживала но в релиз они так и не вышли.
Итого одно растройство, вулкан не для нищебродов, покупайте современные 3д ускорители если хотите летать =)
Я не слышал ни про кого, кому платят за рисование синих треугольников. А сложные приложения в любом случае писать сложно.
Есть такая штука — прототипирование.
Многим за него платят. И часто там ничего круче синих треугольников не нужно.
Многим за него платят. И часто там ничего круче синих треугольников не нужно.
Прототип можно и на OpenGL написать. Или вообще на каком-нибудь Cocoa2D. Многопоточный рендерер на Вулкане всегда требует очень обширного проектирования, чтобы появилось преимущество в производительности, а не чтобы было.
Полагаю — OpenGL накроется скоро медным тазом. Тем более проблемы совместимости за ним тянутся с 90х.
Тут сложный вопрос. Для 90% процентов есть готовые движки. 9% достаточно OpenGL 3.2, и в таком случае нет буквально ни одной причины не использовать именно его. Вот в 1% случаев, когда обязателен именно собственный убийца CryEngine\RenderMan по вкусу, я действительно не понимаю, чего ради начинать проект на D3D11 или опенгл4. Это заведомо уменьшает пределы возможностей движка, с которым жить много лет.
Vulkan API — можно сказать, наследник OpenGL.
Стоит упомянуть что API основано на технологии AMD Mantle и по сути Vulkan его потомок.
Стоит упомянуть что API основано на технологии AMD Mantle и по сути Vulkan его потомок.
Меня мучают такие вопросы.
1. Вот мы сами менеджим память. У меня ресурсы, которые нужны для рендрера фрейма полностью занимают скажем 600Мб, а на устройстве 512Мб физических. То есть на этапе рендера одного изображения я должен сам выгружать ресурсы, которые мне в данный момент не нужны, так?
2. Допустим теперь я хочу написать фреймворк, который предоставит более высокоуровневый интерфейс. Если я захочу спрятать код менеджмента ресурсов на девайсе — то мне фактически придется написать «умный» менеджер памяти (а чтобы был профит — не хуже того, что есть в OGL драйверах). Либо вытягивать потроха менеджмента ресурсов наружу фреймворка, так?
3. И самая большая сложность — это то, что я не знаю вообще ничего о других приложениях использующих видеокарту. Неизвстно нужно выгружать ресурсы, чтобы другие программы могли использовать память, или не нужно, им достаточно памяти, и я могу придержать текущую память для следующего фрейма. Получается раньше видеодрайвер знал все о окружении (был глобальным) и мог сам менеджить память, а сейчас мы попадаем в ситуацию когда мы этого делать не можем. Я очень надеюсь что я ошибаюсь… но это так или нет?
1. Вот мы сами менеджим память. У меня ресурсы, которые нужны для рендрера фрейма полностью занимают скажем 600Мб, а на устройстве 512Мб физических. То есть на этапе рендера одного изображения я должен сам выгружать ресурсы, которые мне в данный момент не нужны, так?
2. Допустим теперь я хочу написать фреймворк, который предоставит более высокоуровневый интерфейс. Если я захочу спрятать код менеджмента ресурсов на девайсе — то мне фактически придется написать «умный» менеджер памяти (а чтобы был профит — не хуже того, что есть в OGL драйверах). Либо вытягивать потроха менеджмента ресурсов наружу фреймворка, так?
3. И самая большая сложность — это то, что я не знаю вообще ничего о других приложениях использующих видеокарту. Неизвстно нужно выгружать ресурсы, чтобы другие программы могли использовать память, или не нужно, им достаточно памяти, и я могу придержать текущую память для следующего фрейма. Получается раньше видеодрайвер знал все о окружении (был глобальным) и мог сам менеджить память, а сейчас мы попадаем в ситуацию когда мы этого делать не можем. Я очень надеюсь что я ошибаюсь… но это так или нет?
1. Можно самостоятельно, можно доверить драйверу: память виртуализируется. В принципе, самым правильным вариантом может оказаться окошко с надписью «Выкинь свои дрова и купи видеокарту».
2. Если хотите повторить Direct3D 11, то будьте готовы повторить путь, который NVIDIA и AMD прошли за 8+ лет, всё просто. На самом деле, управление памятью — наименьшая проблема в Вулкане.
3. ОС может сказать, на какой объем памяти мы приблизительно можем рассчитывать. Всегда нужно быть готовым к тому, что запрос на выделение памяти вернет 0 и адекватно на это реагировать.
Вообще, вот: http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/03/d3d12_vulkan_lessons_learned.pdf
2. Если хотите повторить Direct3D 11, то будьте готовы повторить путь, который NVIDIA и AMD прошли за 8+ лет, всё просто. На самом деле, управление памятью — наименьшая проблема в Вулкане.
3. ОС может сказать, на какой объем памяти мы приблизительно можем рассчитывать. Всегда нужно быть готовым к тому, что запрос на выделение памяти вернет 0 и адекватно на это реагировать.
Вообще, вот: http://32ipi028l5q82yhj72224m8j.wpengine.netdna-cdn.com/wp-content/uploads/2016/03/d3d12_vulkan_lessons_learned.pdf
Vulkan может предоставить информацию о физическом устройстве.
Это типы памяти устройства (0, Device local, Cashed Host, Coherent Host) и кучи памяти (в которых указан индекс используемой памяти).
Информацию о свободной памяти мы получить не можем. Я раньше тоже задавался таким вопросом, на что получил примерно такой ответ: количество свободной памяти постоянно меняется и мы не можем предугадать, сколько будет использовано памяти потом. И, как уже было ранее сказано, всегда нужно быть готовым получить нулевой указатель, такая же фишка нужна и в обычных программах, которые динамически выделяют память (malloc, new).
Главное — это правильно управлять памятью, и не загружать всё подряд в память устройства. Нужно уметь распределять ресурсы между хостом (кэш) и устройством.
И последнее, если всё же действительно не хватает памяти, то есть sparse memory. Как точно работает такая память я пока ещё не в курсе.
Это типы памяти устройства (0, Device local, Cashed Host, Coherent Host) и кучи памяти (в которых указан индекс используемой памяти).
Информацию о свободной памяти мы получить не можем. Я раньше тоже задавался таким вопросом, на что получил примерно такой ответ: количество свободной памяти постоянно меняется и мы не можем предугадать, сколько будет использовано памяти потом. И, как уже было ранее сказано, всегда нужно быть готовым получить нулевой указатель, такая же фишка нужна и в обычных программах, которые динамически выделяют память (malloc, new).
Главное — это правильно управлять памятью, и не загружать всё подряд в память устройства. Нужно уметь распределять ресурсы между хостом (кэш) и устройством.
И последнее, если всё же действительно не хватает памяти, то есть sparse memory. Как точно работает такая память я пока ещё не в курсе.
Sparse memory — это частично не обеспеченный реальной памятью диапазон в виртуальной памяти. Запись туда игнорируется, чтение возвращает неопределенное значение. Т.е., если мы знаем, что 90% изображения не будет использоваться, мы создаем огромную текстуру, но реально занимать она будет пару мегабайт. Позволяет делать очень большие карты теней малыми затратами, например.
Главное — это правильно управлять памятью, и не загружать всё подряд в память устройства. Нужно уметь распределять ресурсы между хостом (кэш) и устройством.Так вот мне например все еще непонятно как это делать. Вот есть у нас 10 приложений, которые кушают видеопамять и съели её практически всю. Я запускаю одиннадцатое, и при попытке выделить память на девайсе говорят что она закончилась. А все потому что предыдущие 10 приложений не выгрузили свою память. Раньше за меня это сделал бы драйвер, он просто бы сам выгрузил память этих приложений, загрузил мою память, отрендерил. А сейчас что? Что мне, разработчику 11-го приложения делать? Как в старые добрые времена показывать пользователю мессадж бокс «Не хватает памяти. Закройте не нужные графические приложения.»?
Если речь идёт о приложениях, которые всё ещё работают и кушают память — да, придётся высвечивать то самое сообщение о нехватке памяти. А как иначе? Стоп, и с каких пор драйвер выгружает память? (Я про такое не в курсе)
Драйвер сам менеджит, какие ресурсы сейчас используются а какие нет. Скажем у вас 2Гб видеопамяти, и 11 запущенных приложений, каждое из которых требует 200Мб на текстуры. Несмотря на то, что памяти вроде как не хватает — приложения корректно работают. А все потому, что драйвер, подготавливает конвеер для рендера конкретного кадра конкретного приложения может выгрузить из резидентной памяти текстуры другого приложения.
Собственно сейчас все это происходит в момент биндинга текстур/буферов прозрачно для нас. Это одна из причин, почему биндинг такой дорогой, и почему bindless текстуры рвут обычные. Для bindless текстур мы биндим текстуру один раз, и потом «pointer» в видеопамяти используем без всяких оверхедов.
Вы даже можете насоздавать ресурсов больше 2Гб в одном приложении, и драйвер будет покорно работать за вас, до тех пор, пока видеопамяти хвататет, чтобы разместить все ресурсы необходимые на очередной дравколл.
В DirectX9 раньше разработчик мог указывать, кто будет менеджить ресурсы:
https://msdn.microsoft.com/en-us/library/windows/desktop/ee418784%28v=vs.85%29.aspx
Но потом видимо системной памяти стало много, и в DirectX10 и выше все ресурсы стал менеджить драйвер (на уровне WDDM):
https://msdn.microsoft.com/en-us/library/windows/hardware/ff568683%28v=vs.85%29.aspx
В OGL этот менеджмент был всю жизнь изкоробки, пока bindless текстуры не завезли.
Ну а в Vulkan я чет не представляю как это теперь разруливать. Хотя возможно драйвер будет так же пейджить ресурсы, как он делает это сейчас.
Собственно сейчас все это происходит в момент биндинга текстур/буферов прозрачно для нас. Это одна из причин, почему биндинг такой дорогой, и почему bindless текстуры рвут обычные. Для bindless текстур мы биндим текстуру один раз, и потом «pointer» в видеопамяти используем без всяких оверхедов.
Вы даже можете насоздавать ресурсов больше 2Гб в одном приложении, и драйвер будет покорно работать за вас, до тех пор, пока видеопамяти хвататет, чтобы разместить все ресурсы необходимые на очередной дравколл.
В DirectX9 раньше разработчик мог указывать, кто будет менеджить ресурсы:
https://msdn.microsoft.com/en-us/library/windows/desktop/ee418784%28v=vs.85%29.aspx
Но потом видимо системной памяти стало много, и в DirectX10 и выше все ресурсы стал менеджить драйвер (на уровне WDDM):
https://msdn.microsoft.com/en-us/library/windows/hardware/ff568683%28v=vs.85%29.aspx
В OGL этот менеджмент был всю жизнь изкоробки, пока bindless текстуры не завезли.
Ну а в Vulkan я чет не представляю как это теперь разруливать. Хотя возможно драйвер будет так же пейджить ресурсы, как он делает это сейчас.
Понял, о чём ты. Ну, я могу ответить так: Vulkan явно не для того, чтобы запускать 11 приложений параллельно (или типа того). Для этого есть тот же самый DX или OGL. Vulkan же, как упоминалось ранее — «графический ассемблер», который позволяет выжимать максимум производительности для приложения.
Но если всё же приложению действительно нужно жить параллельно с другими, то не думаю, что Vulkan (по крайней мере сейчас) подойдёт для этого дела.
И всё же, задам странный вопрос: зачем запускать столько?
Но если всё же приложению действительно нужно жить параллельно с другими, то не думаю, что Vulkan (по крайней мере сейчас) подойдёт для этого дела.
И всё же, задам странный вопрос: зачем запускать столько?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Vulkan API (glNext) от Khronos Group