Это хорошая практика, чтобы использовать все доступные текстурные блоки?

При применении нескольких текстур к сетке, например, для рельефного отображения, я обычно привязываю текстуры к первым нескольким фиксированным текстурным блокам, например: diffuse = unit 0, bump = unit 1, specular = unit 2, затем продолжаю использовать их для каждого разные сетки с разными текстурами. Но мне всегда было интересно, почему glActiveTextureподдерживается так много текстурных блоков (в предыдущей ссылке написано, по крайней мере, 80).

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

Это стандартная практика для приложений OpenGL в реальном времени (я полагаю, это также относится к D3D)? И есть ли какие-то неочевидные последствия для производительности при использовании этого подхода? Возможно, накладные расходы памяти?

Современное оборудование на самом деле не имеет концепции точек привязки текстур, как это показывает OpenGL. Скорее, шейдерный блок использует дескриптор (который является просто неким жирным указателем), который потенциально может обращаться к любой текстуре, пока она находится в видеопамяти. Это то, что делает возможными такие вещи, как бесконечные текстуры . Таким образом, большое количество «текстурных блоков», доступных в текущих реализациях, просто пытается «выколоть» эту теперь не относящуюся к делу часть API.

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