Если у меня много текстур (скажем, 5+ карт), привязанных к одному и тому же текстурному блоку, будет ли это хуже для кеша, чем если бы у меня было только 2 или 3 текстуры?
Просто добавив к ответу imallett , это правда, что увеличение количества обращений к различным данным текстуры в шейдере увеличит нагрузку на кэш (ы) GPU, но есть несколько других факторов, которые могут существенно повлиять на эффект. Это также возможно усложняется тем фактом, что, подобно кэшам ЦП, в графическом процессоре может быть несколько уровней кеша, т.е. Единица текстуры <= L0 <= L1 <= .. Память
Если у вас есть сцена с минимизацией текстурных данных, будь то из-за перспективы или простого масштабирования, и вы не используете отображение MIP, то вы получите псевдоним. Это не просто создание визуальных артефактов; это очень вероятно, будет проблема производительности.
Как только вы получите псевдоним, адресный доступ к текстуре станет непоследовательным, что не только приведет к перегрузке кешей, но и приведет к появлению большого количества разрывов страниц в DRAM (точнее, разрывов строк), что может быть дорогостоящим. MIP картирование помогает уменьшить непоследовательность.
Возможно, это немного очевидный вариант, но если вы можете использовать сжатие текстур (например, DXTn | ETC * | PVRTC * | и т. Д.) С таргетингом от 8bpp до, скажем, 2bpp, вы можете значительно увеличить эффективность пропускной способности / кэш-памяти памяти за счет факторы от 4х до 16х. Сейчас я не могу говорить о всех графических процессорах, но некоторые схемы сжатия текстур (например, перечисленные выше) настолько просты для аппаратного декодирования, что данные могут оставаться сжатыми по всей иерархии кэша и распаковываться только в текстурном блоке, таким образом эффективно умножая размер этих кэшей.
Очевидно, что некоторые данные, например цели рендеринга, используемые в качестве данных текстуры в последующих рендерах, не могут использовать сжатие текстур. Всякий раз, когда вы можете, используйте наименьший пиксельный формат, который будет работать, то есть, если подойдет 32 / 16bpp (A) RGB, не используйте плавающие форматы 4x32!
Это в некоторой степени связано с примером псевдонимов, приведенным выше, но мы видели случаи, когда создавались большие объекты рендеринга, но тогда они были выбраны очень редко. Строки кэша, будь то в процессорах или графических процессорах, довольно длинные, поэтому, если вы используете только один пиксель в каждой строке кэша, вы будете тратить впустую передачи.
Кроме того, сжатые текстуры WRT обеспечивают сжатие путем эффективного обмена данными между локальными областями текселей. Если у вас нет связного доступа, то, кроме сокращения объема памяти, сжатие, вероятно, не поможет.
Не так много проблем с кешем (ну, если только вычисленные обращения не являются совершенно несогласованными), но доступ к текстуре, который не определяется напрямую UV-координатами, предоставленными вершинами, может быть медленнее, чем те, которые определены непосредственно.
Хотя я подозреваю, что большинство текстур в наши дни будут храниться либо в мозаичном, либо в Morton-подобном (или Twiddled / Swizzled) порядке (или даже в комбинации обоих), некоторые текстуры могут все еще быть в порядке строки сканирования, что означает, что вращение текстура может привести к значительному количеству пропусков кэша / разрывов страниц. К сожалению, я не знаю, как определить, организован ли определенный формат таким образом.
(Для фонового чтения, попробуйте Блинна « Правда о наложении текстур» . FWIW, сделав несколько дальнейших шагов, приведших к использованию текстур с твидовым порядком (то есть порядка Мортона), по крайней мере, на некоторых ранних аппаратных средствах ПК ).
Ответ зависит от того, что вы имеете в виду. Современное оборудование (например, с текстурами без привязки) действительно не заботится о том, сколько текстур «связано». Реальный вопрос в том, сколько вы используете .
Текстуры, как правило, хранят данные в удобной для кэша форме (я думаю, что это кривая Мортона). Если вы будете использовать больше текстур, вы получите больше кеша, так как теперь текстуры конкурируют друг с другом за место.
Это на самом деле сводится к хорошо известной старой эвристике программирования шейдеров: медленное нажатие текстур; не используйте слишком много.