Войти
ПрограммированиеФорумГрафика

Diligent Engine - современная кросс-платформенная низкоуровневая графическая библиотека (8 стр)

Страницы: 15 6 7 8 9 10 Следующая »
#105
(Правка: 20:06) 20:05, 3 июня 2019

assiduous
Такой вопрос по статье. тынц
В статье упоминается, что невозможно полностью отслеживать изменения состояния ресурсов "there is no way to efficiently solve resource management problem in a fully automate manner". Почему нельзя запоминать состояния ресурсов, и в случае изменения состояния выставлять барьер? Хотя бы в однопоточном случае.


#106
20:34, 3 июня 2019

assiduous
И что все-таки означает "автоматическое управлением состоянием"? То что везде мы пишем RESOURCE_STATE_TRANSITION_MODE_TRANSITION? Тогда зачем его явно писать, если неявно можно его всегда выставлять? Или я все же не понял и это ручное управление?

#107
20:52, 3 июня 2019

xruck
> В статье упоминается, что невозможно полностью отслеживать изменения состояния ресурсов "there is no way to efficiently solve resource management problem in a fully automate manner".

Это значит, что нет эффективного решения, а не то что его нет совсем.
Полностью автоматическое управление означает что ты пытаешься переписать Direct3D11 или OpenGL, что является заведомо провальным подходом. В случае многопоточной записи команд единственным решением является патчить записанные буфера в момент их отправки в очередь, так как состояния ресурсов были неизвестны в момент записи. Это в принципе невилирует все преимущества параллелизации.

Вместе с тем, во многих случаях автоматическое управление не является проблемой, и поэтому Diligent даёт пользователю возможность выбора и возможность ручной оптимизации барьеров (являющейся абсолютно необходимой в многопоточных ситуациях), если приложение может выполнить его более эффективно.

#108
22:36, 3 июня 2019

assiduous
А в однопоточном режиме такая схема работает? Многопоточность меня не интересует, в чем вотще смысл многопоточно добавлять команды

#109
22:51, 3 июня 2019

xruck
> в чем вотще смысл многопоточно добавлять команды
В чем смысл брать вулкан и делать фичикат? Тогда уж юзай opengl и не парься.

#110
(Правка: 4 июня 2019, 0:04) 22:56, 3 июня 2019

xruck
В однопоточном случае тоже могут быть преимущества. Например, ты отрендерил шадоу мапу, а потом рисуешь 50000 объектов с ней. В автоматическом режиме библиотека будет вынуждена для каждого объекта проверить состояние шадоу мапы. Проще один раз вручную перевести ее в нужное состояние и сказать библиотеке, что все уже как надо (или проверять, но только в дебаге).
Есть много других ситуаций, когда явные барьеры помогают.

#111
0:46, 4 июня 2019

assiduous
> Есть много других ситуаций, когда явные барьеры помогают.
Насколько я помню у тебя барьеры ставтся между всеми командами, что сразу же отключает распаралеливание команд на гпу. Причем барьер ставится даже между чтением и чтением.

> Например, ты отрендерил шадоу мапу, а потом рисуешь 50000 объектов с ней.
Можно сделать имутабельность и только в некоторых случаях делать мютабл и записывать, в любом случае ресурсов, которые меняются не так много и проверки достаточно быстрые.

Тот же Vulkan-EZ поддерживает многопоточность и растановку барьеров, только он достаточно медленый.
Я у себя немного оптимизировал и на трейсе дума 4 автоматическая растановка барьеров работала в 60фпс, причем 80% времени уходило на распаковку трейса и вызовы вулкана (тяжелые сабмиты и презенты). А у меня учитываются и сабренжи буфера, мипмэпы и слои текстуры. Без имутабельности все жутко тормозило, после оптимизаций стало терпимо, там есть еще куда оптимизировать, но пока для демок производительноти даже одного потока более чем достаточно.

#112
(Правка: 2:37) 1:16, 4 июня 2019

/A\
> Насколько я помню у тебя барьеры ставтся между всеми командами, что сразу же отключает распаралеливание команд на гпу. Причем барьер ставится даже между чтением и чтением.
Все, конечно, не настолько катастрофично. При таком подходе вообще невозможно было бы получить хоть сколько-то разумную производительность. На самом деле барьеры ставятся только когда состояние ресурса меняется с чтения на запись и наоборот, и уж конечно не между чтением и чтением.

>в любом случае ресурсов, которые меняются не так много и проверки достаточно быстрые.
Ресурсов, которые меняются, действительно не много, но команд которые их используют может быть много. Оверхед действительно небольшой, и для сотен команд разницы нет. Но когда речь идёт о десятках тысяч команд, разница может стать очень заметной.

#113
12:14, 4 июня 2019

assiduous
> Но когда речь идёт о десятках тысяч команд, разница может стать очень заметной.
Если там десятки тысяч дескриптор сетов, то уже без разницы, а если нет, то проходишь только по уникальным дескриптор сетам. Тем более можно сделать имутабл дескриптор сеты.
У тебя же CommitShaderResources как раз проходит по всем ресурсам.

Если у тебя буфер сначала читается как юниформ, а потом как storage, то это ведь разные состояния и между ними вставится барьер, так ведь? Вот это можно было оптимизировать.
И нигде не учитывается, что storage buffer/image может быть помечен в шейдере как readonly, получается между диспатчами компьют шейдеров с этими ресурсами всегда вставится барьер.

> При таком подходе вообще невозможно было бы получить хоть сколько-то разумную производительность.
Барьеры достаточно быстрые, а тормозит чаще всего рисование. Если между draw call'ами не ставить барьеры, то потеря производительности будет минимальна.

#114
18:01, 4 июня 2019

/A\
> Если там десятки тысяч дескриптор сетов, то уже без разницы, а если нет, то
> проходишь только по уникальным дескриптор сетам. Тем более можно сделать
> имутабл дескриптор сеты.
По идеи ты можешь сделать один большой дескриптор сет со всеми нужными ресурсами и закоммитить его один раз, а во всех командах использовать bindless подход. Не уверен, что ты имеешь в виду под имутабл дескриптор сетами, но в любом случае даже если сам сет никогда не меняется, состояние ресурса может измениться. Библиотека в любом случае для каждого ресурса должна проверить его состояние т.к., например, загрузка начальных данных в текстуру меняет ее состояние даже для иммутабл сета. Но я согласен, что можно больше трюков и оптимизаций добавить. Всяко в D3D11 и OpenGL их гораздо больше.

> У тебя же CommitShaderResources как раз проходит по всем ресурсам.
В автоматическом режиме - да.

> Если у тебя буфер сначала читается как юниформ, а потом как storage, то это ведь разные состояния и между ними вставится барьер, так ведь?
Да, это так, потому что чтение в шейдере требует

VK_ACCESS_SHADER_READ_BIT
флаг тогда как юниформ буфер ставит
VK_ACCESS_UNIFORM_READ_BIT
флаг. Добавка флага требует исполнение барьера.

> Вот это можно было оптимизировать. И нигде не учитывается, что storage buffer/image может быть помечен в шейдере как readonly, получается между диспатчами компьют шейдеров с этими ресурсами всегда вставится барьер.
Учитывается. Readonly storage буфера трактуются как шейдер ресурсы. Для них ставится только

VK_ACCESS_SHADER_READ_BIT
флаг и проверяется, если такой флаг уже есть.

> Барьеры достаточно быстрые, а тормозит чаще всего рисование. Если между draw call'ами не ставить барьеры, то потеря производительности будет минимальна.
Барьеры достаточно быстрые на CPU, но как ты сам верно заметил, они исключают параллелизацию команд на GPU, потому что могут вызывать pipeline flush.
У меня в одной из первоначальных рабочих версий динамические буферы были реализованы как обычные. Запись в такой буфер тербовала барьера, и использование его в шейдере еще одного. В таком режиме астероиды работали со скоростью 3 фпс, все из-за GPU. Без барьеров стало 250+ фпс.

#115
19:05, 4 июня 2019

assiduous
Под имутабл дескриптор сетами я имел ввиду, те которые содержат имутабл ресурсы, то есть никогда не придется проходить по этим ресурсам чтоб поставить барьеры. Например дескриптор сет с текстурами и юниформ буфером с host visible памятью, для таких не нужны барьеры.

> Да, это так, потому что чтение в шейдере требует
> VK_ACCESS_SHADER_READ_BIT
> флаг тогда как юниформ буфер ставит
> VK_ACCESS_UNIFORM_READ_BIT
> флаг. Добавка флага требует исполнение барьера.
Не совсем так, в доках сказано, что один раз использовав access mask изменения становятся видимы для всех последующих и не надо его заново указывать. То есть можно при первом барьере после записи сделать флуш кэша и в dstAccess указать все флаги, которые соответствуют usage буфера, тогда барьеров будет меньше.
К тому же, под виндой нвидиа и интел игнорируют access флаги, у них это атоматически происходит, видимо чтоб вулкан был более user friendly. Так что реально нужен только execution barrier, чтоб одновременного чтения и записи не было.

#116
19:49, 4 июня 2019

assiduous
А вобще классная либа, главное не переставай писать (когда разберусь наверно перейду на нее). И статьи заходят на ура

#117
20:53, 4 июня 2019

/A\
> Под имутабл дескриптор сетами я имел ввиду, те которые содержат имутабл ресурсы, то есть никогда не придется проходить по этим ресурсам чтоб поставить барьеры.
Вот именно для этого все команды принимают RESOURCE_STATE_TRANSITION_MODE. Если приложение знает, что барьеры не нужны - оно может запросто сказать об этом библиотеке. Для приложения это очень просто, а библиотеке меньше проблем с трекингом.
Можно было бы ввести дополнительные флаги для обозначения иммутабл SRB. Но это имело бы в точности тот же эффект, что вызов CommitShaderResources без TRANSITION флага.

> То есть можно при первом барьере после записи сделать флуш кэша и в dstAccess указать все флаги, которые соответствуют usage буфера, тогда барьеров будет меньше.
Я думал сделать так, но где-то вычитал, что рекомендуется ставить как можно меньше флагов и только нужные. Наверное, стоит действительно ставить сразу все возможные флаги чтобы уменьшить количество барьеров. От лишнего барьеа должно быть больше вреда чем от лишнего флага.

#118
20:55, 4 июня 2019

xruck
Спасибо :) В планах много всего, кроме того я ее сейчас обкатываю в одном коммерческом проекте. Так что перспективы пока неплохие

#119
21:02, 4 июня 2019

/A\
> Под имутабл дескриптор сетами я имел ввиду, те которые содержат имутабл ресурсы, то есть никогда не придется проходить по этим ресурсам чтоб поставить барьеры
Вообще-то я ещё немного над этим подумал, и понял, что это неплохая идея. Можно заставить библиотеку ругаться если для иммутабл SRB указан флаг TRANSITION. Надо будет добавить в API. Спасибо за совет!

Страницы: 15 6 7 8 9 10 Следующая »
ПрограммированиеФорумГрафика