Допустим, я хочу сделать квадрат; его текстура - "square.png."
Проще ли сделать это для компьютера, если текстура просто однотонная?
А что, если это очень шумно текстура с совершенно случайными цветами здесь и там?
Или что, если эта текстура зашумлена в том смысле, что каждый пиксель в ней отличается от одного к другому, но лишь чуть-чуть?
Ответы:
Как и большинство вещей в разработке игр, и особенно в игровой графике, ответ «это зависит»
Разрешение вашей текстуры может повлиять на скорость рендеринга. Чем больше пикселей в нем содержится, тем больше необработанных данных можно загрузить в графический процессор, и тем меньше текстур мы можем разместить в кэше за раз, поэтому шейдер может выполнить больше пауз, ожидая нужную часть текстуры. попасть в кеш.
Использование mipmapping может уменьшить влияние этого. С помощью mipmaps мы храним цепочку сокращенных версий текстуры, которая поначалу звучит как еще больше памяти, чтобы ее можно было просматривать. Но это позволяет нам читать из меньших версий, когда текстура отображается на экране небольшого размера (например, удаленный объект в перспективе), поэтому наши образцы лучше используют кеш текстуры, а не перепрыгивают через нее. Это также уменьшает алиасинг.
Содержание ваших текстур в большинстве случаев не влияет на эффективность рендеринга.
Цвет - это просто набор чисел, поскольку речь идет о графическом процессоре, поэтому его не волнует, что это за цифры, он просто проводит их через математику таким же образом. Это не делает ничего необычного, как вспоминание "О, я видел пиксель в этом зеленом цвете раньше, я просто повторно использую тот же результат, который я рассчитал в прошлый раз, когда я видел этот вход", так что все ли ваши текстуры одного цвета или случайные искры, ваш графический процессор выполняет ту же работу.
В отличие от таких форматов, как PNG и JPG, которые более эффективно сжимают в предсказуемых областях изображения и потребляют больше битов в сложных областях, форматы текстур графических процессоров, такие как BTC, ETC, PVRTC или даже необработанный RGBA, используют фиксированное число битов на блок пиксели. Поэтому, делая вашу текстуру более или менее детализированной, сохраняя тот же формат сжатия, вы не измените ее размер, не отразитесь на передаче данных и эффективности, связанной с кэшем.
Но, если вы используете особый вид деталей, который ваше предыдущее сжатие не сохраняет должным образом, вы можете быть вынуждены изменить свое изображение целиком на другой формат, что может снова изменить его размер данных.
Вот самая большая звездочка в этой ситуации: вы можете использовать этот цветовой ввод текстуры для принятия решений, как if() ветвь. Здесь детали важны для скорости.
Блоки графического процессора работают с пакетами пикселей в пакетном режиме, выполняя одни и те же инструкции параллельно для нескольких потоков данных. Поэтому, когда некоторые пиксели в блоке занимают одну ветвь, ifа другие пиксели - другую, весь пакет должен пройти через оба ветви (маскируя результаты, которые не относятся ни к одному, ни к другому набору пикселей).
Если ваши входные данные изменяются плавно / предсказуемо, то, скорее всего, у вас будет много блоков, которым требуется только одна ветвь, и эти случаи с двумя ветвями будут ограничены узкими полосами вокруг границы перехода. Но если вы вводите в случайном порядке, мы ожидаем, что большинство блоков займет обе ветви и замедлит рендеринг.
Это также может произойти, если вы используете одну текстуру для управления поиском во второй текстуре, такой как карта искажения или индекса. Если первая текстура перемещается случайным образом, то мы будем выбирать из разбросанных случайных пятен второй текстуры, делая менее последовательным использование нашего кэша текстуры и дольше ожидая получения необходимых данных, в среднем.
Итак, в целом: нет, содержание текстуры не оказывает большого влияния на скорость рендеринга, за исключением случаев, когда это происходит. ;)
nпикселя, вам пришлось бы пройти каждый пиксель перед ним. С постоянной шириной в пикселях, это просто start_of_buffer + width * n, что намного быстрее, особенно для больших n.
Вместе с Д.М.Григорием превосходным ответом выше, возможно, есть один случай, когда сложность «текстуры» может повлиять на производительность рендеринга, и это когда результаты предыдущего рендеринга используются в качестве источника в последующем, например карты теней / отражения / карты окружающей среды.
Некоторые современные аппаратные средства могут применять сжатие без потерь к этим буферам: например, PowerVR имеет PVRIC , AMD, Delta Color Compression , а ARM имеет нечто подобное. Целью этих методов сжатия является уменьшение общей пропускной способности, что, в свою очередь, может улучшить производительность рендеринга.
Чем проще данные, будь то глубина или цвет (целое число или число с плавающей точкой), тем лучше будут работать эти схемы. Конечно, я бы не советовал преднамеренно упрощать вывод рендеринга только для того, чтобы они лучше функционировали, но в некоторых случаях может помочь отказ от использования зашумленных данных.
Кроме того, выполнение выборки буферов кадра / глубины, которые используют эти схемы, в тщетной попытке уменьшить пропускную способность, не поможет, потому что они, скорее всего, будут основаны на блоках.
Кроме того, вы можете найти следующие два вопроса и ответы SE Computer Graphics: