Сообщения на форуме пользователя Andrey (15 стр.)
Render Ops | 6 июля 2012 | 11:42 | #55 |
---|
Executor
>Для каждого ропа?
> То есть каждый кадр аллокация параметров для каждого ропа со своим количеством
> параметров или как?
Ты шейдера загрузил, с ними же для параметров шейдера сделал аллокацию, зачем что-то аллоцировать повторно? При инициализации ROP ему ссылку на шейдер сохраняют шейдер про свои параметры знает,памятью уже аллоцирована и скольно нужно не больше не меньше. на размер ROP это не влияет, число uniform не ограничено.
>Каждому объекту надо задать свой рандомный цвет, который передаётся через юниформ. Как это реализовано в ропах?
Ага вот тут уже сложнее! Значит расширяем шейдерную систему таким образом, что есть параметры обновляемые Render'ом - матрицы и т.д.(автоматические) И те параметры, которые обновляются, допустим игровой логикой(User Parameters). В таком случае при отрисовке ROP нужно по ссылке на эти User Parametr'ы нужно обновить их для шейдера.
Хранить User параметры можно прямо в материале, т.к. ROP знает про материал, то при отрисовке ROP значение рандомного цвета запишется в параметры шейдера напрямую, и два наших объекта будут рисоваться с разными цветами. В двух подходах размер ROP неизменен.
Память под все шейдерные параметры опять таки выделяется при загрузке.
>Для каждого ропа?
> То есть каждый кадр аллокация параметров для каждого ропа со своим количеством
> параметров или как?
Ты шейдера загрузил, с ними же для параметров шейдера сделал аллокацию, зачем что-то аллоцировать повторно? При инициализации ROP ему ссылку на шейдер сохраняют шейдер про свои параметры знает,памятью уже аллоцирована и скольно нужно не больше не меньше. на размер ROP это не влияет, число uniform не ограничено.
>Каждому объекту надо задать свой рандомный цвет, который передаётся через юниформ. Как это реализовано в ропах?
Ага вот тут уже сложнее! Значит расширяем шейдерную систему таким образом, что есть параметры обновляемые Render'ом - матрицы и т.д.(автоматические) И те параметры, которые обновляются, допустим игровой логикой(User Parameters). В таком случае при отрисовке ROP нужно по ссылке на эти User Parametr'ы нужно обновить их для шейдера.
Хранить User параметры можно прямо в материале, т.к. ROP знает про материал, то при отрисовке ROP значение рандомного цвета запишется в параметры шейдера напрямую, и два наших объекта будут рисоваться с разными цветами. В двух подходах размер ROP неизменен.
Память под все шейдерные параметры опять таки выделяется при загрузке.
Правка: 6 июля 2012 11:44
Render Ops | 6 июля 2012 | 11:03 | #51 |
---|
innuendo
> Кстати, может анизотропку включать\выключать по ориентации в пространстве или
> там признаку (пол\потолок) ?
Наверное не стоит, уже перебор.
> Кстати, может анизотропку включать\выключать по ориентации в пространстве или
> там признаку (пол\потолок) ?
Наверное не стоит, уже перебор.
Render Ops | 6 июля 2012 | 11:02 | #50 |
---|
innuendo
> Какие RasterOps в материале ?
CullFace, Blend,DepthFunc(хотя это лишнее возможно), DepthWrite/DepthTest
>А если, например, материал многослойный ?
приведи пример, вообще я бы разбил его, возможно и не нужно так усложнять, на уровне экспорта данных нужно это упрощать. Не нужно движку так сложно с материалом работать.
> Какие RasterOps в материале ?
CullFace, Blend,DepthFunc(хотя это лишнее возможно), DepthWrite/DepthTest
>А если, например, материал многослойный ?
приведи пример, вообще я бы разбил его, возможно и не нужно так усложнять, на уровне экспорта данных нужно это упрощать. Не нужно движку так сложно с материалом работать.
Render Ops | 6 июля 2012 | 10:58 | #48 |
---|
Executor
> float4 vs_uniforms[256];
> float4 ps_uniforms[256];
Ну это конечно неверно в корне.
>И всё равно не особо и универсально, а если захочется 1024 регистра в VS послать? Обломс?
Я же говорил храни ссылки, может храни индексы на Lokup Table, пересмотри серьезно структуры данных. innuendo предложил хорошее решение в 45 посту.
У меня в шейдере есть класс ShaderParameters - там все константы для шейдера, их обновляет Render перед отрисовкой ROP. И не важно сколько там констант, причем на размер ROP это не влияет.
> float4 vs_uniforms[256];
> float4 ps_uniforms[256];
Ну это конечно неверно в корне.
>И всё равно не особо и универсально, а если захочется 1024 регистра в VS послать? Обломс?
Я же говорил храни ссылки, может храни индексы на Lokup Table, пересмотри серьезно структуры данных. innuendo предложил хорошее решение в 45 посту.
У меня в шейдере есть класс ShaderParameters - там все константы для шейдера, их обновляет Render перед отрисовкой ROP. И не важно сколько там констант, причем на размер ROP это не влияет.
Render Ops | 6 июля 2012 | 10:53 | #46 |
---|
innuendo
>А что есть материал ?
Textures(с параметрами фильтрации, параметры адресации, параметры отключение анизотропной по расстоянию),shaders(вместе с их лодами), RasterOps, некоторые параметры, например изменения альфа теста по дистанции(для травы деревьев), параметры считается перед отрисовкой ROP, передается в шейдер.
Конечно не претендует на универсальность и правильность.
>А что есть материал ?
Textures(с параметрами фильтрации, параметры адресации, параметры отключение анизотропной по расстоянию),shaders(вместе с их лодами), RasterOps, некоторые параметры, например изменения альфа теста по дистанции(для травы деревьев), параметры считается перед отрисовкой ROP, передается в шейдер.
Конечно не претендует на универсальность и правильность.
Render Ops | 6 июля 2012 | 10:35 | #41 |
---|
Executor
> У тебя универсально? Как сделал?
Универсально. На самом деле пока в процессе полного перевода на универсальную, пока проблем нету.
Структура содержит примерно следующее:
VB, IB, StartIndex, StartVertex, numPrimitive, Material (указатель), WorldMatrix(указатель) далее нужен набор параметров упакованных в 64 бита. Ну не совсем пока толстый ROP.
Идти нужно примерно от такой структуры.
>Просто получается, что чем универсальнее, тем толше роп.
Ну смотря как ты оформил эту структуру, лучше оставить ссылки на данные если они тяжелые для копирования и т.д.
Можно объединить VB,IB, в единую структуру - будет ссылка(StartIndex, StartVertex может быть разным вдруг со смещением идет отрисовка)
Если не паковать другие параметры, то конечно sizeof будет большим.
про упаковку можно тут посмотреть
http://www.gamedev.ru/pages/totem4_engine/articles/totem4_article2
Z еще говорил про флаги в рендер операциях.
>Например для шадоумаппинга вообще нафиг не нужно 99% того, что есть в материалах,
а для постпроцесса или для объемного тумана, света и т.д. возможно другие параметры нужны, будешь еще списки другие делать?
Имея универсальную структуру ты можешь спокойно расширять и наворачивать рендер, добавляя проходы и современные техники. Все равно конечный итого DIP + материал.
> У тебя универсально? Как сделал?
Универсально. На самом деле пока в процессе полного перевода на универсальную, пока проблем нету.
Структура содержит примерно следующее:
VB, IB, StartIndex, StartVertex, numPrimitive, Material (указатель), WorldMatrix(указатель) далее нужен набор параметров упакованных в 64 бита. Ну не совсем пока толстый ROP.
Идти нужно примерно от такой структуры.
>Просто получается, что чем универсальнее, тем толше роп.
Ну смотря как ты оформил эту структуру, лучше оставить ссылки на данные если они тяжелые для копирования и т.д.
Можно объединить VB,IB, в единую структуру - будет ссылка(StartIndex, StartVertex может быть разным вдруг со смещением идет отрисовка)
Если не паковать другие параметры, то конечно sizeof будет большим.
про упаковку можно тут посмотреть
http://www.gamedev.ru/pages/totem4_engine/articles/totem4_article2
Z еще говорил про флаги в рендер операциях.
>Например для шадоумаппинга вообще нафиг не нужно 99% того, что есть в материалах,
а для постпроцесса или для объемного тумана, света и т.д. возможно другие параметры нужны, будешь еще списки другие делать?
Имея универсальную структуру ты можешь спокойно расширять и наворачивать рендер, добавляя проходы и современные техники. Все равно конечный итого DIP + материал.
Render Ops | 6 июля 2012 | 9:57 | #36 |
---|
innuendo
> Понятие примитива ещё не появилось в твоей вселенной ? :)
Опустим это понятие, предположив что все Rop содержат это список треугольников. Точки в игрой графики рисуют редко, а линии в режиме отладки движка или в редакторах.
>Это же для группы ROP ?
Почему для группы? Нашел ты кусок геометрии на сцене(кусок сложной модели кусок ландшафта и т.д.) в каждом куске могут быть свои RasterOps. Ну а потом сортировка по приоритемат
Z,Blending,texture,shaders и т.д. тут уже будет по группам.
> Понятие примитива ещё не появилось в твоей вселенной ? :)
Опустим это понятие, предположив что все Rop содержат это список треугольников. Точки в игрой графики рисуют редко, а линии в режиме отладки движка или в редакторах.
>Это же для группы ROP ?
Почему для группы? Нашел ты кусок геометрии на сцене(кусок сложной модели кусок ландшафта и т.д.) в каждом куске могут быть свои RasterOps. Ну а потом сортировка по приоритемат
Z,Blending,texture,shaders и т.д. тут уже будет по группам.
Render Ops | 6 июля 2012 | 9:30 | #34 |
---|
Sergio
> Да, кстати. Объясните про них подробнее. Действительно, ведь они могут быть
> слишком разные, чтобы их объединять в одну сущность.
Нужны примеры. Я так понимаю что при усложнении рендера как раз и возникает сложность в объединении. Можно начать с простого - прозрачный объект и непрозрачный.
В чем разница ? разная функция прозрачности, т.е. в составе RenderOps будет разные RasterOps. Ну и при сортировке это нужно учесть.
> Да, кстати. Объясните про них подробнее. Действительно, ведь они могут быть
> слишком разные, чтобы их объединять в одну сущность.
Нужны примеры. Я так понимаю что при усложнении рендера как раз и возникает сложность в объединении. Можно начать с простого - прозрачный объект и непрозрачный.
В чем разница ? разная функция прозрачности, т.е. в составе RenderOps будет разные RasterOps. Ну и при сортировке это нужно учесть.
Render Ops | 6 июля 2012 | 9:27 | #33 |
---|
SNVampyre
Это не совсем RenderOp, или линковку и присоединение шейдеров ты делаешь во время рендеринга? То что ты описал скорей всего часть RenderOps + создание ресурсов.
То что относится к это SH_RENDER_BIND, SH_RENDER_DRAW, причем они должны быть в составе одной операции.
По идее подход тоже верный, ты накидаешь кучу SH_RENDER_BIND + SH_RENDER_DRAW и будет почти тоже самое. Только сложнее, слишком сильно разделил то, что не нужно разделять.
Хотя не известно как будет это выглядеть. Пробовать нужно.
Mr F
>пакеты raw данных для рендера, которые откуллились
>это и есть рендерОп?
Совершенно верно.
Есть вопросы и замечания по твоему классу.
>GVertexDeclaration* decl;
>U32 GVDeclSize, GVDeclSize1;
а зачем это тут ? лишняя память, ты подумай какой swap будет тяжелый при сортировке. По идее по вершинному буферу можно узнать его формат, по крайней мере у меня так, а по формату берется VertexDeclaration все это линейный операции по константным массивам.
>U8 primsize;
А это что ?
Кстати а мировая матрица трансформации где? Достаточно указателя естественно, сама она хранится в объекте/модели и т.д.
Подумать можно еще про упаковку параметров в виде битов.
Где еще набор текстур, Raster Ops ? (Blending, Depth Func и т.д.)
>Объясните идиоту, зачем нужны renderOps, они же не универсальны, чтоб их во что-то объединять.
Почему не универсален?
Для DIP нужно:
VB,Ib, число примитивов, стартовая вершина стартовый индекс.
Материал(текстуры шейдеры Raster Ops)
мировая матрица
+ расширения например для инстансинга как у Mr F
Executor
> У меня они не универсальны. Это плохо?
Да, не очень хорошо, после обхода сцены, рендеру нужно давать список готовых максимально правильно отсортированных примитивных структур данных, хранящих очередную операцию отрисовки с установкой соответствующих настроек. Объекты и графические техники бывают сложными, поэтому некий менеджер, должен собирать с них одинаковые данные,
приводящие в конечном счете к DIP + настройки. Конечно, не так просто это сделать, но стараться все приводить к универсальному виду.
Это не совсем RenderOp, или линковку и присоединение шейдеров ты делаешь во время рендеринга? То что ты описал скорей всего часть RenderOps + создание ресурсов.
То что относится к это SH_RENDER_BIND, SH_RENDER_DRAW, причем они должны быть в составе одной операции.
По идее подход тоже верный, ты накидаешь кучу SH_RENDER_BIND + SH_RENDER_DRAW и будет почти тоже самое. Только сложнее, слишком сильно разделил то, что не нужно разделять.
Хотя не известно как будет это выглядеть. Пробовать нужно.
Mr F
>пакеты raw данных для рендера, которые откуллились
>это и есть рендерОп?
Совершенно верно.
Есть вопросы и замечания по твоему классу.
>GVertexDeclaration* decl;
>U32 GVDeclSize, GVDeclSize1;
а зачем это тут ? лишняя память, ты подумай какой swap будет тяжелый при сортировке. По идее по вершинному буферу можно узнать его формат, по крайней мере у меня так, а по формату берется VertexDeclaration все это линейный операции по константным массивам.
>U8 primsize;
А это что ?
Кстати а мировая матрица трансформации где? Достаточно указателя естественно, сама она хранится в объекте/модели и т.д.
Подумать можно еще про упаковку параметров в виде битов.
Где еще набор текстур, Raster Ops ? (Blending, Depth Func и т.д.)
>Объясните идиоту, зачем нужны renderOps, они же не универсальны, чтоб их во что-то объединять.
Почему не универсален?
Для DIP нужно:
VB,Ib, число примитивов, стартовая вершина стартовый индекс.
Материал(текстуры шейдеры Raster Ops)
мировая матрица
+ расширения например для инстансинга как у Mr F
Executor
> У меня они не универсальны. Это плохо?
Да, не очень хорошо, после обхода сцены, рендеру нужно давать список готовых максимально правильно отсортированных примитивных структур данных, хранящих очередную операцию отрисовки с установкой соответствующих настроек. Объекты и графические техники бывают сложными, поэтому некий менеджер, должен собирать с них одинаковые данные,
приводящие в конечном счете к DIP + настройки. Конечно, не так просто это сделать, но стараться все приводить к универсальному виду.
Убогость OpenGL API | 4 июля 2012 | 23:29 | #318 |
---|
Blew_zc
>Драйвер вообще может потенциально дать указатель на видеопамять, и никаких выделений и дополнительных копирований не будет.
Ну вот еще дополнительный плюс.
>Драйвер вообще может потенциально дать указатель на видеопамять, и никаких выделений и дополнительных копирований не будет.
Ну вот еще дополнительный плюс.
Убогость OpenGL API | 4 июля 2012 | 23:04 | #316 |
---|
SNVampyre
> Да, второй вариант намного быстрее, так как не вызывает локов.
значит ты дополнительную память выделяешь, грузишь сначала из файла потом вызываешь glBufferData. У тебя за камерой могут не успевать грузится объекты. Зато да, асинхронно будет грузится в потоке рендера, и быстрее возможно будет копирование, хотя я не уверен что быстро как раз на glBufferData будет просадка.
Теперь все понятно. Дополнительные затраты памяти на загрузку файла, двойное копирование, все та-же остановка в потоке отрисовки. Хотя Lock/Unlock тоже память выделяет, но драйвер может это сделает возможно оптимальнее, чем ты ручным выделением.
> Да, второй вариант намного быстрее, так как не вызывает локов.
значит ты дополнительную память выделяешь, грузишь сначала из файла потом вызываешь glBufferData. У тебя за камерой могут не успевать грузится объекты. Зато да, асинхронно будет грузится в потоке рендера, и быстрее возможно будет копирование, хотя я не уверен что быстро как раз на glBufferData будет просадка.
Теперь все понятно. Дополнительные затраты памяти на загрузку файла, двойное копирование, все та-же остановка в потоке отрисовки. Хотя Lock/Unlock тоже память выделяет, но драйвер может это сделает возможно оптимальнее, чем ты ручным выделением.
Убогость OpenGL API | 4 июля 2012 | 22:01 | #311 |
---|
SNVampyre
>Так у тебя два объекта грузились 150мс что ли? Ты определись.
объекты грузились с временем достаточным для простоя и дергания камеры.
> Ты вообще хоть читаешь посты собеседника? Я же писал, что у меня стриминг текстур даёт 2000 текстур 2048х2048 DXT3 в секунду. Тебе такой скорости мало что >ли?
Ну пробуй грузить десяток объектов по 150 метров файлы. Что ты на текстурах зациклился? Как раз текстуры грузились быстрее всего.
Я видел твою сцену. Это кубик с освещение и построцессом. Не надо этим тыкать. Нужно тестировать на десятке гигабайт моделей и на карте 50 км на 50 км. И при полете камеры нужно загружать/выгружать десятки объектов за полсекунды.
Кстати я забыл сказать я грузится с файла сразу в указатель выданный VB/IB/Texture аналог того что выдает к примеру функция glMapBuffer, а ты я так понял грузишь файл в память, а потом копирование в потоке рендера.
>Так у тебя два объекта грузились 150мс что ли? Ты определись.
объекты грузились с временем достаточным для простоя и дергания камеры.
> Ты вообще хоть читаешь посты собеседника? Я же писал, что у меня стриминг текстур даёт 2000 текстур 2048х2048 DXT3 в секунду. Тебе такой скорости мало что >ли?
Ну пробуй грузить десяток объектов по 150 метров файлы. Что ты на текстурах зациклился? Как раз текстуры грузились быстрее всего.
Я видел твою сцену. Это кубик с освещение и построцессом. Не надо этим тыкать. Нужно тестировать на десятке гигабайт моделей и на карте 50 км на 50 км. И при полете камеры нужно загружать/выгружать десятки объектов за полсекунды.
Кстати я забыл сказать я грузится с файла сразу в указатель выданный VB/IB/Texture аналог того что выдает к примеру функция glMapBuffer, а ты я так понял грузишь файл в память, а потом копирование в потоке рендера.
Убогость OpenGL API | 4 июля 2012 | 21:22 | #309 |
---|
SNVampyre
>10мс - это уже 100FPS.
А если 5 объектов уже 50 FPS ? :) и твой продвинутый рендер на 10000 DIP + все остальное даст слайд шоу?
Еще раз для твоей сцены с машинкой и ландшафтом на 2 полика этого хватит, хороший запас.
> Это копирование практически ничего не занимает по времени. Копирование больших массивов нынешние процессоры делают очень быстро. Я тебе точно могу
> гарантировать, что ты не сможешь так загрузить подгрузку ресурсов в видеокарту, чтобы это было заметно, банально жёсткий диск не будет успевать.
Ну загрузил же, лаги были. Я спорить не буду. Все равно копировать в другом потоке будет быстрее. Пока что У тебя нету опыт стриминга данных Так что давай каждый останется при своем мнении. Заканчиваем бессмысленую дискуссию на эту тему.
>10мс - это уже 100FPS.
А если 5 объектов уже 50 FPS ? :) и твой продвинутый рендер на 10000 DIP + все остальное даст слайд шоу?
Еще раз для твоей сцены с машинкой и ландшафтом на 2 полика этого хватит, хороший запас.
> Это копирование практически ничего не занимает по времени. Копирование больших массивов нынешние процессоры делают очень быстро. Я тебе точно могу
> гарантировать, что ты не сможешь так загрузить подгрузку ресурсов в видеокарту, чтобы это было заметно, банально жёсткий диск не будет успевать.
Ну загрузил же, лаги были. Я спорить не буду. Все равно копировать в другом потоке будет быстрее. Пока что У тебя нету опыт стриминга данных Так что давай каждый останется при своем мнении. Заканчиваем бессмысленую дискуссию на эту тему.
Убогость OpenGL API | 4 июля 2012 | 20:52 | #307 |
---|
SNVampyre
> Это время включая загрузку с диска или только копирование данных в буферы?
Да это все время, но без учета, Create/Lock/Unlock. Тут по любому в потоке рендера. Ну ты сократи допустим 10 мс на копирование всех данных для объекта думаю вполне адекватное время и это в кадре очень много, конечно для таких задач как были у меня. И учти что грузится часто, и много буферов и текстур.
Вот и выйдет на все 10 объектов 150 мс. Не думаю что это мало. Тут смысл не в том что-бы взять и грузить в отдельном потоке а в том что-бы не было лагов. Я поставил профайл и понял где лагает. Городить создание много поточного устройства в Direct3D это аналог расшаривания контекстов. Вынеся копирования в другой поток лаги исчезли.
>Ну так в Direct3D9 нет PBO, поэтому там этому нет альтернатив.
ну опять таки копирование в потоке рендеринга. Это нужно выносить, если много данных как по числу запросjв на копирование так и на объемы копирования.
> Это время включая загрузку с диска или только копирование данных в буферы?
Да это все время, но без учета, Create/Lock/Unlock. Тут по любому в потоке рендера. Ну ты сократи допустим 10 мс на копирование всех данных для объекта думаю вполне адекватное время и это в кадре очень много, конечно для таких задач как были у меня. И учти что грузится часто, и много буферов и текстур.
Вот и выйдет на все 10 объектов 150 мс. Не думаю что это мало. Тут смысл не в том что-бы взять и грузить в отдельном потоке а в том что-бы не было лагов. Я поставил профайл и понял где лагает. Городить создание много поточного устройства в Direct3D это аналог расшаривания контекстов. Вынеся копирования в другой поток лаги исчезли.
>Ну так в Direct3D9 нет PBO, поэтому там этому нет альтернатив.
ну опять таки копирование в потоке рендеринга. Это нужно выносить, если много данных как по числу запросjв на копирование так и на объемы копирования.
Убогость OpenGL API | 4 июля 2012 | 19:32 | #304 |
---|
SNVampyre
>А в чём усложнение-то? У тебя в другом потоке грузятся твои текстуры.
не будем про это, в той ситуации я не хотел ничего делать лучше тут другие факторы.
>> Ты думаешь, с загрузкой в другом потоке это будет быстрее?
>> Я пока не загружу ресурсы для объекта он не попадет в список отрисовки
>А это разве не простой? То есть ты увеличиваешь время ожидания на время синхронизации потоков...
Только он на порядок ниже чем твой рендер будет копировать данные.
>> Он не давал рендеру ресурсы залоченные и заполняемые в другом потоке.
>В общем, куча задержек и неудобств, ясно.
Давай я объясню как было сделано может поймешь что там задержки минимальны.
имеем список объектов array
>А в чём усложнение-то? У тебя в другом потоке грузятся твои текстуры.
не будем про это, в той ситуации я не хотел ничего делать лучше тут другие факторы.
>> Ты думаешь, с загрузкой в другом потоке это будет быстрее?
>> Я пока не загружу ресурсы для объекта он не попадет в список отрисовки
>А это разве не простой? То есть ты увеличиваешь время ожидания на время синхронизации потоков...
Только он на порядок ниже чем твой рендер будет копировать данные.
>> Он не давал рендеру ресурсы залоченные и заполняемые в другом потоке.
>В общем, куча задержек и неудобств, ясно.
Давай я объясню как было сделано может поймешь что там задержки минимальны.
имеем список объектов array