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

Vulkan API (вышел!) (338 стр)

Страницы: 1337 338 339 340375 Следующая »
#5055
21:50, 28 янв. 2019

/A\
> о вроде forward быстрее

который + ?


#5056
22:20, 28 янв. 2019

innuendo
> который + ?
Который кластерный, это же idTech, там примерно тотже рендер что в думе, только получше.
И шейдеры теперь без дебажной инфы, читать тяжело, но на вид не силько отличаются от дума.

#5057
(Правка: 7:54) 7:53, 29 янв. 2019

Жаль что Vulkan API шейдеры нельзя использовать вместе с CUDA, и наоборот. Хотелось бы единый язык и для CUDA, и для Vulkan/SPIR-V. Чтобы даже наша сортировка Radix буквально не просто летало, а ревело от скорости с турбонаддувом, чтоб было миллиард в секунду!
Сортировка бобров... ЫХ!

#5058
8:41, 29 янв. 2019

amber3d
> мета-язык (на уровне ассемблера или IR кодов), а саму реализацию (библиотеку) этого API писали бы на уровне компиляторов C++
Не-не-не, Дэвид Блейн, не надо. Хватит того, что один и тот же код может выдавать разный результат на разных GPU и версиях драйверов (в этом треде уже были примеры, да и с другими GAPI такое бывает).

> NVCC и там используется именно хостовый и девайсовый компилятор
И перманентное отставание в поддержке актуальных версий хостовых компиляторов — поддержки Clang 7 нет до сих пор, MSVC 2017 без ограничения на номер "сервис-пака" добавили только в CUDA 10, переход на которую может быть по тем или иным причинам затруднителен, а до неё был цирк с конями из-за невозможности заранее узнать, изменится ли _MSC_VER после обновления студии.

IMHO, языко- и компиляторонезависимые API лучше примотанных скотчем "мета-языков".

#5059
(Правка: 18:35) 10:40, 29 янв. 2019

Dinosaur
> IMHO, языко- и компиляторонезависимые API лучше примотанных скотчем
> "мета-языков".
Хотя бы реализовали API который позволяет писать часть хостового кода в самом API и шейдерах, который при необходимости, может быть выполнен на GPU. Например участок кода, где "аллокация GPU кода, загрузка из указателя, сортировка, загрузка в указатель обратно". И чтобы это были действительно указатели, словно от std::vector, чтобы их попросту пускать в саму глубь API. И обидно что нету именно аллокации в коммандах данного API. И жаль что Vulkan API все еще плохо оптимизирован, вернее плохо-оптимизируемый.

Dinosaur
> Не-не-не, Дэвид Блейн, не надо. Хватит того, что один и тот же код может
> выдавать разный результат на разных GPU и версиях драйверов (в этом треде уже
> были примеры, да и с другими GAPI такое бывает).
Только что вспомнил. Так решать проблему нужно радикально - оптимизировать приложение и код прямо при запуске приложения! Запустил .exe, оно компилировалось, оптимизировалось и запустилось. Изменилась конфа ПК - снова запускаем .exe и ждем оптимизацию!

#5060
10:01, 13 фев. 2019

Я в задумчивости.
Как можно адекватным образом обеспечить динамическое количество объектов в сцене и при этом не перестраивать буфер команд каждый кадр, который же явно так и просится чтобы его не перестраивали?
И не окажется в конечном счете это дороже чем перестройка буфера команд?

#5061
(Правка: 10:47) 10:45, 13 фев. 2019

MikeNew
> Как можно адекватным образом обеспечить динамическое количество объектов в
> сцене и при этом не перестраивать буфер команд каждый кадр, который же явно так
> и просится чтобы его не перестраивали?
не перестраивать буфер команд можно только в синтетических демках, которые нельзя экстраполировать ни для каких реальных геймдев-нужд. в реальности же рендер строится гораздо сложнее — нужно не просто планировать сценарий построения буферов команд, но и стратегии построения, загрузки и байндинга дескриптор сетов, менеджмента рендерпассов и ещё миллион проблем реального рендера, которых в демках просто нет, потому что демки строятся как удобнее программисту, а не как нужно с точки зрения применения.

я, кстати, измерял производительность просто оверхеда на API вызовы в вулкане — 10000 дроколлов, каждый со своим уникальным набором шейдерных констант, буфер команд каждый кадр строится с нуля, рендерится примерно за 5мс на ноутбучной видюхе. то есть стратегии оптимизации уже совершенно другие по сравнению с legacy api рендерами.

#5062
11:51, 13 фев. 2019

Suslik
> я, кстати, измерял производительность просто оверхеда на API вызовы в вулкане —
> 10000 дроколлов, каждый со своим уникальным набором шейдерных констант, буфер
> команд каждый кадр строится с нуля, рендерится примерно за 5мс на ноутбучной
> видюхе. то есть стратегии оптимизации уже совершенно другие по сравнению с
> legacy api рендерами.
Угу.. я и сам заметил что комманд буфер строится адски быстро.. просто хотел развеять последние сомнения - думал вдруг люди как-то хитро обходятся подачей всего через юниформы, а я не в курсе.

#5063
12:39, 13 фев. 2019

Suslik
> не перестраивать буфер команд можно только в синтетических демках, которые
> нельзя экстраполировать ни для каких реальных геймдев-нужд
А в source engine умудряются переиспользовать команд буферы, но я пока не разбирался что именно в них хранится.
Но сама задача непростая и не факт что требует решения.

#5064
(Правка: 14:20) 14:18, 13 фев. 2019

Чтобы переиспользовать буферы комманд нужно переиспользовать буферы с памятью и иметь динамику на уровне данных. Плюс сами вызовы должны быть реализованы в виде комманд. И вообще есть Secondary Buffer который тоже следует использовать.
Вызов отрисовки должен быть один но объединенный, но вызовов загрузки и обработки данных может быть любое если асинхронное. Это как с bindless текстурами или ray-tracing (недавняя история тоже требует аналогичного подхода), все должно быть едино!

#5065
14:36, 13 фев. 2019

Ну вот например у нас есть тайл карты, где ландшафт, деревья и всякие статичные обекты, так просто записываем все в один secondary buffer и рисуем при необходимости. Только придется отказаться от кулинга отдельных объектов тайла, но многие гпу это делают хардварно.

#5066
15:04, 13 фев. 2019

MikeNew
> я и сам заметил что комманд буфер строится адски быстро..

ну так ... просто забросали массивчик данными :)

#5067
(Правка: 15:08) 15:04, 13 фев. 2019

Можно даже в буферы разбубенить эти деревья, ландшафты, статичные объекты. Сделать коллизии, потом раскуллить и расставить эти объекты для отрисовки. Суть в том, чтобы представить дерево не в виде дерева, а в виде некого немого объекта который потом "материализуется" т.е. обретет отрисованную геометрию. Тоже самое с ландшафтами, представив его в чанках и в высотах.
Даже при построении BVH это справедливо, ибо построение иерархии мало отличается от отрисовки по растру, за исключением того, что геометрию нужно сначала временно слить, потом построить его (иерархию).
Если есть инстансинг, это не совсем обязательно, а в случае RTX это предусмотрено в API.
То есть использовать шаблоны для дальнейшей отрисовки всяких объектов, либо же если единичны, то держать на готове сами объекты на отрисовку.
Несколько сложнее будет с уникальными объектами, аля Space Engineers, но и там можно представить блоки в блоках с одной и той же геометрией (хотя они поступают проще и делают единый объект).

#5068
13:17, 25 фев. 2019

Недавно вышел X4 Foundation, где только вулкан рендер. И реализация рендера оставляет желать лучшего.Даже рендердок не может долго дебажить, где-то портится память и все перестает работать. vktrace тоже не работает.
Выдает всего 30фпс в 4к даже в пустом космосе...
Недостатки:
- general layout для depth buffer
- барьер включают абсолютно все этапы (src = ALL_COMMANDS, dst = ALL_COMMANDS) и они даже не сгруппированы, то есть может подряд идти 2 таких барьера
- а еще у всех барьеров стоит флаг DEPENDENCY_BY_REGION, что не имеет смысла
- шейдеры с дебажной инфой и плохо оптимизированны
- очень много дескриптор сетов
- SSAO в полном разрешении, причем нужен только для кабины, где все статично, можно было запечь АО и сэкономить 3мс.

#5069
(Правка: 13:34) 13:30, 25 фев. 2019

/A\
> Недостатки:

ты поработай на реальном проекте - ещё не такое увидишь :)

хотя это Egosoft ...

Страницы: 1337 338 339 340375 Следующая »
ПрограммированиеФорумГрафика