Лучшее решение как раз и заключается в использовании виртуальной видеопамяти. Вместо рассмотрения программ-шейдеров как уникального массива данных, как было в прошлом, они рассматриваются как всё остальное и тоже разбивается их на страницы. Допустим, что графический процессор имеет достаточно исполнительных слотов для выполнения инструкций со всей страницы программы-шейдера, тогда вся программа может быть выполнена как последовательность страниц – загрузим страницу программы 1, выполним программу, загрузим следующую страницу, снова её выполним, и так далее, пока весь код не будет выполнен. Слоты инструкций тогда становятся просто кэшем инструкций L1, и всё начинает работать именно так, как в процессоре общего назначения.
Виртуальная видеопамять – именно та особенность, которая позволяет следующему DirectX заявить о "неограниченных ресурсах", поскольку разработчику больше не нужно учитывать длину программ-шейдеров, или объём текстурной памяти, поскольку всё будет размещаться в виртуальном адресном пространстве графического процессора. Конечно, физическое ограничение по ресурсам останется. Что касается программ-шейдеров, то есть программа больше не сможет размещаться в кэше L1 процессора, производительность будет заметно снижаться, поскольку будут происходить дополнительные операции загрузки и освобождения страниц, помимо тактов ожидания, и всё это необходимо будет осуществлять при работе над каждым пикселем. Точно так же мы будем наблюдать относительно быстрое снижение производительности, когда текстуры начнут браться из системной памяти, или, что ещё хуже, из файла подкачки жёсткого диска. На этот случай Microsoft добавила два новых ограничения на ресурсы – за одним из порогов всё уже просто не будет работать, а второй порог является практическим – за его пределами приложения уже не будут работать в реальном времени (определено как 10 fps при 640x480).
Общая модель ввода/вывода.
Существует ряд интересных последствий внедрения унифицированной модели программ-шейдеров, не все из которых видны сразу же. Конечно же, самое наглядное последствие состоит в возможности осуществления текстурирования внутри вершинной программы, и эта особенность очень важна для карт смещения общего назначения, хотя, конечно, ими дело не ограничивается. Ещё одно менее наглядное последствие заключается в возможности запись напрямую в буфер вершин из вершинной программы, что позволяет кэшировать результаты для более поздних проходов. Это становится особенно важно при использовании текстур высоких порядков и карт смещения, позволяя вам тесселировать и смещать модель сразу же, сохраняя результаты в буфере вершин видеопамяти, просто обращаясь к ним во время всех более поздних проходов.
Но, возможно, самое важное добавление станет понятным, если вы скомбинируете оба отмеченных последствия с моделью виртуальной видеопамяти – при этом запись или чтение из текстуры становятся идентичными записи или чтению из любого блока памяти (то есть, игнорируя фильтрацию). С учётом этой особенности и появилась общая модель ввода/вывода следующего DirectX – сейчас вы можете записывать любые данные в память, которые затем вы можете считать на любом другом этапе конвейера, или даже на следующем проходе. Эти данные не должны быть вершинами, пикселями или любыми другими, привязанными к графике – учитывая доступ как к текущему индексу, так и к буферу вершин, вероятно, вы можете использовать систему для создания информации связи, что позволяет определять границы силуэта. Фактически, вы сможете генерировать все объёмы теней, полностью для всех источников света на графическом процессоре за один проход, и затем сохранять каждый из них в памяти для рендеринга в следующие проходы (вместе с освещением, связанным с объёмами), но возникает одна маленькая проблема – за пределами тесселяции современные графические процессоры не могут создавать новые треугольники.
Процессор топологии.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.