emeljan
29.04.2008, 13:13
Год назад я был под впечатлением от MS вообще, полгода назад я был в неправильной команде, а месяц и неделю назад жизнь кипела и бурлила. Однако, наконец, случился неожиданный перерыв и можно, наконец, написать про DX10.
Сразу скажу, я как девелопер на DX10 писал не больше маленькой демки, но в принципе уже имел счастье копаться во внутренностях. Если что, считайте меня евангелистом, гыгыгы.
Буду описывать впечатления высокого уровня, низкого - детали реализации. Опять же, каждый пункт очень не подробный, про каждый - можно писать большой детальный отдельный пост. Пожелания принимаются :)
За один раз все не описать, сегодня будут, пожалуй, самые большие изменения - инфраструктурные. Нужно отметить, что большинство из них относятся не только к DX10, но и вообще ко всем версиям DX на Висте.
В Висте совершенно новая driver model (WDDM - Windows Display Driver Model, в девичестве LDDM - Longhorn Display Driver Model), это самое большое изменение в модели видео-драйвера со времен, когда вообще появилось hardware acceleration.
Очень поверхностно о том, как было раньше, в XDDM (XP Display Driver Model), по хорошему тут надо писать отдельный пост.
В XDDM каждый вызов DX добавлял токен в так называемый “command buffer”, в независимом от видеокарты формате. Когда рантайм решал, что буфер уже достаточно велик, звалась функция драйвера в kernel mode, ей передавался этот буфер, и драйверу нужно его разобрать и каким-то одному ему известным способом передать видеокарте. Никаких функций драйвера в user mode не было как таковых.
К сожалению (нет, к счастью!), оказалось, что видеокарты очень динамично развиваются, и формат command buffer усложнялся и усложнялся. Появились сложные шейдеры, которые нужно компилировать в микрокод видеокарты, появились заточки под разные игры и так далее. В результате, в kernel mode оказался десятимегабайтный с гаком кусок кода, который в случае любой ошибки вообще говоря убивает систему. Подавляющее большинство BSOD в XP - display driver, самый сложный и опасный драйвер в системе.
Вторая часть проблем про разделение видеокарты между несколькими процессами. В XDDM у OS нет ни способа установить приоритет, ни менеджить видеопамять, ни вообще выполнять какой-то разумный шедулинг вызовов DX от разных процессов. Чуть что - Device Lost, и живой девайс остается у одного процесса.
В новой driver model есть разделение между user mode и kernel mode частью драйвера. Все вызовы DX напрямую идут в user-mode driver, который подготавливает сразу hardware-dependent буфер, который иногда флашит в kernel, где он идет в видеокарту. Идея в том, что всю тяжелую работу можно выполнять в user-mode части, а в kernel фактически только переслать собранный буфер в DMA-трансфер видеокарте. Во-первых, если user-mode driver упадет, ничего страшного не случится - закроется конкретное приложение, но не вылетит OS. Во-вторых, у драйвера больше контроля, когда и сколько kernel-mode calls делать, причем эти вызовы не тяжелые. В-третьих, рантайм становится совсем тонкий - нет никаких command buffers, просто напрямую вызываются функции драйвера.
Кроме того, между user-mode и kernel-mode частями есть наш GPU Scheduler, который может выбирать, какие собранные буфера отправлять видеокарте, то есть менеджить GPU на много процессов.
Там еще куча важных моментов, но все их описывать надо не в рамках этого поста, а то я его никогда не напишу.
В новой driver model есть виртуализована видеопамять - то есть, если ее не хватает, ресурсы будут переноситься в системную. Так как контроль за аллокациями видеопамяти теперь у OS, а не у драйвера, это можно делать гораздо эффективнее, чем POOL_MANAGED в XDDM. Сейчас это работает без железной поддержки - GPU Scheduler перед передачей DMA-пакета карточке загружает все нужные текстуры в видеопамять. Он достаточно умный и умеет подгружать их заранее, пока GPU занят другим и свободна шина. Если приложение уйдет в fullscreen - все остальное из видеопамяти выбросят по мере необходимости, если в windowed - то будет пытаться распределять память по текущим процессам. Собственно, совершенно аналогично обычной памяти.
Важный вопрос - контроль над производительностью со стороны приложения, когда хочется гарантировать наличие ресурса в видеопамяти. Насколько я понимаю, ответ сейчас такой - fullscreen и контроль над размером аллокаций.
То есть, мужики, больше не бывает Device Lost, никогда, всем радовацца полчиса. Если станет активным другое приложение - OS в случае необходимости выгрузит ресурсы и восстановит их обратно. Все еще есть “Device Removed”, но это уже экзотические случаи вроде “выдернули видеокарту” или “поставили новую версию драйвера”, о таких сценариях не надо беспокоиться играм.
В DX10 больше нет капсов, как таковых. Гарантируется наличие всей функциональности, за редкими исключениями типа наличия блендинга для некоторых текстурных форматов (это поправили в DX10.1), то есть если карта поддерживает DX10, то она обязана держать последнюю версию шейдеров в полном объеме, поддерживать все форматы текстур, все возможные режимы фильтрации, стенсила и всего-всего-всего. Более того, для DX10 написали спек правил растеризации треугольников и прочего добра, то есть теперь ожидается и то, что картинка на разных видеокартах на одинаковом коде всегда будет одинаковой и совпадать с эталонным софтверным растеризатором. Где не так - баг производителя карточки.
В будущем новая функциональность будет появляться кусками, типа набор фич DX10.1, DX11 и т.д.
Это в общем-то должно очень радовать девелоперов и существенно улучшать тот бардак, какой был в DX9.
Много в API и driver model изменилось для того, чтобы уменьшить DIP cost на CPU. На XP он очень серьезный, тяжелая игра может проводить около десятка миллисекунд (а то и больше), в вызовах DX. В них мало времени занимает сам рантайм, и много драйвер.
Основное, что изменилось - сама driver model, в которой рантайм фактически ничего не делает, а сразу предоставляет исполнение драйверу.
На стороне API появились State Objects, которые можно прекомпилировать при создании и потом быстро устанавливать на видеокарте и Constant Buffers как средство более эффективно менеджить обновления констант шейдеров. Об этом подробнее - в следующих сериях.
Мужики из Крайтека пишут, что действительно видели серьезное уменьшение DIP cost в Крайзисе на DX10, впрочем, я уверен, текущим драйверам еще есть куда стремиться.
Вся эта инфраструктурная радость и является основной технической причиной того, что DX10 нет на XP. Переносить новую driver model на XP не представляется возможным - слишком много изменений в ядре OS, переносить все фичи DX10 на старую driver model невозможно (виртуализация и шедулинг, к примеру, принципиально не заживет). Есть все еще компромиссы - переносить только хардверные фичи DX10 на старую driver model, это прилично работы для нас и очень много работы для IHV - писать поддержку новых фич для новой и старой driver model, и поведение API будет разным на разных OS. Или предоставить Layer, который будет предоставлять DX9-функциональность с DX10-API, но это может и так написать девелопер, и остается открытым вопрос с представленим капсов с DX10 API.
Видимо, уперлись в нехватку ресурсов для девелопмента. Мне лично кажется, что технически это все сложно и тяжело, но теоретически возможно.
Это не мои размышления.
Сразу скажу, я как девелопер на DX10 писал не больше маленькой демки, но в принципе уже имел счастье копаться во внутренностях. Если что, считайте меня евангелистом, гыгыгы.
Буду описывать впечатления высокого уровня, низкого - детали реализации. Опять же, каждый пункт очень не подробный, про каждый - можно писать большой детальный отдельный пост. Пожелания принимаются :)
За один раз все не описать, сегодня будут, пожалуй, самые большие изменения - инфраструктурные. Нужно отметить, что большинство из них относятся не только к DX10, но и вообще ко всем версиям DX на Висте.
В Висте совершенно новая driver model (WDDM - Windows Display Driver Model, в девичестве LDDM - Longhorn Display Driver Model), это самое большое изменение в модели видео-драйвера со времен, когда вообще появилось hardware acceleration.
Очень поверхностно о том, как было раньше, в XDDM (XP Display Driver Model), по хорошему тут надо писать отдельный пост.
В XDDM каждый вызов DX добавлял токен в так называемый “command buffer”, в независимом от видеокарты формате. Когда рантайм решал, что буфер уже достаточно велик, звалась функция драйвера в kernel mode, ей передавался этот буфер, и драйверу нужно его разобрать и каким-то одному ему известным способом передать видеокарте. Никаких функций драйвера в user mode не было как таковых.
К сожалению (нет, к счастью!), оказалось, что видеокарты очень динамично развиваются, и формат command buffer усложнялся и усложнялся. Появились сложные шейдеры, которые нужно компилировать в микрокод видеокарты, появились заточки под разные игры и так далее. В результате, в kernel mode оказался десятимегабайтный с гаком кусок кода, который в случае любой ошибки вообще говоря убивает систему. Подавляющее большинство BSOD в XP - display driver, самый сложный и опасный драйвер в системе.
Вторая часть проблем про разделение видеокарты между несколькими процессами. В XDDM у OS нет ни способа установить приоритет, ни менеджить видеопамять, ни вообще выполнять какой-то разумный шедулинг вызовов DX от разных процессов. Чуть что - Device Lost, и живой девайс остается у одного процесса.
В новой driver model есть разделение между user mode и kernel mode частью драйвера. Все вызовы DX напрямую идут в user-mode driver, который подготавливает сразу hardware-dependent буфер, который иногда флашит в kernel, где он идет в видеокарту. Идея в том, что всю тяжелую работу можно выполнять в user-mode части, а в kernel фактически только переслать собранный буфер в DMA-трансфер видеокарте. Во-первых, если user-mode driver упадет, ничего страшного не случится - закроется конкретное приложение, но не вылетит OS. Во-вторых, у драйвера больше контроля, когда и сколько kernel-mode calls делать, причем эти вызовы не тяжелые. В-третьих, рантайм становится совсем тонкий - нет никаких command buffers, просто напрямую вызываются функции драйвера.
Кроме того, между user-mode и kernel-mode частями есть наш GPU Scheduler, который может выбирать, какие собранные буфера отправлять видеокарте, то есть менеджить GPU на много процессов.
Там еще куча важных моментов, но все их описывать надо не в рамках этого поста, а то я его никогда не напишу.
В новой driver model есть виртуализована видеопамять - то есть, если ее не хватает, ресурсы будут переноситься в системную. Так как контроль за аллокациями видеопамяти теперь у OS, а не у драйвера, это можно делать гораздо эффективнее, чем POOL_MANAGED в XDDM. Сейчас это работает без железной поддержки - GPU Scheduler перед передачей DMA-пакета карточке загружает все нужные текстуры в видеопамять. Он достаточно умный и умеет подгружать их заранее, пока GPU занят другим и свободна шина. Если приложение уйдет в fullscreen - все остальное из видеопамяти выбросят по мере необходимости, если в windowed - то будет пытаться распределять память по текущим процессам. Собственно, совершенно аналогично обычной памяти.
Важный вопрос - контроль над производительностью со стороны приложения, когда хочется гарантировать наличие ресурса в видеопамяти. Насколько я понимаю, ответ сейчас такой - fullscreen и контроль над размером аллокаций.
То есть, мужики, больше не бывает Device Lost, никогда, всем радовацца полчиса. Если станет активным другое приложение - OS в случае необходимости выгрузит ресурсы и восстановит их обратно. Все еще есть “Device Removed”, но это уже экзотические случаи вроде “выдернули видеокарту” или “поставили новую версию драйвера”, о таких сценариях не надо беспокоиться играм.
В DX10 больше нет капсов, как таковых. Гарантируется наличие всей функциональности, за редкими исключениями типа наличия блендинга для некоторых текстурных форматов (это поправили в DX10.1), то есть если карта поддерживает DX10, то она обязана держать последнюю версию шейдеров в полном объеме, поддерживать все форматы текстур, все возможные режимы фильтрации, стенсила и всего-всего-всего. Более того, для DX10 написали спек правил растеризации треугольников и прочего добра, то есть теперь ожидается и то, что картинка на разных видеокартах на одинаковом коде всегда будет одинаковой и совпадать с эталонным софтверным растеризатором. Где не так - баг производителя карточки.
В будущем новая функциональность будет появляться кусками, типа набор фич DX10.1, DX11 и т.д.
Это в общем-то должно очень радовать девелоперов и существенно улучшать тот бардак, какой был в DX9.
Много в API и driver model изменилось для того, чтобы уменьшить DIP cost на CPU. На XP он очень серьезный, тяжелая игра может проводить около десятка миллисекунд (а то и больше), в вызовах DX. В них мало времени занимает сам рантайм, и много драйвер.
Основное, что изменилось - сама driver model, в которой рантайм фактически ничего не делает, а сразу предоставляет исполнение драйверу.
На стороне API появились State Objects, которые можно прекомпилировать при создании и потом быстро устанавливать на видеокарте и Constant Buffers как средство более эффективно менеджить обновления констант шейдеров. Об этом подробнее - в следующих сериях.
Мужики из Крайтека пишут, что действительно видели серьезное уменьшение DIP cost в Крайзисе на DX10, впрочем, я уверен, текущим драйверам еще есть куда стремиться.
Вся эта инфраструктурная радость и является основной технической причиной того, что DX10 нет на XP. Переносить новую driver model на XP не представляется возможным - слишком много изменений в ядре OS, переносить все фичи DX10 на старую driver model невозможно (виртуализация и шедулинг, к примеру, принципиально не заживет). Есть все еще компромиссы - переносить только хардверные фичи DX10 на старую driver model, это прилично работы для нас и очень много работы для IHV - писать поддержку новых фич для новой и старой driver model, и поведение API будет разным на разных OS. Или предоставить Layer, который будет предоставлять DX9-функциональность с DX10-API, но это может и так написать девелопер, и остается открытым вопрос с представленим капсов с DX10 API.
Видимо, уперлись в нехватку ресурсов для девелопмента. Мне лично кажется, что технически это все сложно и тяжело, но теоретически возможно.
Это не мои размышления.