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

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

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

amber3d
> Шейдеры тоже лучше бы переложили бы на другой язык, кроме GLSL
Там SPIRV вообще-то

> Я в целом, заметил, что народы на Gamedev.ru отстали от жизни.
Что мне делать чтоб догнать жизнь?


#5056
17:49, 28 янв. 2019

/A\
> Там SPIRV вообще-то

Я имею ввиду язык исходного кода. Да есть HLSL, но не решает фундаментальной проблемы единства кода, да и нету расширений вроде "GL_NV_shader_subgroup_partitioned"

#5057
(Правка: 17:55) 17:52, 28 янв. 2019

GLSL\HLSL это барьер для того чтобы программисты не вышли за забор конюшни.
Как бы это не звучало грустно.
Но это в угоду стандартам для всех.

Хотя всякие там ушлые NVIDIA, нет-нет да и пропихнут кое чего эдакого в забор :)
Каверзные свои расширения.

#5058
17:55, 28 янв. 2019

amber3d
> Я имею ввиду язык исходного кода.
Я тут не так давно кидал ссылку на компилятор С++ в spirv.
Так что при желании можно сделать все что угодно.

#5059
19:07, 28 янв. 2019

1 frag / 2 deaths
> Я том, что в коде используются 3 значения из массива, но массив выделяется
> целиком для каждого "потока" поэтому дикая просадка по производительности.
> Потому и спрашиваю, нахрена тут массив
Это синтетический пример, который показывает как снижается производительность при снижении количества варпов из-за недостатка регистрового файла.

#5060
21:50, 28 янв. 2019

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

который + ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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