В DirectX 9 стали использоваться программируемые пиксельные и вершинные шейдеры версий 2.0, 2.Х и 3.0. Версия 2.0 была принята в роли минимальной спецификации, которую должны поддерживать все графические процессоры DirectX 9. Версия же 2.Х была предназначена для более производительных графических процессоров, которые могут сделать немного больше, чем требует спецификация 2.0. Наконец, программы версии 3.0 предназначены для нового поколения видеокарт, которые будут доступны в 2004 году. Пиксельные шейдеры 2.0 содержат, по меньшей мере, в шесть раз больше регистров общего назначения, чем в модели программирования DirectX 8, а число доступных слотов инструкций возросло в квадратичной зависимости – в результате чего функциональность пиксельных программ была поднята почти до того же уровня, что и у вершинных программ в DirectX 8. В то же время возросла потребность в числе обращений к текстурам в вершинных программах, особенно для приложений, желающих использовать карты смещения общего назначения. В версии 3.0 пиксельные и вершинные шейдеры имеют очень похожие возможности, причём настолько, что использование отдельных аппаратных блоков для вершинных и пиксельных программ становится избыточным. В результате все модели программ версии 4.0 идентичны по синтаксису и набору функций, что позволяет соединять различные аппаратные блоки в один. Это приводит ещё и к тому, что любое увеличение производительности шейдеров увеличивает скорость выполнения и вершинных, и пиксельных программ, но для этого надо решить проблему, связанную с подсистемами памяти современных графических процессоров.
Виртуальная видеопамять.
Подсистема памяти на большинстве потребительских графических процессоров устроена таким образом, что она в значительной мере нацелена на компьютерную графику – всё, с чем она работает, это текстурные объекты, вершины, треугольники и программы-шейдеры. Если нужно отобразить некоторую геометрию с картой текстур, и в то же время нужной текстуры в видеопамяти нет, то в видеопамять будет загружаться вся текстура вместе с её MIP-уровнями – только после этого графический процессор сможет начать рендеринг. Но при этом возникают некоторые проблемы. Во-первых, такой способ слишком ресурсоёмок – для данного кадра могут никогда не использовать все текстурные объекты, типа MIP-уровней, - фактически, нужный вам MIP-уровень вряд ли потребляет максимальные объём памяти и пропускную способность, как первый уровень. Особенно это относится к играм в больших открытых окружениях, где большинство текстур на экране находятся так далеко, что для них требуются только самый низкий MIP-уровень. Вся избыточная информация не была бы проблемой, если бы на графическую карту отсылалась бы одна текстура, но в случаях, когда карте приходится постоянно обращаться к AGP/системной памяти, приложение начинает заметно "тормозить". Пропускная способность памяти на современных графических ускорителях примерно в десять раз превышает пропускную способность шины AGP, в результате чего пользователь отчётливо ощущает ситуацию, когда у карты заканчивается видеопамять – частота кадров приложения начинает спорадически меняться.
Одним из возможных решений является осуществление всего текстурирования напрямую из памяти AGP. При этом возникающие проблемы памяти исчезли бы, но только по причине того, что вся передача для каждого кадра происходила бы по одной и той же медленной шине. То есть мы исправляем появление периодических "тормозов" путём замедления всего процесса – наверняка есть и лучшее решение.
Поскольку графические процессоры всё больше напоминают их "собратьев" общего назначения, то, возможно, одно из решений заключается в эмуляции того, как центральный процессор компьютера управляет памятью. Действительно, у процессоров общего назначения возникают во многом схожие проблемы, ведь не все программы могут уместиться в кэшах процессора, а выполнение программы напрямую из оперативной памяти было бы очень медленным. Решение заключается в использовании виртуальной памяти вместо физической. При этом программисту не нужно больше думать о том, каков объём кэша или системной памяти в системе – вместо этого все операции с памятью производятся в виртуальном адресном пространстве, которое разделено на маленькие страницы (обычно размером 4 кбайт). Весь процесс зависит от реализации управления каждой страницей, чтобы она была в кэше в нужные моменты, и в системной памяти, если к ней не обращаются. Или в файле подкачки на жёстком диске, если оперативной памяти не будет хватать.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.