Управление памятью С++ для потоковой передачи текстур в видеоиграх

Ответ 1

Недавно я много изучил управление памятью, и это самая информативная и полезная статья, которую я нашел в сети.

http://www.ibm.com/developerworks/linux/library/l-memory/

Основываясь на этой статье, лучший и быстрый результат, который вы получите, состоит в том, чтобы разделить 64 МБ на куски равного размера. Размер кусков будет зависеть от размера вашего объекта. И выделять или освобождать полный кусок за раз. Это

• Быстрее, чем инкрементная сборка мусора.
• Simpler.
• И решает эту проблему "слишком много фрагментации" на какую-то сумму.

Прочтите, вы найдете отличную информацию о каждом возможном решении, которое есть, и достоинствах и недостатках для каждого.

Ответ 2

Почему бы не использовать несколько областей памяти для потоковых текстур и пула по размеру текстуры?

Insomniac имеет документ об их реализации потоковой передачи текстур на PS3. Я полагаю, это может быть полезно: ссылка.

Для общих стратегий распределения, чтобы минимизировать фрагментацию, может помочь Doug Lea.

Но из моего чтения вашего вопроса, похоже, вы переусердствовали, и я настоятельно рекомендую использовать объединенный подход. (Кроме того, запуск дефрагментационного прохода в памяти с записью не звучит особенно безопасно или забавно.)

Ответ 3

Поскольку вы используете ручки, у вас есть много свободы для перемещения памяти. Я думаю, что использование отдельного потока, вероятно, не самый лучший (самый безопасный или быстрый) способ - думаю, вам лучше использовать тип инкрементного распределителя копирования, где на каждом malloc() или free() вы компактны ( копировать вперед или назад в памяти) некоторое количество выделенных блоков с количеством байтов, которое вы копируете, истощая "бюджет", который периодически reset, до его начального значения (например, при каждом обновлении экрана). (Конечно, копируются только целые блоки.)

Идея состоит в том, что копирование заданного количества байтов занимает довольно предсказуемое количество времени, поэтому вы можете оценить, сколько байтов копирования вы можете безопасно выполнять на обновление экрана, и ограничиться этим. Если в бюджете достаточно времени, вызов malloc() или free() будет полностью дефрагментировать память, в противном случае он будет дефрагментировать его как можно больше в заданных временных ограничениях.

Есть некоторые вопросы, которые я оставляю здесь нерешенными - например. точно как сжать память. Стандартный неинкрементный копировальный распределитель может просто начать выделять с фронта, а затем копировать все в спину (освобождая память спереди), когда память заканчивается, но у вас нет этой свободы здесь. Возможно, вам понадобится эвристика, чтобы решить, нужно ли перемещать блоки вперед или назад. Важно избегать колебаний (один и тот же блок перемещается вперед, а затем назад при последовательных вызовах на malloc() или free()).

Ответ 4

Мы почти точно описали систему, за исключением того, что мы выделяем в слоты фиксированного размера - 256x256, 512x512, 1024x1024 и 2048x2048 текстуры в двух форматах каждый (DXT1 и DXT5) - чтобы избежать управления памятью.

Ответ 5

Я бы рекомендовал постепенный подход. Каждый кадр находит непрерывный блок памяти inuse, который имеет свободное пространство с обеих сторон и перемещает его в зависимости от того, какое из направлений позволит ему поместиться. или вы можете просто переместить все блоки в одном направлении, найти зазор и использовать блок, который лучше всего подходит для него и переместить его. На 360 вам, вероятно, следует использовать поток для перемещения, в то время как на PS3 лучше всего использовать графический процессор для перемещения данных вокруг вас.