Детализированная текстура занимает больше времени для рендеринга?

22

Допустим, я хочу сделать квадрат; его текстура - "square.png."

Проще ли сделать это для компьютера, если текстура просто однотонная?

А что, если это очень шумно текстура с совершенно случайными цветами здесь и там?

Или что, если эта текстура зашумлена в том смысле, что каждый пиксель в ней отличается от одного к другому, но лишь чуть-чуть?

user3491043
источник

Ответы:

39

Как и большинство вещей в разработке игр, и особенно в игровой графике, ответ «это зависит»

Размер текстуры

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

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

Детализация текстур

Содержание ваших текстур в большинстве случаев не влияет на эффективность рендеринга.

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

В отличие от таких форматов, как PNG и JPG, которые более эффективно сжимают в предсказуемых областях изображения и потребляют больше битов в сложных областях, форматы текстур графических процессоров, такие как BTC, ETC, PVRTC или даже необработанный RGBA, используют фиксированное число битов на блок пиксели. Поэтому, делая вашу текстуру более или менее детализированной, сохраняя тот же формат сжатия, вы не измените ее размер, не отразитесь на передаче данных и эффективности, связанной с кэшем.

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

Ветвление и косвенность шейдеров

Вот самая большая звездочка в этой ситуации: вы можете использовать этот цветовой ввод текстуры для принятия решений, как if() ветвь. Здесь детали важны для скорости.

Блоки графического процессора работают с пакетами пикселей в пакетном режиме, выполняя одни и те же инструкции параллельно для нескольких потоков данных. Поэтому, когда некоторые пиксели в блоке занимают одну ветвь, ifа другие пиксели - другую, весь пакет должен пройти через оба ветви (маскируя результаты, которые не относятся ни к одному, ни к другому набору пикселей).

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

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


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

Д.М.Григорий
источник
Текстуры низкого разрешения (например, Minecraft) с большей вероятностью будут загружать тексели для смежных пикселей в кеш, когда в кеш загружается определенный тексель, верно?
user253751
6
@immibis Minecraft имеет крошечные текстуры. По умолчанию это просто 16x16, который так легко вписывается в кеш текстуры каждого ядра, что это даже не смешно: D И да, большинство образцов текстур будут с одним и тем же текселем, если только вы не очень далеко от блока. Это особенно верно, если принять во внимание подразделение экрана - если вы достаточно близко, весь пакет для данного ядра может отображаться на один и тот же тексель: более простой графический процессор DA, вероятно, будет работать лучше для такого текстурирования с низким разрешением - я подозреваю, много усилий тратится на оптимизацию, которая ничем не помогает для Minecraft.
Luaan
1
Примечание: «Использует то же количество байтов на пиксель» на самом деле является ключом к быстрому взлому, который использует графический код. Если бы вы попытались использовать PNG для внутренних целей или даже что-то вроде UTF-8 с переменным размером пикселя, чтобы добраться до этого nпикселя, вам пришлось бы пройти каждый пиксель перед ним. С постоянной шириной в пикселях, это просто start_of_buffer + width * n, что намного быстрее, особенно для больших n.
Фонд Моника иск
@Luaan Я имею в виду, что даже когда вы находитесь далеко от блока, когда он выбирает один тексель (какой бы он ни был первым), он также должен вытягивать несколько соседних в кеш.
user253751
4
Это тот случай, о котором я говорю выше с помощью mipmapping. Чтобы наши образцы не пропускали текстуру, оставляя большие промежутки между повторным использованием кеша или почти отсутствием, мы храним версию 512x512 и версию 256x256 и… иногда вплоть до 1x1. Таким образом, при рисовании текстуры 1024x1024 в формате 16x16 большинство игр на самом деле будут считывать данные с формата 16x16, и с точки зрения эффективности кэш-памяти она работает аналогично случаю Minecraft 16x16. Это также уменьшает искрящиеся артефакты сглаживания от понижающей дискретизации.
DMGregory
1

Вместе с Д.М.Григорием превосходным ответом выше, возможно, есть один случай, когда сложность «текстуры» может повлиять на производительность рендеринга, и это когда результаты предыдущего рендеринга используются в качестве источника в последующем, например карты теней / отражения / карты окружающей среды.

Некоторые современные аппаратные средства могут применять сжатие без потерь к этим буферам: например, PowerVR имеет PVRIC , AMD, Delta Color Compression , а ARM имеет нечто подобное. Целью этих методов сжатия является уменьшение общей пропускной способности, что, в свою очередь, может улучшить производительность рендеринга.

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

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

Кроме того, вы можете найти следующие два вопроса и ответы SE Computer Graphics:

Саймон Ф
источник