Тёмная тема
- HolyDel
- Постоялец
>Может оно даже в худшем варианте всего лишь будет экономией на спичках?
ну я это пишу не для оптимизации по скорости. скорее для красоты кода.
>То есть если DSA это тупо обертка над bind-modify-unbind, и работает так
вполне возможно, но хочется верить что в новых версиях драйвера это пофиксят. и уже скомпиленное приложение станет работать быстрее магическим образом.
ну и конечно пачку юниформов передавать каждый по отдельности это бред. есть же UBO и всякие там SSBO
>покажи как оно это DSA выглядит хоть )
можно писать в ДВА раза меньше кода ))))
было:
glActiveTexture(GL_TEXTURE0 + layer); glBindTexture( target, handle);
стало:
glBindTextureUnit(layer, handle);
на самом деле шутки шутками, но код сверху еще и менял текущий текстурный юнит. что есть не гуд.
innuendo
В DX я вызову всего одну функцию Create*, для создания ресурса. Сколько функций мне надо вызвать в OGL чтобы создать текстуру? И мой вопрос был в том - эффективно ли DSA это делает.
То есть что будет эффективней работать:
Это, с DSA
glProgramUniform1f(progId, loc, x); glProgramUniform1f( progId, loc1, x); glProgramUniform1f( progId, loc2, x); glProgramUniform1f( progId, loc3, x); glProgramUniform1f( progId, loc4, x); glProgramUniform1f( progId, loc5, x);
или все таки это:
// временно переключаем стейт если он еще не стоит if (progId != currprog) glUseProgram( progId); // модифицируем glUniform1f( loc, x); glUniform1f( loc1, x); glUniform1f( loc2, x); glUniform1f( loc3, x); glUniform1f( loc4, x); glUniform1f( loc5, x); // возвращаем старый стейт если надо if ( progId != currprog) glUseProgram( currprog);
HolyDel
> ну и конечно пачку юниформов передавать каждый по отдельности это бред. есть же
> UBO и всякие там SSBO
это (и пост выше), это ванильный пример того как приходится один ресурс много модифицировать. Мне просто лень мозг напрягать чтобы написать более правдоподобную стену функций... Я думаю, мой вопрос и такой пример отражает
war_zes
> То есть если DSA это тупо обертка над bind-modify-unbind, и работает так
Я надеюсь, всё же драйверы пишут не дураки? Тем более, что DSA не только что появился, а издревле поддерживался всеми вендорами через расширение.
war_zes
> Это, с DSA
Это не DSA, оно ещё в OpenGL 4.1 появилось вроде.
HolyDel
То есть твой фреймворк теперь будет требовать OpenGL 4.5 для работы?
HolyDel
> glBindTextureUnit(layer, handle);
Значит всё-таки EXT расширение и DSA в ядре отличаются. В EXT_DSA эта функция называется glBindMultiTextureEXT, да ещё и target принимает.
war_zes
> В DX я вызову всего одну функцию Create*, для создания ресурса. Сколько функций
> мне надо вызвать в OGL чтобы создать текстуру? И мой вопрос был в том -
> эффективно ли DSA это делает.
Писал про стейт - теперь про ресурс
gammaker
>>Я надеюсь, всё же драйверы пишут не дураки?
Ну да, десять лет во всех паперах вендоры писали про ручное кеширование стейтов. Почему-то они до сих пор не догадались что это хорошо бы сделать на уровне драйвера (хотя в mesa как я вижу догадались)
gammaker
Ну вот смотри. есть объектная матрица меняющаяся каждый кадр. И вот ее засылаем через DSA. И вот тут как раз не хватает понимания как DSA работает внутри. Дело в том что DSA это же не просто красивый синтаксис, и его создали не только для того чтобы не писать одну лишнюю строчку, но и для того чтобы не сбивать текущие забинденные ресурсы.
То есть вопрос в том, как DSA влияет на текущий забинденный ресурс (не тот который ставим, а тот который уже стоит в видеокарте) того же типа. То есть в спеке только гарантируют что он вернет этот ресурс на место (собственно ради этого DSA и сделали).
То есть они могут брать текущий, сохранять его куда-то, ставить редактируемый, модифицировать его, затем возвращать ранее сохраненный. Но если это так - то это будет ужастный оверхед, особенно когда придется один и тот же стейт модифицировать много раз (тупо будет много лишней работы, так как DSA по спеке не сохраняет стейт который он редактировал, а сбрасывает его - unbind), то есть мой пример может начать работать так:
glProgramUniform1f(progId, loc, x) -> ->tempstate = GetState( ) ->BindState( progId) ->ModifyState( progId, loc, x) ->BindState( tempstate)
И так на каждый вызов DSA.
Но, дело в том что где-то (толи в спеке, толи в описании, толи на сайте opengl.org) я всеже встречал упоминание, что DSA не нужен текущий контекст, то есть он работает в обход контекста. Но я не очень четко пониманию роль контекста с позиции машины стейтов. Но возможно что там как раз нет никаких GetState() и BindState, а только ModifyState.
Так что вот и спрашиваю, как же оно все таки там внутри работает - эффективнее ручного кеширования или наоборот хуже
>То есть твой фреймворк теперь будет требовать OpenGL 4.5 для работы?
да, специфика продукта. железо под него можно выбирать.
gammaker
> Значит всё-таки EXT расширение и DSA в ядре отличаются. В EXT_DSA эта функция
> называется glBindMultiTextureEXT, да ещё и target принимает.
да. отличаются.
war_zes
> В DX я вызову всего одну функцию Create*, для создания ресурса. Сколько функций
> мне надо вызвать в OGL чтобы создать текстуру?
2-4.
возник вопрос:
есть функция:
void glTextureSubImage2D( GLuint texture, GLint level, GLint xoffset, GLint yoffset, GLsizei width, GLsizei height, GLenum format, GLenum type, const void *pixels);
она больше не принимает target. как мне теперь грузить cubemap -ы?
war_zes
> Но, дело в том что где-то (толи в спеке, толи в описании, толи на сайте
> opengl.org) я всеже встречал упоминание, что DSA не нужен текущий контекст, то
> есть он работает в обход контекста.
я сомневаюсь что это действительно так. разные ресурсы на разных контекстах могут иметь одинаковые имена, например "1".
таким образом без привязки к контексту мы не поймем что ето за ресурс. я хз почему нам не дают указатели. с ними бы и работали.
даже все вот эти bindless текстуры должны быть обявленны resident в каждом контексте где они используются. и ее 64 битный хендл судя по всему хранит в себе просто контекст и имя ресурс. или что то в этом роде.
innuendo
> Писал про стейт - теперь про ресурс
и что?
HolyDel
> 2-4.
В среднем - 7 (это я про старый вариант, без DSA). Генерация, бинд, заливка данных, установка параметров (фильтрация там и подобное)
war_zes
> > Писал про стейт - теперь про ресурс
> и что?
Ты уже определись что хочешь узнать :)
> В среднем - 7 (это я про старый вариант, без DSA). Генерация, бинд, заливка
> данных, установка параметров (фильтрация там и подобное)
Я надеюсь, это не 7 строк кода на КАЖДУЮ текстуру ? :):):)
>Так что вот и спрашиваю, как же оно все таки там внутри работает - эффективнее ручного кеширования или наоборот хуже
Забей уже. У тебя что-то медленно работает ?
innuendo
>>Ты уже определись что хочешь узнать :)
Чем отличается модифицирование текстуры через DSA от модифицирования блендинга через DSA?
Я хочу узнать как внутри работает DSA
innuendo
> Я надеюсь, это не 7 строк кода на КАЖДУЮ текстуру ? :):):)
Вообще-то на каждую
glGenTextures()
glBindTexture()
от 2 до не знаю сколько (в моем 2D движке их 4 штуки) glTexParameteri
glTexImage2D()
innuendo
>>Забей уже. У тебя что-то медленно работает ?
Тут вопрос в другом. Я уже написал в своем движке обычную (но няшную) систему кеширования, и по сути свой аналог DSA, поэтому стоит вопрос в другом - выбросить свой велосипед сократив количество лишнего кода, но при этом очень сильно переписывая нутро, или оставить все как есть, ибо оно не стоит того
war_zes
> от модифицирования блендинга через DSA?
Что это такое ? :)
> Я хочу узнать как внутри работает DSA
Это знают только девелоперы драйвера - тебе это знать вредно :)
> > Я надеюсь, это не 7 строк кода на КАЖДУЮ текстуру ? :):):)
> Вообще-то на каждую
> glGenTextures()
> glBindTexture()
> от 2 до не знаю сколько (в моем 2D движке их 4 штуки) glTexParameteri
> glTexImage2D()
Ну сделай себе
GLuint CreateTexture( ...)
и будет одна строчка ...
> Я уже написал в своем движке обычную (но няшную) систему кеширования
Твоя система кеширования сильно ускорила ?
HolyDel
> она больше не принимает target. как мне теперь грузить cubemap -ы?
glTextureSubImage3D
Тема в архиве.