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

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

Страницы: 116 17 18 1922 Следующая »
#240
22:37, 13 ноя. 2019

assiduous
gpuopen по работе


#241
19:19, 18 ноя. 2019

assiduous
А почему не сделать установку uniform-ов по именам (OpenGL style) на уровне контекста? Все равно это придется делать..Вообще есть те, кто в большом проекте руками создают структуры под константы, мапят их, следят за выравниванием?

#242
(Правка: 20:20) 20:19, 18 ноя. 2019

xruck
> А почему не сделать установку uniform-ов по именам (OpenGL style) на уровне
> контекста?
А какая польза от такой абстракции? В современных API uniform buffer - это имеено буфер, т.е. просто участок памяти. Какая у этой памяти структура - решать приложению, это не должно быть заботой API. Забота API - предоставить средства для обновления этого участка памяти. Не говоря уже о том, что такая абстракция потребует много накладных расходов. Например, ты захотел одину матрицу обновить, и что API должен с этим делать? Держать копию где-то в системной памяти? Сразу начать обновлять GPU буффер. Приложение все это само может сделать гораздо эффективнее.

И, кроме того, у меня примета, что если что-то сделано каким-то способом в OpenGL, значит 100% надо делать как-то по-другому.

xruck
> Все равно это придется делать..Вообще есть те, кто в большом проекте руками
> создают структуры под константы, мапят их, следят за выравниванием?
Решением этой проблемы является рефлекшн: шейдер может тебе сказать про каждый буфер, какие в нем элементы, их вырванивание и т.п.
Кроме того, очень часто шейедры генерятся из других представлений (шейдер граф и т.п.), поэтому ты сам изначально знаешь, какие ресурсы используются.

#243
20:34, 18 ноя. 2019

assiduous
> И, кроме того, у меня примета, что если что-то сделано каким-то способом в
> OpenGL, значит 100% надо делать как-то по-другому.
UBO спасет отца русской демократии, а FFP - должен умереть

#244
22:02, 18 ноя. 2019

assiduous
Хз мне было бы удобно. Зачем страдать

#245
22:11, 18 ноя. 2019

xruck
удобно != оптимально по производительности

#246
22:22, 18 ноя. 2019

Deamon
Понятно что оптимальней изучать машинные инструкции и писать на голом железе. Тут вопрос даже не удобства, а в принципе можно ли этим пользоваться в больших проектах. Сейчас этим возможно пользоваться если у тебя пара шейдеров: все структуры руками создал и все хорошо и оптимально. Но когда у тебя сотни шейдеров, уже будет накладно каждый раз руками создавать. Еще хуже становится когда несколько шейдеров расшаривают один буфер.

#247
22:47, 18 ноя. 2019

Deamon
> удобно != оптимально по производительности

можно примеры из своей практики?

#248
22:59, 18 ноя. 2019

xruck
> Еще хуже становится когда несколько шейдеров расшаривают один буфер.

ещё хуже когда код пишется в одной компании а используется в другой

#249
23:09, 18 ноя. 2019

xruck
> Вообще есть те, кто в большом проекте руками создают структуры под константы,
> мапят их, следят за выравниванием?

если рендер не сложный можно руками - сложные и гибкие используют рефлекшн

#250
(Правка: 23:22) 23:21, 18 ноя. 2019

assiduous
> И, кроме того, у меня примета, что если что-то сделано каким-то способом в
> OpenGL, значит 100% надо делать как-то по-другому.

троллишь ? mdi было в гл задолго до

assiduous
> Решением этой проблемы является рефлекшн: шейдер может тебе сказать про каждый
> буфер, какие в нем элементы, их вырванивание и т.п.
> Кроме того, очень часто шейедры генерятся из других представлений (шейдер граф
> и т.п.), поэтому ты сам изначально знаешь, какие ресурсы используются.

так тебе нужно что-то вроде мапы и всё такое

#251
0:08, 19 ноя. 2019

xruck
На уровне API нет таких объектов как матрицы, отдельные переменные и т.п. Есть область памяти в которую ты можешь записать данные. API так же может тебе сказать какую структуру данных ожидает шейдер - дальше задача приложения эти данные предоставить.

Как я уже сказал, реализация доступа к отдельным переменным очень сильно замедлит реализацию. Сейчас самый быстрый метод обновления буфера - мэппинг, при котором для буфера выделяется новый кусок памяти. Как только буфер размэплен, он может быть использован GPU и его нельзя больше обновить. Частичные обновления буфера потребуют кучи хаков, в результате быстрее работать точно не станет.

#252
0:20, 19 ноя. 2019

assiduous
> Как я уже сказал, реализация доступа к отдельным переменным очень сильно
> замедлит реализацию. Сейчас самый быстрый метод обновления буфера - мэппинг,
> при котором для буфера выделяется новый кусок памяти. Как только буфер
> размэплен, он может быть использован GPU и его нельзя больше обновить.
> Частичные обновления буфера потребуют кучи хаков, в результате быстрее работать
> точно не станет.

ох, кто говорит про частые обновления ? просто скрываются в драйвере теже хешмапы - потом при draw call делается один апдейт

#253
0:32, 19 ноя. 2019

innuendo
> ох, кто говорит про частые обновления ? просто скрываются в драйвере теже
> хешмапы - потом при draw call делается один апдейт
Diligent Engine изначально задумывался как explicit API. Задачи сделать ещё один OpenGL не было. Если приложение хочет делать отложенные обновления - пожалуйста, все что надо для этого есть (ну, или будет. До рефлекшна структуры константных буферов никак не дойдут руки). В любом случае, этого нет в D3D12 и Вулкане, на которые ориентирован API.

#254
0:34, 19 ноя. 2019

assiduous

как минимум теже пушконстанты говорят что не всё так однозначно в железе

Страницы: 116 17 18 1922 Следующая »
ПрограммированиеФорумГрафика