WGF / LDDM

Помните рекламу женской косметики? «Исследования показали, что цвет лица улучшается на 37%, а состояние кожи на 70%». Прелесть, не правда ли? Давайте прикинем, возможно, даже с большей степенью серьезности, насколько новая операционная система с кодовым именем Longhorn и входящий в ее состав набор графический API улучшат возможности разработчиков и качество игр. Конечно, мы не претендуем на процентную точность, и цифра 55% в заголовке этой статьи ничем не обоснована. Но, выглядит неплохо, не так ли?

Новая архитектура драйверов и графическая подсистема Longhorn
Вокруг столько кодовых имен (Avalon, Longhorn, WGF 1.0 и 2.0 и т.д.), что немудрено запутаться. Попробуем нарисовать четкую картину и расставить все по своим полочкам.


Longhorn
Новая операционная система, которая придет на смену различным вариантам Windows XP, ориентировочно в 2006 году. В отличие от Windows XP и Windows 2000, основанных на разных версиях одного ядра и имевших практически идентичную драйверную модель, Longhorn сулит нам существенные перемены не только в интерфейсной части и API, но и в самом сердце системы, в ядре, архитектуре памяти и менеджмента ресурсов. Новая операционная система будет поддерживать два типа драйверов (две драйверные модели), одну оставленную для совместимости со старыми драйверами — модель XP/2000 и вторую — новые драйверы, специально разработанные для Longhorn и последующих версий этой OS. Эта новая модель (стандарт на драйверы и их взаимодействие с ядром OS и API) называется LDM (Longhorn Driver Model) и важнейшей и наиболее интересной для нас ее частью является отвечающая за всю графику LDDM (Longhorn Display Driver Model) — т.е. модель дисплейного драйвера Longhorn. Все принципиально новые графические возможности будут реализовываться с помощью новых LDDM драйверов, драйверы построенные по старой модели смогут обеспечить только базовый, уже доступный в XP уровень аппаратной графической поддержки.

Разумеется, новые приложения могут обращаться и к старым и к новым API, старые приложения знают только о старых API. API контактируют с системой и оборудованием (посредством драйверов). Старые драйверы подключаются в режиме совместимости через драйверный интерфейс Windows XP (XPDM), новые — в новом режиме Longhorn (LDM).


LDM
Интересно, что новая драйверная модель предусматривает два уровня — базовый и продвинутый. Базовые драйверы могут быть написаны и для текущего аппаратного обеспечения, не требуя от аппаратуры каких либо функций, специально рассчитанных на новые возможности Longhorn. Эти драйверы будут обеспечивать все минимально необходимое для работы новых API и новой драйверной модели, но не всегда оптимально с точки зрения производительности или удобства реализации. Продвинутые драйверы требуют специальной поддержки железом некоторых моментов, в первую очередь связанных с менеджментом ресурсов, виртуальной памятью и конкурентными потоками заданий от приложений к аппаратным устройствам. Т.е. железо должно разрабатываться с учетом спецификаций LDM и понимать некоторые специальные системные структуры данных. Тогда, новые функции ядра и драйверной модели Longhorn будут выполняться наиболее быстрым, надежным и эффективным способом.

Разумеется, вначале, сразу после выхода системы, многие драйверы будут работать в режиме совместимости с XP или в базовом режиме LDM — ведь специально разработанное с учетом Longhorn железо в широком ассортименте появится не сразу. Но постепенно будут появляться все новые и новые устройства с полноценной, продвинутой поддержкой LDM и в первую очередь это коснется графических ускорителей — для них особенно важны эти новые возможности системы. Посудите сами — новые драйверы смогут серьезно снизить задержки системных вызовов (основной бич современного аппаратного ускорения 3D), повысить эффективность управления памятью и ресурсами, причем автоматически, не напрягая приложения и программистов.

Конкретно в новой драйверной модели и новой дисплейной драйверной модели (LDDM) нас ждет следующий набор важных принципиальных новшеств:

1. Виртуализация состояния. Каждое приложение имеет собственное состояние всех настроек графического конвейера, они не пересекаются и не мешают друг другу.
2. Виртуализация и менеджмент ресурсов (выделение для них памяти, реальной и виртуальной, перенос их в локальную память ускорителя и обратно и т.д.) выполняется автоматически и полностью прозрачен для приложений. Единственная ситуация отказа в выделении новых ресурсов — исчерпанная виртуальная память. В продвинутой драйверной модели ресурсы могут быть недоступными в любой момент и создаваться в памяти на лету, по требованию — т.е. когда придет время к их отрисовке и они станут действительно видимы. В базовой драйверной модели все ресурсы должны быть загружены и доступны, но по мере работы приложения ресурсы могут вытесняться из основной памяти в файл подкачки, причем с учетом частоты обращений к ним.
3. Виртуализация исполнения. Приложения могут одновременно и конкурентно использовать аппаратные ускорители, не мешая друг другу. Система сама распределяет время, выделяемое на исполнение разных потоков команд.
4. Валидация команд. Происходит проверка параметров и команд на допустимость (как в OpenGL) — что сильно повышает стабильность работы приложений. В продвинутой драйверной модели эта проверка может осуществляться полностью аппаратно (!) без нагрузки на CPU .
5. Существенное снижение расходов (задержек) на вызовы API, смену параметров и настроек (стейтов) ускорителя и другие операции, проходящие через драйвер и оборудование. Фактически — самое важно для практических разработчиков новшество, способное заметно увеличить производительность игр и разнообразие визуальных эффектов.
6. Возможно горячее подключение графических устройств.

Эти и другие прелести сулит переход на новую драйверную модель и новое графическое ядро OS Longhorn — согласитесь, перспективы радужные. Посмотрим, как все будет реализовано на практике. А пока, детальнее обрисуем обстановку в области графических API:


Графические API в Longhorn

В самом верху нашей схемы — пользовательские и системные графические приложения. Ниже — линейка различных API к которым они обращаются. Пройдем по порядку, слева направо:

• WGF 2.0 — новый 3D API разработанный для Longhorn и будущих OS и идущий на смену DX 9 и его вариантам (можно сказать что это новое название для D3D10). Имеет существенные новшества и отличия в графическом конвейере (о чем далее) и таким образом предоставляет принципиально новые возможности для аппаратного ускорения трехмерной графики. Новый конвейер (на схеме под WGF 2.0) требует и новых драйверов, старые драйверы в режиме совместимости не обеспечивают необходимую для WGF 2.0 функциональность. Этот API предназначен для нового железа, которое будет разработано уже с учетом Longhorn и WGF 2.0 — старые ускорители, включая текущих лидеров, также не смогут обеспечить всю необходимую функциональность и для них будет достаточно задействовать API WGF 1.0 (см. ниже).
• D3D9 и другие старые 3D API — оставлены для совместимости. Прекрасно обходятся старыми драйверами и с точки зрения приложений ничем не отличаются от того, что мы имели ранее в Windows 2000/XP. API D3D9 соответствует самой последней спецификации — 9.0c. Все более старые API (включая D3D5, 6 и 7) исключены и эмулируются трансляцией в вызовы D3D9, причем все устаревшие фиксированные функции эмулируются шейдерами. Забытый всеми D3D RM (отложенный режим построения изображения) полностью изъят и больше не поддерживается даже для совместимости.
• DX VA — DirectX Video Acceleration — новая подсистема и API аппаратного ускорения работы с видео потоками. Рассчитана на высокопроизводительную аппаратную обработку видеопотоков, вплоть до HD-DVD разрешений. Включает, в том числе, и систему защиты контента от перехвата и модификации, как во время его обработки на CPU, так и на GPU. Для аппаратного ускорения могут быть задействованы специальные шейдеры исполняемые на GPU. Защищенные данные, передаваемые по шинам общего назначения шифруются и могут быть дешифрованы затем аппаратно соответствующими видеокартами. Более того, предусмотрена система аутентификации с помощью которой система проверяет подлинность драйвера, а драйвер — подлинность ускорителя. Интересно, насколько эта система будет жизненна и как быстро ее обойдут ;-)
• WGF 1.0 — тоже новый API, функционально основанный на графических возможностях D3D9 с некоторыми небольшими изменениями и новшествами (иногда его упоминают как D3D9.L, а мы для разнообразия будем звать его D3D9+). Хотя с точки зрения программиста сам API и отличается от D3D9 во многих аспектах и вызовах, в том числе заметно облегчая менеджмент ресурсов, и некоторые другие вопросы, графический конвейер остался прежним и обеспечивает нам хорошо знакомую по D3D9 гибкость и функциональность, но не более того. Т.е. разрабатывать приложения под WGF 1.0 несколько удобнее, чем под старый D3D9, но доступ к принципиально новым возможностям они не получат. Хотя и будут работать быстрее, стабильнее и надежнее, в силу перечисленных выше достоинств LDDM, которые WGF 1.0 по мере возможности задействует. Этот API идеально подходит для современного железа, в случае, если драйверы к нему будут переписаны под новую модель LDM, что может быть сделано достаточно быстро — уже к выходу операционной системы или ранее. Из основных новшеств отметим поддержку разделяемых между приложения и процессами ресурсов (возможен один виртуальный буфер кадра на несколько приложений) и автоматический менеджмент памяти, ограниченный только доступной виртуальной памятью, но не ограниченный физическими ресурсами локальной или системной памяти.
• DWM/Avalon — надстройка над WGF 1.0. Это графический оконный API и новый менеджер окон (DWM — Desktop Window Manager), сильно отличающийся по подходу к управлению и рендерингу окон от того, что было ранее, в том числе в Windows XP. Теперь, как и в Unix (X-Windows) каждое приложение строит изображение в собственном графическом пространстве, некоем виртуальном окне, которое имеет собственный графический контекст, состояние, и никак не взаимодействует с другими виртуальными буферами других приложений. А менеджер DWM обеспечивает непосредственное финальное отображение этих заранее готовых окон, их перемещение и сортировку относительно друг друга (наложение). Причем, без особых помех могут быть реализованы и более сложные схемы, чем традиционная, например трехмерный оконный менеджер. Такой подход увеличивает расход памяти, но избавляет нас от забот по постоянной перерисовке окон в случае изменения положения верхних, перетаскивания и других операций. Больше никаких неприятных вздрагиваний, подпорченных на некоторое время изображений в момент пиковой нагрузки приложения и т.д. Теперь нет и такого понятия как эксклюзивное владение экраном — оно эмулируется. Нет и неприятной возможности потерять ресурсы в результате переключений полноэкранных приложений. Новый WDM будет обеспечивать и всевозможные мульти-мониторные удовольствия, от привязки отдельных окон к отдельным мониторам и независимых рабочих столов на разных дисплеях, до классического мультиэкрана (один рабочий стол, разбитый на несколько дисплеев). Из основных новшеств, также отметим поддержку масштабирования шрифтов и окон, дисплеев с нестандартными и высокими значениями DPI и использование D3D9 шейдеров для визуальных эффектов в пользовательском интерфейсе, отрисовки и анимации окон и элементов управления.
• OpenGL — тут все осталось по прежнему, есть два варианта — либо устанавливаемый ICD драйвер от производителя ускорителя, с собственным графическим конвейером (рыжий блок) либо трансляция вызовов OpenGL 1.4 в WGF 1.0, и далее стандартным путем в XPDM или LDM графический D3D драйвер. Второй вариант, как известно, работает медленно, для игр не годиться, и предназначен для совместимости прочих приложений.

Теперь обратим внимание на то, как путешествуют наши вызовы, из приложений, до самого железа. Основное новшество — разбитый на две части графический драйвер. Первая часть (рыжий блок, помеченный как user mode) исполняется на пользовательском уровне и не может нанести серьезных помех работе системы в случае своего ошибочного или нестабильного поведения. Ее назначение — обеспечивать все функции драйвера, которые могут быть выполнены без критического и тесного (интенсивного) контакта с железом. Таких функций предостаточно, начиная с проверки параметров, компиляции и оптимизации шейдеров и кончая сбором настроек и преобразованием форматов во внутренние аппаратные представления. На этом же уровне существует и устанавливаемый драйвер с графическим конвейером OpenGL. Далее идет ядро системы, и наиболее интересная нам часть — графическое ядро DXG — здесь мы уже имеем дело с нулевым уровнем исполнения (привилегированным) и неверная работа этого кода может полностью нарушить нормальную работу системы. И здесь же расположена критическая часть графического драйвера, исполняемая также в привилегированном режиме. Такое разделение повышает стабильность работы системы — т.к. объем чужеродного кода исполняемого на нулевом уровне и чреватого глобальным крахом системы в случае неверной работы, уменьшается в несколько раз. Интересно, что формирование списка команд, который потом отправляется на аппаратную отрисовку, идет полностью в пользовательской части драйвера, таким образом, основное время, проводимое в драйвере также будет приходиться на защищенный режим. Обещается и более простая структура новых драйверов LDM — что должно не только еще более снизить вероятность ошибки, но и сократить время разработки новых драйверов, особенно для будущего, созданного уже с учетом Longhorn железа.


Новый графический конвейер и WGF 2.0
Итак, самое вкусное. Новый графический конвейер.

1. Очень детализированная спецификация возможностей ускорителя. Отсутствуют CAPS — все ускорители должны уметь все, что входит в спецификацию. Т.е. все возможности доступные в API требуемы и стандартны. Больше никакого разнобоя, все под контролем Microsoft.
2. Единая унифицированная программная модель для всех типов шейдеров, вершинных, пиксельных и других, если такие будут. Новая шейдерная модель, больше гибкости, меньше ограничений, практически отсутствуют лимиты на сложность шейдеров.
3. Высокая степень независимости GPU от CPU — полностью автоматическая проверка параметров и исполнение списков отрисовки, автоматическое создание, распределение и подкачка ресурсов. Автоматическое аппаратное переключение контекста и работа с несколькими потоками команд. Минимальные задержки при передаче параметров от приложения к ускорителю — все это в новой модели LDDM.
4. Новые стадии графического конвейера — экспорт промежуточных результатов, для последующей повторной обработки и геометрический шейдер (далее подробнее).
5. Новые форматы данных, для HDR и нормалей, задаваемые структуры данных и даже массивы из ресурсов (!). Скажем, кубическая текстура теперь представляется массивом из 6 обычных текстур, возможны и более произвольные варианты.
6. Новый алгоритм компрессии для нормалей — фактически — 3Dc от ATI.
7. Целочисленная адресация текстур (доступ к ней как к массиву констант), несколько выборок одновременно.

А вот так он выглядит на блок-схеме:

Обсудим основные новшества слева направо. Во-первых, совершенно униформичный (с одинаковыми возможностями) доступ к текстурам возможен теперь на трех стадиях конвейера — на стадии вершинного шейдера, затем на стадии геометрического шейдера и на стадии пиксельного шейдера, разумеется. Везде доступны сэмплеры, позволяющие выбрать сразу несколько соседних значений из текстуры по одним рассчитанным текстурным координатам, что может существенно упростить реализацию собственных алгоритмов фильтрации или работы с нетривиальными представлениями данных и всяческими специальными картами. После уже привычной стадии вершинного шейдера следует геометрический шейдер (Geometry Shader). Что это такое? Это шейдер, которому доступны уже собранные из вершин треугольники перед отрисовкой, как целостные объекты. Т.е. он может производить какие-либо операции над треугольниками целиком. В том числе, учитывая какие-то контрольные или дополнительные параметры вершин. Можно изменить параметры, можно рассчитать новые, специфичные для всего треугольника, и передать их затем в пиксельный шедер. Можно пометить треугольник предикатом (чтобы затем обработать его по разному, в зависимости от значения предиката), или выбросить его из кандидатов на отрисовку. К сожалению этот шейдер не может, как ожидалось ранее, произвольно создавать новую геометрию и новые треугольники на выходе, но сразу за ним следует еще одна новая стадия — вывод потока (Stream Out).

Наконец-то официально можно вернуть обратно в буфер (память) данные, прошедшие обработку в вершинной части конвейера, до передачи и отрисовки их в пиксельной части. Затем их можно снова использовать по своему усмотрению. Таким образом можно реализовать множество различных вещей, ранее невозможных или возможных но очень неудобным образом. Например, можно плодить новую геометрию, в том числе реализовать тесселяцию поверхностей на большее кратное число треугольников по тому или иному алгоритму. Для этого надо воспользоваться двумя проходами вершинной части, где первый экспортирует поток данных и коэффицентами деления у потоков между ними (помните, еще в DX 9с появилась возможность устанавливать коэффициент, на который будут делиться индексы вершин при собирании их из нескольких независимых потоков, отдельный для каждого потока). Это несколько менее естественно, чем просто генерация новых вершин и новой геометрии в вершинном шейдере, но теперь это есть и, наконец, то это стало возможным. Можно даже сразу зациклить данные по маршруту выход -> вход и воспользовавшись предикатами осуществить циклический отбор и деградирование геометрии, например, упростив модель.

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

Очень важным новшеством является канонизация HLSL — отныне его компилятор станет неотделимой частью ядра API, а не отдельным блоком. Теперь, компиляцию будет осуществлять WGF 2.0, при этом, обращаясь к драйверу за «советом», что и как оптимизировать и затем будет передавать драйверу уже промежуточный байткод, который по хорошему должен исполняться WGF 2.0 ускорителем практически напрямую, что впрочем, не исключает еще одной стадии оптимизации шейдера в драйвере прямо на уровне бинарного кода, перед исполнением:

Надеемся, что HLSL станет основным средством для написания шейдеров, а ассемблерный код отойдет на второй план, как это случилось в свое время с CPU. Ведь HLSL оставляет много просторов для будущего развития архитектуры и получения новых приростов скорости за счет простой перекомпиляции для нового железа.

В самой низкоуровневой модели новых шейдерных процессоров можно отметить два основных новшества:

- широкое распространение механизма предикатов, и оптимизация их работы в железе, для реализации гибких условий без особого падения производительности.
- существенное снижение количественных ограничений — число констант и длина шейдеров теперь практически не лимитированы, существенно выросло число временных регистров. Вложенность выборок текстур не ограничивается, как в базовой модели 2.0.

фактически, все это напоминает скорее сильно улучшенную модель 3.0, чем что-то принципиально новое, но этого и не надо, единственный возможный архитектурный шаг — произвольный доступ к памяти данных и команд еще не готов случиться, по нескольким причинам, и на пути к нему нас еще ждет произвольная генерация новых объектов, вершин например, которая тоже пока что не доступна в WGF 2.0).


Вероятные сроки и сценарии развития
Чуть позже, когда будет больше информации, в отдельной статье мы обсудим возможности новых шейдеров WGF 2.0 (условно говоря, SM 4.0) а пока подведем итоги и поговорим о перспективах. Итак, несмотря на то, что не все ожидания были оправданы (например, относительно геометрического шейдерного процессора), можно признать скорее революционное, чем эволюционное значение WGF 2.0. Количество переходит в качество. В первую очередь благодаря отказу от множества неприятных рудиментов и наметившейся стройности подхода, зачастую несвойственной Microsoft (берегись OpenGL!). Здесь и проверка параметров, и централизованная компиляция, и поддержка многозадачности и наконец-то менеджер окон отделенный от GDI и других непосредственных графических API. Чего только стоит виртуализация ресурсов и снижение задержек при передаче параметров ускорителю. Возможность вывода данных из конвейера — один из давно и горячо ожидаемых хитов. Нет сомнений, что все здорово и даже не на 55%, а на все 85% лучше того, что было, но вот вопрос — когда?

Скорее всего, ближе к концу 2006 года. Потому что должна выйти операционная система, затем должно появиться оборудование, затем должны быть написаны и отлажены полноценные LDDM драйверы «продвинутой» породы. И только тогда мы получим полноценную связку WGF 2.0 + продвинутый LDDM драйвер с Longhorn железом, а еще через год-полтора и первые реально получающие от них преимущества приложения.

Возможно, если все пойдет хорошо, и при определенной доле везения, ATI или NVIDIA удастся реализовать WGF 2.0 функции уже в следующем поколении (NV5X и иже от ATI) и даже порадовать нас некими демками на эту тему, но печальный опыт с NV3X и третьими шейдерами показал, что угадать финальную спецификацию заранее непросто и, скорее всего, только следующее поколение (NV6X и иже от ATI) будет действительно полноценным WGF 2.0 железом. А с учетом разработки приложений, можно говорить и о поколении NV7X в конце 2007 года. Все нормально — операционные системы живут долго, и приходят на рынок не сразу, а WGF 2.0 будет доступно только на Longhorn и последующих системах на ее основе.

Интересно, как Microsoft сделала еще один шаг к жесткому контролю над развитием графического рынка — теперь ускорители будут вынуждены иметь практически одинаковые возможности и разница будет только в качестве и скорости их реализации. Никаких капсов, никакого произвола форматов — все поддерживают всё. И всё — это то всё, которое решила включить в очередную версию своего графического API компания Microsoft. Конечно, будут, как и раньше хаки — возможности специфические для вендора, но так или иначе задействуемые из D3D приложений, пусть и не столь официальным путем как в OpenGL с его расширениями. Но реализовать их станет труднее. Что ж, и ранее было понятно, кто тут рулевой, разделяет и властвует ;-)

Впрочем, как обычно, ждать не так уж и долго. Скоро сами все увидим!