Сообщения на форуме пользователя Andrey (66 стр.)
Организация Streaming data loading в 3D движке | 7 окт. 2009 | 18:04 | #11 |
---|
> у меня спросить :)
итак
>плавующие блоки в памяти ( через handle адрессуешь, а не через прямой указатель )
что за Win32 функция?
>что бы работать делаешь им lock(), пишешь, потом unlock() -
HeapLock/HeapUnlock ?
>через некую дельту времени если нет локов активных внутри критсекции делаешь уплотнение
HeapCompact ?
Организация Streaming data loading в 3D движке | 7 окт. 2009 | 17:56 | #8 |
---|
> а есть способ дефрагментации оперативки
не знаю таких, рекомендуется не делать фрагментацию.
innuendo
ContentStream - хорошая реализация. Буду опираться на нее.
>плавующие блоки в памяти ( через handle адрессуешь, а не через прямой указатель )
>что бы работать делаешь им lock(), пишешь, потом unlock() -
>через некую дельту времени если нет локов активных внутри критсекции делаешь уплотнение
где поподробнее почитать?
Организация Streaming data loading в 3D движке | 7 окт. 2009 | 16:37 | #5 |
---|
Ну какая тут критика. Это быстро? не падает? просадки FPS при подгрузке есть? Память не фрагментируется? значит хорошо.
кстати какое API ?
Организация Streaming data loading в 3D движке | 7 окт. 2009 | 15:48 | #2 |
---|
>ContentStream пример видел из DXSDK ?
нет. спасибо сейчас гляну.
Организация Streaming data loading в 3D движке | 7 окт. 2009 | 15:41 | #0 |
---|
Суть задачи в следующем. Есть сцена с условно бесконечным размером, т.е. большой протяженности. На ней большой кол-во объектов. Требуется при передвижении камеры динамически подгружать их и выгружать старые. Все грузить сразу нельзя, просто не хватит памяти. при каком Условии выгружать старые еще не подумал, но варианты выгрузки есть
такие:
- Если объект не виден, удалить через некоторое время, тут может быть тонкость, можно и не удалять, если есть свободный лимит памяти и т.д;
- удалять если он на большом расстоянии, тут тоже можно учесть время и свободное место в памяти.
Теперь вопросы:
1)Как делать выгрузку старых? на уровне объектов или на уровне ресурсов? на уровне объектов - удалили сам объект, вместе с ним все графические ресурсы - материалы(текстуры, шейдеры), вершинные, индексные буферы. Тут можно объект пометить как пустой и использовать для загрузки другого, просто записав новые данные.
На уровне ресурсов тут все понятно - просто удаляем графические ресурсы
2) Как корректно и быстро выгружать старые данные? сохранять временно на диск? или просто освобождать память? или хранить в памяти? Либо самые старые сохранять диск? могут быть проблемы с фрагментацией?
надумал простую идею. Создаем большой файл средствами проецирования файлов в память. Каждому ресурсу выделяется позиция + смещение равное размеру данных.
При очередной выгрузке/подгрузке данные скидываются/загружаются оттуда. Какие тут могут быть проблемы?
3) Как организовать распределение задач по потокам?
На данный момент реализовано так:
1 Поток - рендер. 2 Поток - загрузка. Сейчас это работает. При полете камеры грузятся появляются объекты. Выгрузку еще не реализовывал.
В каком потоке делать задания на загрузку новой группы объектов? Сколько объектов лучше грузить, и в отдельных потоках ли это делать или все в одном?
4) Главный вопрос каким образом сделать эту реализацию что-бы производительность не падала.
Если еще что-то не понятно, задавайте вопросы я допишу.
Поиск по форуму ничего не дал.
Буду рад любым ссылкам, рекомендациям.
Спасибо всем заранее.
С Уважением, Андрей.
STL. Использовать или нет? | 7 окт. 2009 | 14:51 | #1060 |
---|
итак по порядку.
>>часто std::fill для зануления массивов, можно и memset но небезопасно,
>чем не безопасно? если размер массива известен, какие ошибки тут можно сделать???
std::fill действительно не нужен. Везде можно memset.
>>ты в циклах не пишешь std::for_each ? мне удобно, коротко, тут уже на любителя,
>так нада функцию писать, мало мест где такое удобно.
ну в паре мест это есть, и это не часто.
>>std::copy удобен, конечно на memcpy можно заменить, но если объекты не сложные, часто std::find использую 1 строчка и все.
>копировать массивами сложные объекты??? зачем??? мы про геймдев же а не про биздев и т.д. теболее в движке.
std::copy в одном месте не получится заменить на memcpy, идет копирование int32 массива в массив int16 тут можно исправить ситуацию, возможно пересмотреть структуры данных и т.д. В других можно заменить на memcpy.
>>у тебя нету поиска массивах?
>зачем что то искать в массивах? ресурсы по имени?? ну догда хэшмап.
>что ещё искать???
std::find есть несколько, в режиме рендеринга есть одно место где есть std::find_if - поиск шейдера по квадрату дистанции(при большом расстоянии упрощенный шейдер ставится)
просто есть ли тут смысл для массива из 3,4 шейдеров делать hash ?
>...а то вон один уже спекся, кризис кризис кричит везде.
да я адекватно отношусь к критике, анализирую просвещаюсь. делаю тесты, смотрю профайлером, смотрю asm код и т.д.
ну вот к примеру недавно действительно проверил что std::binary_search быстрее std::map хотя сложность у них одинакова...
vladislav
> В C++ такого нет - это приравнивается к велосипеду - тут нет неясностей.
ну в любом случае во всех реализациях STL это есть. Тут неясность писать ли свой Hash Map со статической таблицей, либо пользоваться этим.
Нужно детально исследовать проблему сколько элементов будет и т.д.
STL. Использовать или нет? | 7 окт. 2009 | 13:03 | #1044 |
---|
часто std::fill для зануления массивов, можно и memset но небезопасно, ты в циклах не пишешь std::for_each ? мне удобно, коротко, тут уже на любителя, std::copy удобен, конечно на memcpy можно заменить, но если объекты не сложные, часто std::find использую 1 строчка и все.
я не спорю не все идеально у меня но эти алгоритмы полезны. У тебя всего это нету?
у тебя нету поиска массивах? и ничего не копируешь? std::max_element/min_element при построении вершинных буферов использую - наверняка не нужен можно пересмотреть алгоритм.
STL. Использовать или нет? | 7 окт. 2009 | 12:37 | #1039 |
---|
> конкретно вот тебе что нужно из алгоритмов?
ну я думаю вот что можно использовать:
правка добавил еще
Правка: 7 окт. 2009 12:44
STL. Использовать или нет? | 7 окт. 2009 | 11:58 | #1034 |
---|
>ну так вроде пришли к выводу что кроме std::vector вроде в гемдеве больше нифига и не нада
наверное еще наверняка пойдут все алгоритмы STL кроме тех что выделяют временно память для своих нужд.
неясности еще с stdext::hash_map.
Передача данных от вершинного шейдера в пиксельный | 6 окт. 2009 | 17:38 | #48 |
---|
еще не пробовал. не знаю как.
STL. Использовать или нет? | 6 окт. 2009 | 17:37 | #1023 |
---|
а... блин точно по привычки не глянул внимательней, std::count имеет право жить.
STL. Использовать или нет? | 6 окт. 2009 | 17:33 | #1020 |
---|
>и почему count тормознее чем transform ?
std::find, transform они как раз нужны и удобны.
а вот потоки ввода вывода это вообще убожество.
http://www.ipolyakov.com/old/ru/stdioVSiostreams/comparison.html
Передача данных от вершинного шейдера в пиксельный | 6 окт. 2009 | 17:25 | #46 |
---|
>А как ты сделаешь в GL больше 8 ?
не возникало пока такой задачи. хватало 4 вроде...
в общем согласно доке по Cg: ну а там всего 8.
в общем ждать новой версии, вроде должен GLSL 1.5 поддерживать.
STL. Использовать или нет? | 6 окт. 2009 | 17:22 | #1015 |
---|
все кроме cout, это тормоз.
Передача данных от вершинного шейдера в пиксельный | 6 окт. 2009 | 14:19 | #39 |
---|
пиксельный скомпилился(glslf). Вершинный не хочет(glslv): Cg компилит успешно в профиль vs_3_0(Direct3D).
А вот Cg в профиль vs_2_0 выдает ту-же ошибку.
Может Cg еще не держит наверное больше 8 текстурных координат для OpenGL ? в новой версии может что измениться.