Сообщения на форуме пользователя Andrey (37 стр.)
История про то, как Пятачок оптимизировал простой цикл | 14 дек. 2010 | 17:56 | #102 |
---|
kas
> возможно про садка еще на Load hit Store.
> на пц такое не заметить.
я так и подумал, Значит остался толстый итератор для MSVC реализации STL
> возможно про садка еще на Load hit Store.
> на пц такое не заметить.
я так и подумал, Значит остался толстый итератор для MSVC реализации STL
История про то, как Пятачок оптимизировал простой цикл | 14 дек. 2010 | 16:32 | #98 |
---|
Suslik
>1) Почему итератор работает так медленно?
> 2) Почему operator[] работает так медленно?
В стандартной реализации от MS идет вызов через итератор, последний класс обертка над указателем, нужно asm код сравнить с STLPort, там итератор это тупо указатель, возможно про садка еще на Load hit Store.
>1) Почему итератор работает так медленно?
> 2) Почему operator[] работает так медленно?
В стандартной реализации от MS идет вызов через итератор, последний класс обертка над указателем, нужно asm код сравнить с STLPort, там итератор это тупо указатель, возможно про садка еще на Load hit Store.
Yet another совет по `Орхитектуре` | 11 дек. 2010 | 15:51 | #598 |
---|
Z
> > осталось разобраться как фиксировать указатели для конкретных задач и сильно
> > ли
> > нужно последнее? много дает выигрыша и т.д. ?
> Не понял.
Все, сам разобрался.
> > осталось разобраться как фиксировать указатели для конкретных задач и сильно
> > ли
> > нужно последнее? много дает выигрыша и т.д. ?
> Не понял.
Все, сам разобрался.
Yet another совет по `Орхитектуре` | 11 дек. 2010 | 10:49 | #547 |
---|
Z
> Вот кстати, про запись и чтение блобов - небольшой примерчик, своего рода
> влобнъй first generation код + мелкий пример:
спасибо! Отлично я на верном пути! осталось разобраться как фиксировать указатели для конкретных задач и сильно ли нужно последнее? много дает выигрыша и т.д. ?
> Вот кстати, про запись и чтение блобов - небольшой примерчик, своего рода
> влобнъй first generation код + мелкий пример:
спасибо! Отлично я на верном пути! осталось разобраться как фиксировать указатели для конкретных задач и сильно ли нужно последнее? много дает выигрыша и т.д. ?
Yet another совет по `Орхитектуре` | 9 дек. 2010 | 12:23 | #284 |
---|
Executor
> Покажи как это устроено, я примерно понял, но так до конца и не смог понять как
> по этому int32 можно чтото делать с текстурой или любым другим объектом 3Д
> Апи...
> Вот есть IDirect3DTexture9, как до неё достучаться через int32?
int32 это тупо индекс массива где твои ресурсы и хранятся, вот и все, линейно все храниться в памяти никакого говно ООП и кучи интерфейсов, никакого abstraction penalty и всего остального.
ReeV
> грубым c-cast'ом, я бы за это.....руки..отрывал
Ты наверное не понял реализацию. Какие касты?? ты про что вообще?
> Покажи как это устроено, я примерно понял, но так до конца и не смог понять как
> по этому int32 можно чтото делать с текстурой или любым другим объектом 3Д
> Апи...
> Вот есть IDirect3DTexture9, как до неё достучаться через int32?
int32 это тупо индекс массива где твои ресурсы и хранятся, вот и все, линейно все храниться в памяти никакого говно ООП и кучи интерфейсов, никакого abstraction penalty и всего остального.
struct Direct3DTexture { IDirect3DTexture9* tex; // other data }; array<Direct3DTexture > textures; // где-то в классе рендер девайс // внешний вызов render->BindTexture(const Texture& tex, 1) // примерная реализация BindTexture(const Texture& tex, uint stage) { .... uint id = tex; assert(id < textures.size()); pDevice->SetTexture(stage, textures[id].tex); .... }
> грубым c-cast'ом, я бы за это.....руки..отрывал
Ты наверное не понял реализацию. Какие касты?? ты про что вообще?
Yet another совет по `Орхитектуре` | 9 дек. 2010 | 11:09 | #274 |
---|
Executor
> Не пойдёт?
Не пойдет, зачем тут виртуальный вызов и лишние абстракции, типа ООП круто? оборачиваем int32 в класс и подаем этот id в рендер девай/контекс и сразу имеем доступ к graphics API без лишнего кода и все в 1 классе, причем реализация работает для разных API.
> Не пойдёт?
Не пойдет, зачем тут виртуальный вызов и лишние абстракции, типа ООП круто? оборачиваем int32 в класс и подаем этот id в рендер девай/контекс и сразу имеем доступ к graphics API без лишнего кода и все в 1 классе, причем реализация работает для разных API.
Пишем отладчик для Lua 5.1 (комментарии) | 9 дек. 2010 | 10:47 | #3 |
---|
Cherk
> Очень полезная вещь. Исходники я так понимаю закрыты...
Было бы еще на C++ лучше было бы.
> Очень полезная вещь. Исходники я так понимаю закрыты...
Было бы еще на C++ лучше было бы.
Структура данных для вершинного буфера | 9 дек. 2010 | 10:42 | #12 |
---|
Sergio
> На данные, которые будут заливаться в видеопамять
Так... этот указатель будет не валидный после того как ты залил все в видеопамять, вопрос зачем его хранить как членом класса?
Класс вершинного буфера должен хранить - API specific указатель и т.д., формат, размер, и режим использования(статический динамический). Больше в классе ничего не должно быть.
Зачем там указатель на видео память? Вся эта логика будет в методе Lock/Unlock/WriteData и т.д. и указатель будет временным в виде локальной переменной или как входной параметр.
> > в этот-же буфер? дак не влезет,
> Вот я про это и говорю.
И какой из вывод из этой идеи? Непонятная функциональность просчета нормалей прямо в вершинном буфере, формат которого физически не имеет нормалей, да непонятно для чего нужна? Ты по видео памяти хочешь шарахать и BSOD создавать?
innuendo
> так какой % ускорения ? 0.1 ? это какой-то синтетический тест ? вся сцена в
> одном vbo ?
Сравнивал на ландшафте. Общий вершинный буфер для всего ландшафта. Уменьшил число вызовов функция gl*Pointer, FPS возрос, где-то 10%. Почему бы не добавить это если там 3 строчки кода.
> На данные, которые будут заливаться в видеопамять
Так... этот указатель будет не валидный после того как ты залил все в видеопамять, вопрос зачем его хранить как членом класса?
Класс вершинного буфера должен хранить - API specific указатель и т.д., формат, размер, и режим использования(статический динамический). Больше в классе ничего не должно быть.
Зачем там указатель на видео память? Вся эта логика будет в методе Lock/Unlock/WriteData и т.д. и указатель будет временным в виде локальной переменной или как входной параметр.
> > в этот-же буфер? дак не влезет,
> Вот я про это и говорю.
И какой из вывод из этой идеи? Непонятная функциональность просчета нормалей прямо в вершинном буфере, формат которого физически не имеет нормалей, да непонятно для чего нужна? Ты по видео памяти хочешь шарахать и BSOD создавать?
innuendo
> так какой % ускорения ? 0.1 ? это какой-то синтетический тест ? вся сцена в
> одном vbo ?
Сравнивал на ландшафте. Общий вершинный буфер для всего ландшафта. Уменьшил число вызовов функция gl*Pointer, FPS возрос, где-то 10%. Почему бы не добавить это если там 3 строчки кода.
Структура данных для вершинного буфера | 8 дек. 2010 | 23:34 | #6 |
---|
innuendo
> ну не смешите мои тапочки, это сильно ускорило FPS ?
у меня ускорило, ты число вызовов сравни для 100 патчей и подумай, потом пиши в таком контексте.
> ну не смешите мои тапочки, это сильно ускорило FPS ?
у меня ускорило, ты число вызовов сравни для 100 патчей и подумай, потом пиши в таком контексте.
Структура данных для вершинного буфера | 8 дек. 2010 | 23:32 | #5 |
---|
Sergio
>void* data;
не понял это указатель на что? На видео память или откуда данные в буфер заливать?
>
> > Залочить буфер посчитать нормали и разлочить или как???
> А если в данных буфера изначально не предусмотрены нормали?
Так ладно посчитал нормали, куда массив нормалей присабачивать будешь? в этот-же буфер? дак не влезет, или для других целей? если так то можно на этапе загрузки посчитать. Я что-то не понимаю твою идею.
>void* data;
не понял это указатель на что? На видео память или откуда данные в буфер заливать?
>
> > Залочить буфер посчитать нормали и разлочить или как???
> А если в данных буфера изначально не предусмотрены нормали?
Так ладно посчитал нормали, куда массив нормалей присабачивать будешь? в этот-же буфер? дак не влезет, или для других целей? если так то можно на этапе загрузки посчитать. Я что-то не понимаю твою идею.
Структура данных для вершинного буфера | 8 дек. 2010 | 23:19 | #1 |
---|
Sergio
> и неплохо было бы менять формат эитх данных на лету (например в существующем
> буфере с координатами посчитать нормали)
Интересно зачем это нужно?
Залочить буфер посчитать нормали и разлочить или как???
> Ответ напрашивается сам собой - void*
это как понимать ? или это имеется ввиду gl*Pointer ?
> с другой стороны теряется скорость
как тут теряется скорость, если это единственное решение, или я не так понял?
> Это довольно быстро и удобно, но не гибко
Зачем тут гибкость? имеем 4-5 форматов на весь движок, а больше и не нужно. Зачем все усложнять?
Вообще загадочно ты как-то все написал.
Кстати про буферы. Рекомендую GL_ARB_draw_elements_base_vertex, сокращает число вызовов gl*Pointer если рисовать со смещением. Додумались это добавить спустя много лет, причем начиная с версии OpenGL 3.0, хотя в Direct3D9 это можно делать еще самого начала.
> и неплохо было бы менять формат эитх данных на лету (например в существующем
> буфере с координатами посчитать нормали)
Интересно зачем это нужно?
Залочить буфер посчитать нормали и разлочить или как???
> Ответ напрашивается сам собой - void*
это как понимать ? или это имеется ввиду gl*Pointer ?
> с другой стороны теряется скорость
как тут теряется скорость, если это единственное решение, или я не так понял?
> Это довольно быстро и удобно, но не гибко
Зачем тут гибкость? имеем 4-5 форматов на весь движок, а больше и не нужно. Зачем все усложнять?
Вообще загадочно ты как-то все написал.
Кстати про буферы. Рекомендую GL_ARB_draw_elements_base_vertex, сокращает число вызовов gl*Pointer если рисовать со смещением. Додумались это добавить спустя много лет, причем начиная с версии OpenGL 3.0, хотя в Direct3D9 это можно делать еще самого начала.
gDEBugger теперь бесплатен! (комментарии) | 8 дек. 2010 | 13:33 | #13 |
---|
Опа! круто однако!
Кривые значения при использовании массива в ассемблерной вставке в функциях | 8 дек. 2010 | 11:35 | #5 |
---|
LeonardoA.M
ох sorry, ошибся.
ох sorry, ошибся.
Кривые значения при использовании массива в ассемблерной вставке в функциях | 8 дек. 2010 | 11:26 | #3 |
---|
LeonardoA.M
можно еще и так:
можно еще и так:
mov eax, [X + edi]
Yet another совет по `Орхитектуре` | 7 дек. 2010 | 22:44 | #140 |
---|
Pushkoff
> хочется сказать: поднимите руку все у кого GAPI подменяется на лету!!
у меня с команды в консоли в движке можно рендер менять :))) причем работает. Правда падает иногда - появляются иногда ошибки. Это конечно экспериментальная реализация.
> хочется сказать: поднимите руку все у кого GAPI подменяется на лету!!
у меня с команды в консоли в движке можно рендер менять :))) причем работает. Правда падает иногда - появляются иногда ошибки. Это конечно экспериментальная реализация.