Сообщения на форуме пользователя Andrey (25 стр.)
Проблема удаления элементов массива... | 7 янв. 2012 | 1:02 | #13 |
---|
gammaker
> а удалять из середины можно простым обменом элемента с последним, когда порядок
> не важен.
Зачем менять? Если можно еще быстрее: последний писать на место удаляемого.
> а удалять из середины можно простым обменом элемента с последним, когда порядок
> не важен.
Зачем менять? Если можно еще быстрее: последний писать на место удаляемого.
Реализация класса вершинного буфера в движке. | 7 янв. 2012 | 0:47 | #19 |
---|
Технарь
> CVertexBuffeк9::Free
А если это вызывать более 1 раза ???
> CVertexBuffeк9::Free
А если это вызывать более 1 раза ???
nvidia cg. Юзать или нет? | 5 янв. 2012 | 23:58 | #1 |
---|
Imaginary unit
http://www.gamedev.ru/code/forum/?id=154893
> Какие минусы? Перфоманс?
Если не использовать Cg Run Time(а его лучше не использовать об этом выше почитай я давал ссылки на nVidia форум), то нужно писать самому получения параметров из GLSL кода, выданного Cg компилятором, я написал это, к тому-же добавил правку с добавлением UBO.
http://www.gamedev.ru/code/forum/?id=154893
> Какие минусы? Перфоманс?
Если не использовать Cg Run Time(а его лучше не использовать об этом выше почитай я давал ссылки на nVidia форум), то нужно писать самому получения параметров из GLSL кода, выданного Cg компилятором, я написал это, к тому-же добавил правку с добавлением UBO.
Правильная замена glDrawElementsBaseVertex | 5 янв. 2012 | 23:09 | #20 |
---|
innuendo
> один раз ставишь, потом индексами рулишь ( если они, конечно, 32 битные :) )
> ...
Невнимательно почитал первый пост. там 1 индексный буфер. Двигают смещением вершин.
> один раз ставишь, потом индексами рулишь ( если они, конечно, 32 битные :) )
> ...
Невнимательно почитал первый пост. там 1 индексный буфер. Двигают смещением вершин.
Правильная замена glDrawElementsBaseVertex | 3 янв. 2012 | 13:54 | #13 |
---|
Sergio
>decl.numElements()
тут сколько атрибутов ?
>const VertexElement& e = decl.element(i);
Что внутри decl.element(i); ?
>size_t dataOffset = index * (decl.interleaved() ? decl.dataSize() : vertexAttributeTypeSize(e.type) );
Замерь время выполнения твоих расчетов указателей. + проверки внутри цикла. Не думаю что там проблема. Но тут имеет место небольшой код на CPU. Может он и отнимает время? Хотя там вроде нечему.
Предлагаю что-бы развеять сомнения хранить для патчей пред рассчитанные смещения. Тогда только остается только частые вызовы Run Time.
По идее к примеру для 30 патчей ландшафта ты вызываешь:
30 * NumAttributes вызовов glVertexAttribPointer. В случае с glDrawElementsBaseVertex это делается 1 раз.
>decl.numElements()
тут сколько атрибутов ?
>const VertexElement& e = decl.element(i);
Что внутри decl.element(i); ?
>size_t dataOffset = index * (decl.interleaved() ? decl.dataSize() : vertexAttributeTypeSize(e.type) );
Замерь время выполнения твоих расчетов указателей. + проверки внутри цикла. Не думаю что там проблема. Но тут имеет место небольшой код на CPU. Может он и отнимает время? Хотя там вроде нечему.
Предлагаю что-бы развеять сомнения хранить для патчей пред рассчитанные смещения. Тогда только остается только частые вызовы Run Time.
По идее к примеру для 30 патчей ландшафта ты вызываешь:
30 * NumAttributes вызовов glVertexAttribPointer. В случае с glDrawElementsBaseVertex это делается 1 раз.
Загадочные падения после Lock | 30 дек. 2011 | 0:22 | #1 |
---|
Barbar1an
Буфер правильно создан? В каком пуле? DxDebug поможет тебе.
Буфер правильно создан? В каком пуле? DxDebug поможет тебе.
Быстрые деревья С++. Потестим скорость ? | 25 дек. 2011 | 22:17 | #30 |
---|
DevilDevil
> в чём преимущество деревьев над хэш-таблицами ?
Под конкретный набор данных можно подобрать хорошую хешь функцию, имеющую хорошее распределение минимум и коллизий. С деревом будет всегда логарифмическая сложность.
> в чём преимущество деревьев над хэш-таблицами ?
Под конкретный набор данных можно подобрать хорошую хешь функцию, имеющую хорошее распределение минимум и коллизий. С деревом будет всегда логарифмическая сложность.
Быстрые деревья С++. Потестим скорость ? | 25 дек. 2011 | 20:29 | #14 |
---|
Sbtrn. Devil
> А к хэш-таблицам у меня нет доверия. У них слишком мутный принцип работы, и при
> этом их подозрительно превозносят.
У хеш-таблицы реализация проще чем у дерева, одна балансировка чего стоит.
> А к хэш-таблицам у меня нет доверия. У них слишком мутный принцип работы, и при
> этом их подозрительно превозносят.
У хеш-таблицы реализация проще чем у дерева, одна балансировка чего стоит.
Вышел C11 (C1X) | 24 дек. 2011 | 20:46 | #12 |
---|
Chipmunk
> NULL_PTR
> > Поддержка многопоточности
> в смысле?
http://ru.wikipedia.org/wiki/C1X
Поддержка многопоточности, для этого в стандарт добавили спецификатор типа _Thread_local, заголовочный файл <threads.h>, включающий в себя функции по созданию и управлению потоками, мьютексами, мониторами и функции управления хранилищем потока (англ. en:Thread-local storage). Также в C1X добавили квалификатор типа _Atomic и заголовочный файл <stdatomic.h> для непрерываемых операций доступа к объектам;
> NULL_PTR
> > Поддержка многопоточности
> в смысле?
http://ru.wikipedia.org/wiki/C1X
Поддержка многопоточности, для этого в стандарт добавили спецификатор типа _Thread_local, заголовочный файл <threads.h>, включающий в себя функции по созданию и управлению потоками, мьютексами, мониторами и функции управления хранилищем потока (англ. en:Thread-local storage). Также в C1X добавили квалификатор типа _Atomic и заголовочный файл <stdatomic.h> для непрерываемых операций доступа к объектам;
GL & texture streaming | 23 дек. 2011 | 10:40 | #8 |
---|
Outlaw
>ну как решение да, но это сильно windows specific, портить потом как?
Для разных платформ придется писать свою реализацию.
http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html
>ну как решение да, но это сильно windows specific, портить потом как?
Для разных платформ придется писать свою реализацию.
http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html
Как организовать поддержку шейдеров в движке? | 22 дек. 2011 | 17:56 | #129 |
---|
gammaker
> Понятно, а OpenGL ES тогда тут причём, о котором писал Z?
Как это причем? OpenGL и OpenGL ES (2.0 конечно) GLSL используют. Та принцип передачи констант одинаков. Реализация GLSL в драйвере конечно возможно разная.
> Понятно, а OpenGL ES тогда тут причём, о котором писал Z?
Как это причем? OpenGL и OpenGL ES (2.0 конечно) GLSL используют. Та принцип передачи констант одинаков. Реализация GLSL в драйвере конечно возможно разная.
Как организовать поддержку шейдеров в движке? | 22 дек. 2011 | 13:13 | #121 |
---|
innuendo
>ну в N раз повторю, достаточно немного подумать и никакой GL_ARB_uniform_buffer_object не нужен чтобы не слать по одной
это такой же геморой как получения констант GLSL из выхопа Cg. Так что в топку.
>тот же Cg очень даже неплохо работает и без регистров, в том же Сталкере нет привязки констант к регистрам - и ничего, работает :)
Еще раз Cg Run Time сидит в CPU, в топку его вместе с его не привязками к регистрам. А в Сталкере наверняка компилятор HLSL все последовательно с нулевого регистра и расположил все константы. Такое вполне возможно, я сам как-то проверял. Если это не так то плохо.
>ну в N раз повторю, достаточно немного подумать и никакой GL_ARB_uniform_buffer_object не нужен чтобы не слать по одной
это такой же геморой как получения констант GLSL из выхопа Cg. Так что в топку.
>тот же Cg очень даже неплохо работает и без регистров, в том же Сталкере нет привязки констант к регистрам - и ничего, работает :)
Еще раз Cg Run Time сидит в CPU, в топку его вместе с его не привязками к регистрам. А в Сталкере наверняка компилятор HLSL все последовательно с нулевого регистра и расположил все константы. Такое вполне возможно, я сам как-то проверял. Если это не так то плохо.
Как организовать поддержку шейдеров в движке? | 21 дек. 2011 | 22:33 | #112 |
---|
gammaker
> > Однако, если нужна поддержка OpenGL ES, дела обстоят немного сложнее - там нет
> > константнъх буферов и нет общих регистров.
> Что значит общих регистров?
Если ты в Direct3D9-11 поставил в первый регистр константу, то при смене шейдера новый шейдер про нее будет знать. В OpenGL это не работает или не гарантирует работу или как вендрозависимое поведение, ведь в GLSL убоали понятие регистро что очень очень зря на мой взгляд. Прямой аналог реализации шейдеров в Direct3D обеспечивают только расширение GL_ARB_vertex_program и GL_ARB_fragment_program, есть еще их расширенные улучшенные версии это GL_NV_fragment_program2 и GL_NV_vertex_program3 первые 2 уже устрели, вторые уже тоже ну и работают только на nVidia картах и на PlayStation3 через Cg.
> > Однако, если нужна поддержка OpenGL ES, дела обстоят немного сложнее - там нет
> > константнъх буферов и нет общих регистров.
> Что значит общих регистров?
Если ты в Direct3D9-11 поставил в первый регистр константу, то при смене шейдера новый шейдер про нее будет знать. В OpenGL это не работает или не гарантирует работу или как вендрозависимое поведение, ведь в GLSL убоали понятие регистро что очень очень зря на мой взгляд. Прямой аналог реализации шейдеров в Direct3D обеспечивают только расширение GL_ARB_vertex_program и GL_ARB_fragment_program, есть еще их расширенные улучшенные версии это GL_NV_fragment_program2 и GL_NV_vertex_program3 первые 2 уже устрели, вторые уже тоже ну и работают только на nVidia картах и на PlayStation3 через Cg.
Как организовать поддержку шейдеров в движке? | 21 дек. 2011 | 18:00 | #109 |
---|
gammaker
> Такой вариант я и использовал до того, как решил всё переделать. Он слишком
> кривой. Для каждого API пользователю движка придётся писать разный код. Для
> OpenGL придётся создавать шейдер так:
> Shader* shader=new Shader("shader.vs", "shader.ps");
> а для DirectX:
> Shader* shadervs=new Shader("shader.vs");
> Shader* shaderps=new Shader("shader.ps");
Ничего кривого оне вижу
Напиши отдельно интерфейс для загрузки шейдеров. А на вход подавай пути к файлам. в результате будет пара шейдеров. И уже не важно это GLSL программа содержащая 2 шейдера или отдельные шейдеры для Direct3D9/10.
> DirectX9 отличается от 10-го тем, что он не может хранить несколько буферов и
> их переключать, и их нужно пересылать?
Он отличается тем что там можно создать отдельно использую ID3DXConstantTable, или самому организуя массив все констант, далее слать их через IDirect3DDevice9::SetVertexShaderConstantF.
Direct3D10 сразу предлагает интерфейс ID3D10Buffer для обновления всех констант, ты его можешь залочить и обновить и т.д.
> Константы пересылать в буфер туда-сюда медленно. Допустим, есть два материала,
> использующие одни и те же шейдеры. Первый материал поменяет сразу все
> константы, потом второй поменяет все константы. Каждый кадр они будут меняться
> местами. Если можно сразу целыми буферами их пересылать, то нормально, а если в
> цикле по одной, то тормозно.
Организуй shared константы между шейдерами находящимися в разных материалах. Шейдер будет по флагу узнавать обновилась ли одинаковая константа другим шейдеров или нет, он ее и слать не будет. Все это нужно мерить профайлером. Может можно всегда слать все и не обновлять и не делать проверки, усложняя этим код. Что-бы не слать по одной константе, объеденяй константы по признаку обновления и шли кусками в пределах общего списка констант.
Кстати не забывай про GL_ARB_uniform_buffer_object для GLSL что-бы не слать по одной.
> Такой вариант я и использовал до того, как решил всё переделать. Он слишком
> кривой. Для каждого API пользователю движка придётся писать разный код. Для
> OpenGL придётся создавать шейдер так:
> Shader* shader=new Shader("shader.vs", "shader.ps");
> а для DirectX:
> Shader* shadervs=new Shader("shader.vs");
> Shader* shaderps=new Shader("shader.ps");
Ничего кривого оне вижу
Напиши отдельно интерфейс для загрузки шейдеров. А на вход подавай пути к файлам. в результате будет пара шейдеров. И уже не важно это GLSL программа содержащая 2 шейдера или отдельные шейдеры для Direct3D9/10.
> DirectX9 отличается от 10-го тем, что он не может хранить несколько буферов и
> их переключать, и их нужно пересылать?
Он отличается тем что там можно создать отдельно использую ID3DXConstantTable, или самому организуя массив все констант, далее слать их через IDirect3DDevice9::SetVertexShaderConstantF.
Direct3D10 сразу предлагает интерфейс ID3D10Buffer для обновления всех констант, ты его можешь залочить и обновить и т.д.
> Константы пересылать в буфер туда-сюда медленно. Допустим, есть два материала,
> использующие одни и те же шейдеры. Первый материал поменяет сразу все
> константы, потом второй поменяет все константы. Каждый кадр они будут меняться
> местами. Если можно сразу целыми буферами их пересылать, то нормально, а если в
> цикле по одной, то тормозно.
Организуй shared константы между шейдерами находящимися в разных материалах. Шейдер будет по флагу узнавать обновилась ли одинаковая константа другим шейдеров или нет, он ее и слать не будет. Все это нужно мерить профайлером. Может можно всегда слать все и не обновлять и не делать проверки, усложняя этим код. Что-бы не слать по одной константе, объеденяй константы по признаку обновления и шли кусками в пределах общего списка констант.
Кстати не забывай про GL_ARB_uniform_buffer_object для GLSL что-бы не слать по одной.
Как организовать поддержку шейдеров в движке? | 21 дек. 2011 | 16:50 | #106 |
---|
gammaker
> Вопрос вот в чём: не займут ли эти программы много памяти и времени на
> создание\переключение?
Вот тут поподробнее.
> И как сделать подобное на Direct3D 9 с тем же интерфейсом? В нём ведь нет
> никаких программ. Придётся дублировать передачу одних и тех же констант в
> разные шейдеры, а при смене материала каждый раз менять туда-сюда константы? Мне кажется, это будет очень тормозно.
К примеру имеем интерфейс Render. От него наследники OpenGL,D3D9,D3D10
ест внешний вызов
render->SetPixelShader(ps);
render->SetVertexShader(vs);
в D3D9,D3D10 все будет нормально, а вот в OpenGL сохраняешь текущий шейдер, он же GLSL и он-же один и тот-же, т.е. что пиксельный что вершинный. Если поставили вершинный то пиксельный не ставим(ведь один и тот-же слинкованный в одну общую GLSL программу) и наоборот. Вот тебе и ушло дублирование констант и повторная установка. В реализации это выглядит примерно так:
Насчет тормознутости не совсем понятно
>Или там есть какие-то буферы констант, которые можно отдельно заполнять и переключать? Слышал, что в версии 10 они появились, а в 9-м вроде нету.
Есть там все. В Direct3D9 заводишь общий буфер под все константы шлешь за 1 вызов(если все изменились).
Иначе обновляешь некий список только измененных констант и шлешь их по отдельности, где возможно, объединяешь, если значение стартовые регистр + размер константы совпадает со стартовым регистром другой константы. Это примерный аналог буферов в Direct3D10.
>так как шейдеры не спрячешь внутрь движка за интерфейсом.
Отлично прячутся у меня GLSL + ARB + HLSL(D3D9,D3D10)
>Сразу говорю: CG мне не подходит, так как по религиозным причинам не хочу таскать с движком ничего лишнего - всё должно быть своё.
Да пожалуйста только вот шейдеры будешь для разных API писать разные
> Вопрос вот в чём: не займут ли эти программы много памяти и времени на
> создание\переключение?
Вот тут поподробнее.
> И как сделать подобное на Direct3D 9 с тем же интерфейсом? В нём ведь нет
> никаких программ. Придётся дублировать передачу одних и тех же констант в
> разные шейдеры, а при смене материала каждый раз менять туда-сюда константы? Мне кажется, это будет очень тормозно.
К примеру имеем интерфейс Render. От него наследники OpenGL,D3D9,D3D10
ест внешний вызов
render->SetPixelShader(ps);
render->SetVertexShader(vs);
в D3D9,D3D10 все будет нормально, а вот в OpenGL сохраняешь текущий шейдер, он же GLSL и он-же один и тот-же, т.е. что пиксельный что вершинный. Если поставили вершинный то пиксельный не ставим(ведь один и тот-же слинкованный в одну общую GLSL программу) и наоборот. Вот тебе и ушло дублирование констант и повторная установка. В реализации это выглядит примерно так:
void OpenGLRender::SetPixelShader(Shader* vs) { if (curShader != vs) { vs->UpdateShaderParameters(); vs->Bind(); curShader = vs; } } void OpenGLRender::SetVertexShader(Shader* ps) { if (curShader != ps) { ps->UpdateShaderParameters(); ps->Bind(); curShader = ps; } }
>Или там есть какие-то буферы констант, которые можно отдельно заполнять и переключать? Слышал, что в версии 10 они появились, а в 9-м вроде нету.
Есть там все. В Direct3D9 заводишь общий буфер под все константы шлешь за 1 вызов(если все изменились).
Иначе обновляешь некий список только измененных констант и шлешь их по отдельности, где возможно, объединяешь, если значение стартовые регистр + размер константы совпадает со стартовым регистром другой константы. Это примерный аналог буферов в Direct3D10.
>так как шейдеры не спрячешь внутрь движка за интерфейсом.
Отлично прячутся у меня GLSL + ARB + HLSL(D3D9,D3D10)
>Сразу говорю: CG мне не подходит, так как по религиозным причинам не хочу таскать с движком ничего лишнего - всё должно быть своё.
Да пожалуйста только вот шейдеры будешь для разных API писать разные