Зачем нужны мозаичного ресурса?
Требуются мозаичные ресурсы, поэтому меньше памяти графического процессора (GPU) тратится впустую при хранении областей поверхностей, к которым приложение знает, что доступ к ним не будет осуществляться, а оборудование может понять, как фильтровать смежные плитки.
В графической системе (то есть операционной системе, драйвере дисплея и графическом оборудовании) без поддержки мозаичного ресурса графическая система управляет всеми выделениями памяти Direct3D с степенью детализации ресурсов. Для буфера весь буфер является подресурсом. Для текстуры (например, Texture2D) каждый уровень MIP является подресурсом; для массива текстур (например, Texture2DArray) каждый уровень MIP в заданном срезе массива является подресурсом. Графическая система лишь предоставляет возможность управлять сопоставлениями выделения памяти на этом уровне вложенных ресурсов. В контексте мозаичного ресурса "сопоставление" означает, что данные видны GPU.
Предположим, что приложение знает, что определенной операции отрисовки необходим доступ лишь к небольшой части цепочки MIP-карт (возможно, даже не к полной области определенной MIP-карты). В идеале приложение должно сообщить графической системе об этой потребности. Тогда графическая система обеспечит сопоставление лишь необходимого количества памяти графического процессора, не задействуя лишнюю память. На самом деле, без поддержки плиток ресурсы, графическая система может быть проинформирована только о памяти, которая должна быть сопоставлена с GPU с степенью детализации ресурсов (например, диапазоном полных уровней MIP-карты, к которым можно получить доступ). В графической системе также невозможен отказ от требования выделения памяти, поэтому возможно использование излишне большого количества памяти графического процессора для полного сопоставления всех вложенных ресурсов перед выполнением команды отрисовки, ссылающейся на какую-либо часть памяти. Это лишь одна проблема, которая затрудняет использование большого объема памяти в Direct3D без поддержки плиток ресурсов.
Direct3D 11 поддерживает поверхности Texture2D с заданной стороной до 16384 пикселей. Изображение, размером 16 384 пкс в ширину, 16 384 в высоту и 4 байтами на пиксель потребляет 1 ГБ видеопамяти (и добавление MIP-карт удваивает это значение). На практике редко возникает необходимость использовать в одной операции отрисовки весь 1 ГБ памяти.
Некоторые разработчики игр создают модели поверхностей ландшафтов размером плоть до 128 на 128 тыс. пикселей. На существующих графических процессорах это становится возможным благодаря разбиению поверхности на плитки, которые достаточно малы для обработки оборудованием. Приложение должно определить, какие плитки могут потребоваться, и загрузить их в кэш текстур графического процессора — систему программной подкачки. Значительный недостаток этого подхода заключается в том, что оборудование ничего не знает о разбиении по страницам: когда часть изображения должна быть показана на экране, на который пересекается плитка, оборудование не знает, как выполнять фиксированную функцию (то есть эффективную) фильтрацию по плиткам. Это означает, что приложение, управляющее собственным программным разбиением на плитки, вынуждено использовать ручную фильтрацию текстур в коде шейдера (что требует очень большого количества ресурсов, если требуется высококачественная анизотропная фильтрация) и (или) тратить память на создание вокруг плиток полей, которые содержат данные из соседних плиток, чтобы аппаратная фильтрация с фиксированной функцией могла продолжать оказывать некоторую помощь.
Если мозаичное представление выделений поверхностей может быть первоклассным компонентом в графической системе, приложение может сообщить оборудованию, какие плитки сделать доступными. Таким образом меньшее количество памяти графического процессора тратится на хранение областей поверхности, доступ к которым, как известно приложению, осуществляться не будет. Оборудованию при этом известно, как производить фильтрацию соседних плиток, чтобы разрешить часть проблем, с которыми сталкиваются разработчики, выполняющие программное разделение на плитки самостоятельно.
Однако для того, чтобы решение было полнофункциональным, необходимо каким-то образом решить проблему того, что вне зависимости от наличия поддержки разбиения поверхности на плитки максимальные размеры поверхности в данный момент составляют 16 384 пикселей, что значительно меньше 128 тысяч, которые уже требуются приложениям. Одним из подходов может быть просто требование поддержки текстур большего размера оборудованием, однако такой подход связан с значительными расходами и компромиссами. Путь фильтра текстур Direct3D 11 и путь отрисовки уже насыщены с точки зрения точности, поддерживая текстуры 16K с другими требованиями, такими как поддержка экстентов окна просмотра, падающих с поверхности во время отрисовки, или поддержка текстуры, обтекающей края поверхности во время фильтрации. Существует возможность найти компромисс так, чтобы по мере увеличения размера текстуры за пределы 16 тысяч пикселей определенным образом снижались функциональные возможности или точность. Однако даже при этой уступке могут потребоваться дополнительные затраты на оборудование в плане способности всей аппаратной системы к переходу к текстурам увеличенного размера.
Со значительным увеличением размера текстур возникает проблема, состоящая в том, что координаты текстуры одинарной точности с плавающей запятой (и связанные интерполяторы для поддержки растеризации) не располагают достаточной точностью, чтобы безошибочно указывать расположение на поверхности. Это приводит к дрожанию при фильтрации текстур. Затратным решением является требование поддержки интерполятора двойной точности, но при наличии разумной альтернативы оно представляется избыточным.
Альтернативное имя для плиток ресурсов — "разреженная текстура". "Разреженный" передает как мозаичный характер ресурсов, так и, возможно, основную причину их облицовки - что не все из них, как ожидается, будут сопоставлены сразу. Фактически, приложение может создать ресурс с плиткой, в котором данные не будут создаваться для всех регионов и mips ресурса, намеренно. Таким образом, само содержимое может быть разреженным, и сопоставление содержимого в памяти GPU в данный момент времени будет подмножеством этого (еще более разреженным).
Другой сценарий, который может обслуживаться мозаичными ресурсами, — это включение нескольких ресурсов разных размеров или форматов для совместного использования одной и той же памяти. Иногда приложения имеют особые наборы ресурсов, которые не должны использоваться одновременно, или ресурсы, которые создаются только для очень краткого использования и затем удаляются, после чего создаются другие ресурсы. Форма общности, которая может выпадать из "плиток ресурсов", заключается в том, что пользователь может указать несколько разных ресурсов в одной (перекрывающейся) памяти. Другими словами, создание и уничтожение "ресурсов" (которые определяют размер, формат и т. д.) может быть отделено от управления памятью, выделяемой для этих ресурсов, с точки зрения приложения.
Связанные темы