Сколько памяти занимает текстура на GPU?


9

Большой png на диске может занимать всего пару мегабайт, но я думаю, что в gpu этот же png хранится в несжатом формате, который занимает гораздо больше места. Это правда? Если это правда, сколько места?

Ответы:


16

JPG и PNG файлы почти всегда будут меньше на диске, чем в памяти; они должны быть распакованы на лету, чтобы получить необработанные данные RGB, что потребует большей вычислительной мощности для загрузки и большего объема оперативной памяти. Многие современные движки предпочитают хранить на диске тот же формат, что и в памяти, что приводит к файлам того же размера, что и требования к текстуре (но также больше, чем PNG или JPG). RGB / RGBA и S3TC / DXTn / BCn являются наиболее широко используемыми форматами, поскольку они считываются прямо в память без какой-либо обработки (текстуры DXT предварительно сжаты).

Итак, это размеры для различных распространенных форматов текстур:

  • L (яркость, например, оттенки серого): ширина * высота * 1 байт.
  • LA (яркость и альфа, общие для шрифтов): ширина * высота * 2 байта.
  • RGB (цвет, без альфа): ширина * высота * 3 байта.
  • RGBA (цвет с альфа): ширина * высота * 4 байта.
  • DXT1 / BC1 (цвет, двоичная альфа): (ширина * высота * 4 байта) / 8 (степень сжатия 8: 1).
  • DXT3 / BC2 (цвет, резкая альфа) / DXT5 / BC3 (цвет, градиент альфа): (ширина * высота * 4 байта) / 4 (степень сжатия 4: 1).

Если вы используете изображение с мипмапами , текстуре потребуется 4/3 больше памяти. Кроме того, ширина и высота текстуры могут быть внутренне округлены, чтобы быть степенью двойки на старых или менее способных аппаратных средствах, а на некоторых очень ограниченных аппаратных средствах, также вынужденных быть квадратными.

Больше информации о DXT: это сжатие с потерями; это означает, что некоторые цветовые данные теряются при сжатии текстуры. Это негативно влияет на вашу текстуру, искажая четкие границы и создавая «блоки» на градиентах; но преимущества намного лучше, чем недостатки (если у вас есть текстура, которая выглядит ужасно плохо в DXT, просто держите ее несжатой; другие компенсируют потерю размера). Кроме того, поскольку пиксели сжимаются блоками фиксированного размера, ширина и высота текстуры должны быть кратны четырем.


Это верно, за исключением вашего первого предложения - формат текстуры на диске может быть любым сильно сжатым форматом, и поэтому он не занимает столько же места на диске, сколько в VRAM, за исключением форматов диска, которые являются прямой сериализацией форматов памяти.

Конечно, можно, но проверьте ресурсы, используемые в играх, созданных с использованием Unreal Engine, Source и т. Д. Они обычно не сжимаются на диске, потому что в настоящее время на диске более чем достаточно места, чтобы оставить ресурсы несжатыми; и сэкономленное пространство не компенсирует дополнительную оперативную память и процессорное время, необходимое для распаковки файлов при каждой загрузке.
r2d2rigo

1
Я думаю, вы найдете, что меняется от двигателя к двигателю. Многие из более крупных движков - особенно те, которые работают на консолях - будут использовать формат диска, идентичный или близкий к формату памяти. Но найти игры, предназначенные только для ПК, довольно просто с ресурсами PNG или JPEG. Если вам придется идти на диск за нагрузкой, которая все равно будет доминировать в вашем времени. Плюс, Майк особенно упоминает PNG и JPEG как формат диска.

В основном правильно, за исключением того, что форматы RGB обычно не существуют на графических процессорах; см .: opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads
Максимус минимальный

9

Очевидно: это зависит от формата.

Давайте возьмем квадратную текстуру 256 на 256 пикселей. Если он несжатый 32-разрядный с альфа-каналом ( Colorв XNA), то он занимает 256 КБ ( 256*256*4байтов).

16-битные форматы (например Bgr565:), очевидно, будут вдвое меньше - 128 КБ .

Тогда вы попадаете на сжатые форматы. В XNA у вас есть DXT1, DXT3 и DXT5 (также известный как S3 Compression ). Это формат сжатия с потерями. Это также блочный формат - это означает, что вы можете выбирать из него (потому что вы знаете, в каком блоке находится пиксель). Это также быстрее, потому что вы используете меньше пропускной способности.

Степень сжатия DXT1 составляет 8: 1, а для DXT3 и DXT5 - 4: 1.

Таким образом, размер изображения DXT1 256x256 составляет 32 КБ . И DXT3 или DXT5 составляет 64 КБ .

И затем есть мипмаппирование . Если это включено, это создает серию изображений в графической памяти, каждая половина размера предыдущего. Так для нашего изображения 256x256: 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. Текстура с mipmapping примерно 133% от размера оригинала.


4

Большинство графических процессоров могут читать только очень специфический формат сжатия. например. BC *, DXT *, не такие форматы, как png. Так что да, по большей части это правда, что .png займет больше места в видеопамяти, чем на диске.

Текстуры могут храниться в сжатом или несжатом виде как в видеопамяти, так и в системной памяти.

Для несжатых текстур общее эмпирическое правило заключается в том, что он займет столько же места в видеопамяти, сколько в несжатом виде в системной памяти.

Для сжатых текстур DXT1. GPU хранит 8 байтов для каждой плитки 4x4 в вашей текстуре. Несжатые данные (8 бит на канал RGB) обычно бывают 4x4x3 = 48 байтов, так что коэффициент сжатия равен 6: 1. Для сжатых текстур DXT3 / DXT5 графический процессор хранит 16 байтов для каждой плитки 4x4 в вашей текстуре. Это немного более низкая степень сжатия 3: 1.

Есть несколько предостережений с несжатыми и сжатыми текстурами:

  • Большая часть памяти выделяется в страницах (размер которых зависит от графического процессора) фиксированного размера. например. 4 КБ и часто это не перераспределяется и совместно используется с другими данными GPU. То есть. если размер вашей текстуры меньше размера страницы, он часто остается размером страницы.

  • У некоторых графических процессоров есть очень специфические требования к выравниванию. В прошлом некоторые графические процессоры требовали, чтобы текстуры имели степень 2. Это часто требовалось для поддержки визуализированного представления (см. Morton Ordering: http://en.wikipedia.org/wiki/Z-order_(curve )) для улучшения локальности доступа при выборке из текстуры. Это означало, что текстуры странных размеров будут дополняться, чтобы сохранить эти требования (обычно это заполнение обрабатывается драйвером). Несмотря на то, что порядок следования демонов не обязательно используется в современном графическом процессоре, может существовать вздутие живота для поддержки конкретных требований графического процессора.

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

  • Если вы включите mipmapping, дополнительные mips будут потреблять в среднем около трети базового уровня mip. YMMV на основе вышеуказанных предостережений.


0

AFAIK, это ширина изображения * высота * BPP, независимо, если это PNG, JPG или BMP. Я не знаю, как устроен DDS или другие сжимаемые форматы.

Mip-mapping увеличит потребность в видеопамяти.

Мои знания в этой теме могут быть немного устаревшими. Я отказался от 3D некоторое время назад.


2
Изображения также имеют высоту (или шаг), которая является количеством байтов между концом одной строки и началом следующей строки пикселей. Никто другой не упомянул об этом, поэтому я могу ошибаться.
CiscoIPPhone

1
Обычно «шаг» относится к длине строки развертки в байтах (как в Freetype и SDL), а «шаг» относится к пространству между элементами, которые могут быть пикселями или линиями сканирования (как в OpenGL и аргументе 3-го слайса Python). Оба значения необходимы для обработки изображения, но «обычно» pitch = width * bytes_per_pixel и stride = 0. Термины часто используются свободно и запутанно, поэтому лучше проверить документацию по API для выбранной вами библиотеки.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.