Как исправить ошибку Direct3D 9.0c. Директ 3d
DirectX 11 (Direct3D, D3D) для Windows 7
После установки операционной системы Windows, если Вы впоследствии пожелаете сыграть какую-то мало-мальски приличную игру, либо будете работать с трёхмерной графикой, хотите добиться отличного качества воспроизведения звуковых устройств, Вам необходимо установить последнюю версию Direct X.
Технология DirectX (Direct3D, D3D) позволяет использовать все возможности видео- и аудиоустройств, клавиатуры, миши, джойстика, сетевой коммуникации игр, давая доступ программам обращаться к их ресурсам напрямую.
Но в этом есть некоторые нюансы, которые необходимо знать:
1. Ограничения операционной системы
- Последняя версия для Windows 95/98/98SE/ME/2000 — 8.0 (пользователи этих версий Windows не могут установить DirectX старше 8.0)
- для Windows XP — 9.0c (пользователи Windows XP не могут установить DirectX 10, 11)
- Windows Vista/7 — 11.1c
2. Кроме того, существуют аппаратные ограничения
Видеокарта, в которой присутствует поддержка только Direct X 10 — не сможет работать в режиме Direct X 11.
3. Программные ограничения
Игры, написанные под Direct X 11 могут не запуститься либо на видеокарте Direct X 10, либо под Windows XP и более ранней версией Windows, а если запустится, то в упрощённом графическом режиме.
Как же разобраться во всём этом многообразии Direct X, систем, карт и программ?
На самом деле всё просто: необходимо с веб-сайта Microsoft скачать веб инсталлятор и запустить его:
Программа сама скачает и установит все необходимые компоненты DirectX (Direct3D, D3D). Пакет включает все предыдущие версии и дополнения библиотек, а также обновленные компоненты для Windows x86 и x64. Скачать полную версию можно так же с сайта компании Microsoft.
Как узнать какая версия DirectX установлена
Необходимо запустить Средство диагностики DirectX (в меню Пуск команду Выполнить и ввести dxdiag):
Полная версия статьи DirectX 11 (Direct3D, D3D) для Windows 7 скачать бесплатно Rus
nevermind.mypage.ru
Важные изменения в Direct3D 11 по сравнению с Direct3D 9 - UWP app developer
- 02/08/2017
- Время чтения: 7 мин
В этой статье
[ Обновлено для приложений UWP в Windows 10. Статьи о Windows 8.x см. в архиве ]
Резюме
В этой статье рассматриваются основные различия между DirectX 9 и DirectX 11.
Direct3D 11 — это по сути тот же тип API, что и Direct3D 9, а именно виртуализованный интерфейс нижнего уровня для взаимодействия с графическим оборудованием. Он также по-прежнему позволяет выполнять графические операции в разнообразных аппаратных реализациях. Структура графического API изменилась по сравнению с Direct3D 9; идея контекста устройства была расширена. Также был добавлен специальный API для графической инфраструктуры. Ресурсы, хранящиеся на устройстве Direct3D, получили принципиально новый механизм для полиморфизма данных — представление ресурсов.
Базовые функции API
В Direct3D 9, прежде чем использовать интерфейс для взаимодействия с API Direct3D, его приходилось создавать. В играх UWP с использованием Direct3D 11 вы вызываете статическую функцию D3D11CreateDevice для создания устройства и контекста устройства.
Устройства и контекст устройства
Устройство Direct3D 11 представляет собой виртуализованный графический адаптер. Оно используется для создания ресурсов в видеопамяти, например для отправки текстур графическому процессору (GPU), создания представлений на основе ресурсов текстуры и цепочек буферов и для создания дискретизаторов текстур. Полный перечень способов использования интерфейса устройства Direct3D 11 приведен в разделах ID3D11Device и ID3D11Device1.
Контекст устройства Direct3D 11 используется для настройки состояния конвейера и создания команд отрисовки. Например, цепочка отрисовки Direct3D 11 использует контекст устройства для настройки цепочки отрисовки и рисования сцены (см. ниже). Контекст устройства применяется для доступа к видеопамяти (сопоставления), которую используют ресурсы устройства Direct3D, а также для обновления данных подресурсов, например данных буфера констант. Полный перечень способов использования контекста устройства Direct3D 11 приведен в разделах ID3D11DeviceContext и ID3D11DeviceContext1. Обратите внимание, что большинство наших образцов используют мгновенный контекст для обработки напрямую на устройстве, но Direct3D 11 также поддерживает и отложенные контексты устройств, которые применяются преимущественно для многопоточности.
Чтобы получить маркер устройства и маркер контекста устройства, в Direct3D 11 вызывается D3D11CreateDevice. В этом методе также запрашивается определенный набор аппаратных функций и извлекаются сведения об уровнях компонентов Direct3D, которые поддерживает графический адаптер. Дополнительные сведения об устройствах, контекстах устройств и потоковой модели см. в разделе Вводные сведения об устройстве в Direct3D 11.
Инфраструктура устройства, буферы кадров и представления однобуферной прорисовки
В Direct3D 11 для настройки адаптера устройств и конфигурации оборудования применяется API DirectX Graphics Infrastructure (DXGI) с использованием COM-интерфейсов IDXGIAdapter и IDXGIDevice1. Буферы и другие ресурсы окон (видимые и закадровые) создаются и настраиваются при помощи определенных интерфейсов DXGI. Реализация шаблона фабрики IDXGIFactory2 получает ресурсы DXGI, такие как буфер кадров. Поскольку DXGI принадлежит цепочка буферов, интерфейс DXGI используется для представления кадров на экране. Дополнительные сведения об этом см. в IDXGISwapChain1.
Используйте IDXGIFactory2 для создания цепочки буферов, совместимой с вашей игрой. Необходимо создать цепочку буферов не для HWND, а для основного окна или для композиции (взаимодействие с XAML).
Ресурсы устройств и представления ресурсов
Direct3D 11 поддерживает дополнительный уровень полиморфизма для ресурсов видеопамяти — для представлений. По сути там, где раньше был один объект Direct3D 9 для текстуры, теперь есть два объекта: ресурс текстуры, где хранятся данные, и представление ресурсов, которое определяет способ использования представления для отрисовки. Представление на основе ресурса позволяет использовать ресурс для определенной цели. Например, ресурс двухмерной текстуры создается в форме ID3D11Texture2D, затем на его основе создается представление ресурсов шейдера (ID3D11ShaderResourceView), и его можно использовать как текстуру в шейдере. Представление однобуферной прорисовки (ID3D11RenderTargetView) можно также создать на основе того же ресурса двухмерной текстуры и использовать его как поверхность рисования. В другом примере те же пиксельные данные представлены в двух разных форматах пикселей с использованием двух отдельных представлений на основе одного ресурса текстуры.
Основной ресурс необходимо создать со свойствами, совместимыми с типом представлений, которые будут созданы из него. Например, если ID3D11RenderTargetView применяется к поверхности, ее нужно создать с флагом D3D11_BIND_RENDER_TARGET. Формат поверхности DXGI должен быть совместим с отрисовкой (см. DXGI_FORMAT).
Большинство ресурсов, которые вы используете для отрисовки, унаследованы от интерфейса ID3D11Resource, в свою очередь унаследованного от ID3D11DeviceChild. Буферы вершин, буферы индексов, буферы констант и шейдеры — все это ресурсы Direct3D 11. Входные макеты и состояния дискретизатора унаследованы напрямую от ID3D11DeviceChild.
Представления ресурсов используют значение перечисления DXGI_FORMAT для указания формата пикселей. Не каждый D3DFMT поддерживается как DXGI_FORMAT. Например, в DXGI не существует формата RGB 24 бита на пиксель, эквивалентного D3DFMT_R8G8B8. Также эквиваленты BGR существуют не для каждого формата RGB (DXGI_FORMAT_R10G10B10A2_UNORM эквивалентен D3DFMT_A2B10G10R10, но прямого эквивалента D3DFMT_A2R10G10B10 нет). Во время сборки следует преобразовать содержимое в этих устаревших форматах в поддерживаемые форматы. Полный перечень форматов DXGI см. в перечислении DXGI_FORMAT.
Ресурсы устройств Direct3D (и представления ресурсов) создаются до обработки сцены. Контексты устройств используются для настройки цепочки отрисовки, как описано ниже.
Контекст устройства и цепочка отрисовки
В Direct3D 9 и Direct3D 10.x был единственный объект устройства Direct3D, который управлял созданием ресурсов, состоянием и рисованием. В Direct3D 11 интерфейс устройства Direct3D также управляет созданием ресурсов, но для управления состоянием и операциями рисования используется контекст устройства Direct3D. Вот пример использования контекста устройства (интерфейса ID3D11DeviceContext1) для настройки цепочки отрисовки:
- Настройка и очистка представлений однобуферной прорисовки (и представления трафарета глубины)
- Настройка буфера вершин, буфера индексов и входного макета для этапа сборщика входных данных (этапа IA)
- Привязка вершинного и обычного построителей текстуры к конвейеру
- Привязка буферов констант к шейдерам
- Привязка представлений текстуры и дискретизаторов к построителю текстуры
- Рисование сцены
Когда вызван один из методов ID3D11DeviceContext::Draw, рисуется сцена в представлении однобуферной прорисовки. По завершении рисования адаптер DXGI используется для представления законченного кадра вызовом IDXGISwapChain1::Present1.
Управление состоянием
В Direct3D 9 для управления параметрами состояния использовался большой набор отдельных переключателей, которые настраивались с помощью методов SetRenderState, SetSamplerState и SetTextureStageState. Поскольку Direct3D 11 не поддерживает устаревший конвейер с фиксированной функцией, метод SetTextureStageState заменен написанием построителей текстуры (PS). Не существует эквивалента блоку состояний Direct3D 9. В Direct3D 11 для управления состоянием используются 4 вида объектов состояния, что упрощает группировку состояний отрисовки.
Например, вместо использования метода SetRenderState с D3DRS_ZENABLE вы создаете объект DepthStencilState с этим и другими связанными параметрами состояния и используете его для изменения состояния в процессе отрисовки.
При переносе приложений Direct3D 9 в объекты состояния учитывайте, что различные комбинации состояний представлены в виде неизменяемых объектов состояния. Их следует создать один раз и многократно использовать, пока они остаются действительными.
Уровни функций Direct3D
В Direct3D появился новый механизм определения аппаратной поддержки — уровни функций. Благодаря уровням функций становится проще узнать о возможностях графического адаптера, поскольку можно запросить четко определенный набор функций GPU. Например, уровень функций 9_1 реализует функции графических адаптеров Direct3D 9, включая модель шейдера 2.x. Так как 9_1 — самый нижний уровень функций, можно предположить, что все устройства будут поддерживать вершинный и обычный построители текстуры — те же этапы, которые поддерживала программируемая модель шейдера Direct3D 9.
Ваша игра будет использовать D3D11CreateDevice для создания устройства и контекста устройства Direct3D. Вызывая эту функцию, вы предоставляете список уровней функций, которые поддерживает ваша игра. На основе этого списка функция вернет самый высокий поддерживаемый уровень функций. Например, если ваша игра может использовать текстуры BC4/BC5 (функцию оборудования DirectX 10), следует включить в список поддерживаемых уровней функций как минимум уровни 9_1 и 10_0. Если игра работает на оборудовании DirectX 9 и текстуры BC4/BC5 использовать нельзя, то D3D11CreateDevice вернет 9_1. Затем ваша игра может переключиться на другой формат текстур (и более мелкие текстуры).
Если вы решили расширить игру Direct3D 9, добавив поддержку более высоких уровней функций Direct3D, лучше сначала закончить перенос существующего графического кода Direct3D 9. После переноса игры в Direct3D 11 будет проще добавить дополнительные пути отрисовки с более сложной графикой.
Подробное объяснение поддержки уровней функций см. в разделе Уровни функций Direct3D. Полный перечень функций Direct3D 11 см. в разделах Функции Direct3D 11 и Функции Direct3D 11.1.
Уровни функций и программируемый конвейер
С момента появления Direct3D 9 оборудование непрерывно совершенствовалось, и в программируемый графический конвейер было добавлено несколько новых дополнительных этапов. Набор параметров для графического конвейера зависит от уровня функций Direct3D. Уровень функций 10.0 включает этап геометрического построителя текстуры с дополнительным потоковым выводом для многопроходной отрисовки на GPU. Уровень функций 11_0 включает шейдер поверхности и шейдер доменов для использования с аппаратным мозаичным представлением. Уровень функций 11_0 также включает полную поддержку шейдеров DirectCompute, тогда как уровни функций 10.x поддерживают только ограниченную форму DirectCompute.
Все шейдеры написаны на языке HLSL с использованием профиля шейдеров, соответствующего уровню функций Direct3D. Профили шейдеров имеют прямую совместимость, поэтому шейдер HLSL, скомпилированный с использованием vs_4_0_level_9_1 или ps_4_0_level_9_1, будет работать на всех устройствах. Профили шейдеров не совместимы с предыдущими уровнями, поэтому шейдер, скомпилированный с использованием vs_4_1, будет работать только на устройствах с уровнями функций 10_1, 11_0 или 11_1.
В Direct3D 9 для управления константами шейдеров использовался общий массив с методами SetVertexShaderConstant и SetPixelShaderConstant. Direct3D 11 использует буферы констант, которые представляют собой ресурсы, аналогичные буферу вершин или буферу индексов. Буферы констант эффективно обновляются благодаря своей структуре. Вам не нужно размещать все константы шейдера в одном глобальном массиве. Вместо этого вы объединяете константы в логические группы и управляете ими при помощи одного или нескольких буферов констант. При переносе игры Direct3D 9 в Direct3D 11 запланируйте такую организацию буферов констант, чтобы можно было обновлять их соответствующим образом. Например, сгруппируйте константы шейдера, которые не обновляются с каждым кадром, в отдельный буфер констант. Тогда вам не придется постоянно отправлять эти данные графическому адаптеру вместе с более динамическими константами шейдера.
Примечание. Большинство приложений Direct3D 9 широко использовали шейдеры, но иногда в комбинации с традиционной моделью на основе фиксированной функции. Обратите внимание, что Direct3D 11 использует только программируемую модель шейдеров. Устаревшие компоненты Direct3D 9 с фиксированными функциями использовать не рекомендуется.
docs.microsoft.com
 Шаг 1: Восстановить записи реестра, связанные с ошибкой 9.0c |
| Редактирование реестра Windows вручную с целью удаления содержащих ошибки ключей Ошибка 9.0c не рекомендуется, если вы не являетесь специалистом по обслуживанию ПК. Ошибки, допущенные при редактировании реестра, могут привести к неработоспособности вашего ПК и нанести непоправимый ущерб вашей операционной системе. На самом деле, даже одна запятая, поставленная не в том месте, может воспрепятствовать загрузке компьютера! В связи с подобным риском мы настоятельно рекомендуем использовать надежные инструменты очистки реестра, такие как WinThruster (разработанный Microsoft Gold Certified Partner), чтобы просканировать и исправить любые проблемы, связанные с Ошибка 9.0c. Используя очистку реестра, вы сможете автоматизировать процесс поиска поврежденных записей реестра, ссылок на отсутствующие файлы (например, вызывающих ошибку 9.0c) и нерабочих ссылок внутри реестра. Перед каждым сканированием автоматически создается резервная копия, позволяющая отменить любые изменения одним кликом и защищающая вас от возможного повреждения компьютера. Самое приятное, что устранение ошибок реестра может резко повысить скорость и производительность системы. Предупреждение: Если вы не являетесь опытным пользователем ПК, мы НЕ рекомендуем редактирование реестра Windows вручную. Некорректное использование Редактора реестра может привести к серьезным проблемам и потребовать переустановки Windows. Мы не гарантируем, что неполадки, являющиеся результатом неправильного использования Редактора реестра, могут быть устранены. Вы пользуетесь Редактором реестра на свой страх и риск. Перед тем, как вручную восстанавливать реестр Windows, необходимо создать резервную копию, экспортировав часть реестра, связанную с Ошибка 9.0c (например, Direct3D):
Следующие шаги при ручном редактировании реестра не будут описаны в данной статье, так как с большой вероятностью могут привести к повреждению вашей системы. Если вы хотите получить больше информации о редактировании реестра вручную, пожалуйста, ознакомьтесь со ссылками ниже. Мы не несем никакой ответственности за результаты действий, совершенных по инструкции, приведенной ниже - вы выполняете эти задачи на свой страх и риск. Windows XPhttp://www.theeldergeek.com/windows_xp_registry.htm Windows 7http://www.theeldergeek.com/windows_7/registry_edits_for_win7.htm Windows Vistahttp://support.microsoft.com/kb/2688326 - LetMeFixItMyselfAlways |
Шаг 2: Проведите полное сканирование вашего компьютера на вредоносное ПО |
| Есть вероятность, что ошибка 9.0c может быть связана с заражением вашего компьютера вредоносным ПО. Эти вредоносные злоумышленники могут повредить или даже удалить файлы, связанные с Ошибки во время выполнения. Кроме того, существует возможность, что ошибка 9.0c связана с компонентом самой вредоносной программы. Совет: Если у вас еще не установлены средства для защиты от вредоносного ПО, мы настоятельно рекомендуем использовать Emsisoft Anti-Malware (скачать). В отличие от других защитных программ, данная программа предлагает гарантию удаления вредоносного ПО. |
Шаг 3: Очистить систему от мусора (временных файлов и папок) с помощью очистки диска (cleanmgr) |
| Со временем ваш компьютер накапливает ненужные файлы в связи с обычным интернет-серфингом и повседневным использованием компьютера. Если такие ненужные файлы иногда не удалять, они могут привести к снижению быстродействия Direct3D или к ошибке 9.0c, возможно вследствие конфликтов файлов или перегрузки жесткого диска. Удаление таких временных файлов при помощи утилиты Очистка диска может не только устранить ошибку 9.0c, но и существенно повысить быстродействие вашего компьютера. Совет: Хотя утилита Очистки диска является прекрасным встроенным инструментом, она удаляет не все временные файлы с вашего компьютера. Другие часто используемые программы, такие как Microsoft Office, Firefox, Chrome, Live Messenger, а также сотни других программ не поддаются очистке при помощи программы Очистка диска (включая некоторые программы Microsoft Corporation). Из-за недостатков утилиты Windows Очистка диска (cleanmgr) мы настоятельно рекомендуем использовать специализированное программное обеспечение очистки жесткого диска / защиты конфиденциальности, например WinSweeper (разработано Microsoft Gold Partner), для очистки всего компьютера. Запуск WinSweeper раз в день (при помощи автоматического сканирования) гарантирует, что ваш компьютер всегда будет чист, будет работает быстро и без ошибок 9.0c, связанных с временными файлами. Как запустить Очистку диска (cleanmgr) (Windows XP, Vista, 7, 8 и 10):
|
Шаг 4: Обновите драйверы устройств на вашем компьютере |
| Ошибки 9.0c могут быть связаны с повреждением или устареванием драйверов устройств. Драйверы с легкостью могут работать сегодня и перестать работать завтра по целому ряду причин. Хорошая новость состоит в том, что чаще всего вы можете обновить драйверы устройства, чтобы устранить проблему с Ошибка 9.0c. В связи с временными затратами и общей сложностью обновления драйверов мы настоятельно рекомендуем использовать утилиту обновления драйверов, например DriverDoc (разработана Microsoft Gold Partner), для автоматизации этого процесса. |
Шаг 5: Используйте Восстановление системы Windows, чтобы "Отменить" последние изменения в системе |
| Восстановление системы Windows позволяет вашему компьютеру "отправиться в прошлое", чтобы исправить проблемы Ошибка 9.0c. Восстановление системы может вернуть системные файлы и программы на вашем компьютере к тому времени, когда все работало нормально. Это потенциально может помочь вам избежать головной боли от устранения ошибок, связанных с 9.0c. Пожалуйста, учтите: использование восстановления системы не повлияет на ваши документы, изображения или другие данные. Чтобы использовать Восстановление системы (Windows XP, Vista, 7, 8 и 10):
|
Шаг 6: Удалите и установите заново программу Direct3D, связанную с Ошибка 9.0c |
| Инструкции для Windows 7 и Windows Vista:
Инструкции для Windows XP:
Инструкции для Windows 8:
После того, как вы успешно удалили программу, связанную с Ошибка 9.0c (например, Direct3D), заново установите данную программу, следуя инструкции Microsoft Corporation. Совет: Если вы абсолютно уверены, что ошибка 9.0c связана с определенной программой Microsoft Corporation, удаление и повторная установка программы, связанной с Ошибка 9.0c с большой вероятностью решит вашу проблему. |
Шаг 7: Запустите проверку системных файлов Windows ("sfc /scannow") |
| Проверка системных файлов представляет собой удобный инструмент, включаемый в состав Windows, который позволяет просканировать и восстановить поврежденные системные файлы Windows (включая те, которые имеют отношение к Ошибка 9.0c). Чтобы запустить проверку системных файлов (Windows XP, Vista, 7, 8 и 10):
|
Шаг 8: Установите все доступные обновления Windows |
| Microsoft постоянно обновляет и улучшает системные файлы Windows, связанные с Ошибка 9.0c. Иногда для решения проблемы Ошибки во время выполнения нужно просто напросто обновить Windows при помощи последнего пакета обновлений или другого патча, которые Microsoft выпускает на постоянной основе. Чтобы проверить наличие обновлений Windows (Windows XP, Vista, 7, 8 и 10):
|
Шаг 9: Произведите чистую установку Windows |
| Предупреждение: Мы должны подчеркнуть, что переустановка Windows займет очень много времени и является слишком сложной задачей, чтобы решить проблемы Ошибка 9.0c. Во избежание потери данных вы должны быть уверены, что вы создали резервные копии всех важных документов, изображений, программ установки программного обеспечения и других персональных данных перед началом процесса. Если вы сейчас е создаете резервные копии данных, вам стоит немедленно заняться этим (скачать рекомендованное решение для резервного копирования), чтобы защитить себя от безвозвратной потери данных. Пожалуйста, учтите: Если проблема 9.0c не устранена после чистой установки Windows, это означает, что проблема Ошибки во время выполнения ОБЯЗАТЕЛЬНО связана с аппаратным обеспечением. В таком случае, вам, вероятно, придется заменить соответствующее оборудование, вызывающее ошибку 9.0c. |
www.solvusoft.com
Direct3D 10 - это... Что такое Direct3D 10?
Direct3D 10 — набор API функций для взаимодействия с видеокартой; поддерживается аппаратно видеокартами класса NV GeForce 8x00, ATI Radeon 2x00 и выше.
Direct3D 10 (D3D10) — компонент интерфейса программирования приложений (англ. API) DirectX 10, 10-я версия Direct3D, преемник Direct3D 9. Direct3D 10 обеспечивает функции для взаимодействия операционной системы и приложений с драйверами видеокарты. Эти функции привязаны к операционной системе в линейке Windows и доступны в Windows Vista и Windows 7 . Частично D3D10 работает на видеокартах уровня Direct3D 9.Официальная финальная версия вышла 10 ноября 2006 года в составе Windows Vista.
Далее приведены ключевые особенности и отличия от Direct3D версии 9.
Возможности и особенности
Новая модель драйвера
В Windows Vista совершенно новая модель драйвера — WDDM (Windows Display Driver Model, ранее называемая LDDM — Longhorn Display Driver Model) — серьезное изменение в модели видеодрайвера со времен появления аппаратного ускорения. В XDDM (Windows XP Display Driver Model) каждый вызов DirectX добавлял указатель команды (токен) в буфер команд в независимом от видеокарты формате. Когда DX Runtime решал, что буфер достаточно заполнен, вызывалась функция драйвера (в режиме ядра), которая получала этот буфер. После этого драйвер разбирал этот буфер и передавал данные видеокарте. То есть никаких функций драйвера в пользовательском режиме не было. Развитие видеокарт и, как следствие, усложнение буфера команд привело к тому, что драйвер стал немыслимо большим и в случае любой ошибки провоцировал BSOD. Также в XDDM у операционной системы нет способов установления приоритета, управления видеопамятью, планирования вызовов DX, что затрудняет разделение видеокарты между несколькими процессами — причина «потери устройства».
В новой модели драйвера сделано разделение между пользовательской и работающей в режиме ядра частью драйвера. Все вызовы DX напрямую идут в пользовательский драйвер, который готовит сразу буфер с содержимым, зависящим от оборудования. Этот буфер передаёт данные в ядро операционной системы, откуда они идут на видеокарту. Таким образом вся тяжёлая работа выполняется в пользовательской части, а в ядре - пересылка собранного буфера в DMA-трансфер видеокарты. Как итог, если пользовательский драйвер упадет, ничего страшного не случится — закроется конкретное приложение (но не BSOD). И у драйвера больше контроля (когда и сколько вызовов функций ядра делать). Также DX Runtime становится совсем тонкий — нет буферов команд, напрямую вызываются функции драйвера. Кроме этого между пользовательскими и ядерными частями есть планировщик заданий, который выбирает какие собранные буфера отправлять видеокарте (разделение GPU на много процессов).
Виртуализация видеопамяти
Теперь если не хватает видеопамяти, то ресурсы переносятся в системную (откуда могут быть отсвоплены). За счёт наличия у Windows Vista контроля выделения видеопамяти (ранее, у драйвера) можно распределять её более эффективно, чем POOL_MANAGED в XDDM. На данном этапе это работает на программном уровне — планировщик GPU перед передачей DMA-пакета карте загружает все нужные текстуры в видеопамять (умеет подгружать их заранее, пока GPU занят другим и свободна шина). Если приложение полноэкранное, все лишнее из видеопамяти будет перенесено в системную память по мере необходимости; если в оконном режиме, то происходит разделение памяти между текущими процессами. Если требуется гарантировать 100 % наличие ресурса в видеопамяти, то необходимо использовать полноэкранный режим и контроль над размером выделений.
Отсутствие ситуации «потери устройства» (Device Lost)
В предыдущих версиях по различным причинам мог происходить Device Lost, после чего требовалось загружать все ресурсы в видеопамять заново и производить восстановление объектов. С новой моделью драйвера этой проблемы больше не существует. Возможен только Device Removed, который означает что-то вроде «выдернули видеокарту»/«поставили новую версию драйвера» и встречается очень редко.
Убраны списки возможностей (D3D caps)
В DX10 больше нет капсов, как таковых. Гарантируется наличие всей функциональности, то есть если карта поддерживает DX10, то она обязана поддерживать последнюю версию шейдеров в полном объёме, поддерживать все форматы текстур, все возможные режимы фильтрации, шаблона (stencil) и всего остального. Более того, для DX10 написали спецификацию правил растеризации, то есть теперь картинка на разных видеокартах на одинаковом коде всегда должна быть одинаковой и совпадать с эталонным программным растеризатором. Если это не так, то это баг производителя видеокарты. В дальнейшем функциональность будет расширяться (пакет DX10.1, DX11 и т.д.).
Уменьшено время вызова функций DirectX
Уменьшено время вызова функций (в том числе DIP) на CPU. По данным презентаций Microsoft можно наблюдать 10x уменьшение времени. Это существенно, так как тяжёлая игра может проводить около 10+ миллисекунд в вызовах DX. Большую часть времени вызова ранее уходило на Runtime и Driver. теперь driver model фактически ничего не делает, а сразу предоставляет исполнение драйверу.
State Objects и Constant Buffers
Появились State Objects — объекты, которые можно предварительно собрать при создании и потом быстро устанавливать на видеокарте. Добавлены Constant Buffers, позволяющие более эффективно выставлять константы шейдеров.
Использование объектов-состояний
Все Set*State заменены на объекты-состояния (State Objects). Состояния разделены по нескольким группам:
- Rasterizer State — fill mode, cull mode, depth bias, multisample, scissor и т. д.
- Blend State — alpha blend, color write mask, blend op и т. д.
- Depth State — depth func, stencil func и т. д.
- SamplerState — tex filtering, clamping и т. д.
Состояния для каждой группы ставятся целиком, а не каждый по отдельности, как в D3D9. Для каждой группы можно создать State Object, которому при создании указывается полный набор состояний группы, и «установить» можно только его. Создание State Object — дорогая и медленная операция и должна вызываться редко. Мотивация этого нововведения — такой API позволяет драйверу сгенерировать набор команд видеокарте заранее (при создании State Object) и не генерировать его каждый раз во время рендера при вызовах Set*State.
Буфера и биндинг
Для основных типов данных (вершин, индексов, констант) введён единый буфер — ID3D10Buffer — набор байтов в памяти. Type safe обеспечивается за счёт указания при создании содержимого буфера. Для ресурсов введены отдельные объекты для биндинга к конвейеру — resource views. То есть сначала создаем текстуру как объект в памяти, а потом её resource view как инпут для шейдера или как render target, и уже с этим view вызываем PSSetShaderResources (вместо SetTexture) и OMSetRenderTargets (вместо SetRenderTarget). Стоит отметить, что у одного ресурса может быть несколько resource views.
Такой принцип позволяет работать обобщенно. Существуют «бестипные» (typeless) ресурсы, то есть ресурсы, которые не имеют определённого типа (не указан при создании) — например, DXGI_FORMAT_R32G32B32_TYPELESS. Тип таких ресурсов выбирается во время создания view (например, DXGI_FORMAT_R32G32B32_UINT или DXGI_FORMAT_R32G32B32_FLOAT) и выбора элемента/слайса из массива текстур/объёмной текстуры.
Использование буферов констант
Set*ShaderConstant заменены на Constant Buffers — группы констант (буфер на n констант), устанавливающихся за раз. Группу можно локать и записывать как обычный буфер. Биндинг к шейдеру производится начиная с некоторого слота.
Таким образом использование констант сводится к разделению их на несколько групп по частоте обновления (per-object, per-material, per-pass, per-scene) и созданию для каждой группы Constant Buffer. Помимо дополнительной производительности такой подход даёт драйверу высокоуровневую картину — больше возможностей для оптимизации.
Параметры шейдеров
VertexDeclaration заменён на Input Layout. Он требует при создании Shader Input Signature, то есть список input-параметров шейдера. Созданный объект можно использовать как Vertex Declaration с любым шейдером, имеющим такой же список input-параметров. В D3D9 Vertex Declaration устанавливался независимо от шейдера при рендере и поэтому драйверам приходилось серьёзно модифицировать сетап при смене vdecl. Сейчас vdecl жёстко привязан ко входу шейдера, что позволяет драйверу предвычислять все заранее.
Убраны asm-шейдеры
Шейдеры больше нельзя писать на ассемблере — нужно пользоваться HLSL. Хотя ассемблер для shader model 4.x есть и можно смотреть результат компиляции шейдеров в него, но больше нет возможности получить бинарный код шейдера из текста ассемблера (то что делали psa.exe/vsa.exe). Отреверсинженирить бинарный код, впрочем, никто не мешает.
Компилятор HLSL 4.0
Чтобы было легче портировать код шейдеров, компилятор умеет компилировать HLSL-шейдеры старых версий (SM2.0, SM 3.0) в SM4.0. В новом HLSL добавили атрибуты для хинтов компилятору — размотку циклов и выбор dynamic vs static branching для условных переходов.
Эволюционные изменения в шейдерах
В Shader Model 4 добавлены целочисленные инструкции и битовые операции (можно считать в честном fixed point и передавать булевые флажки), убрано ограничение на количество инструкций (но очень длинный шейдер может упереться в ограничение по времени выполнения пакета на GPU, до 10 сек)
Геометрические шейдеры (Geometry Shader)
Геометрический шейдер — дополнительный шейдер между вершинным (Vertex Shader) и пиксельным (Pixel Shader), который может генерировать примитивы. На вход ему подается примитив с информацией о соседях, на выход — можно сгенерировать несколько (не фиксированное число). Основная идея — наконец генерировать геометрию на GPU. Geometry Shaders очень плохо подходят для тесселяции и нужны для всяческой локальной генерации геометрии по мелочи. Например, можно патикл строить по одному вертексу или использовать стрипы геометрии в post-processing (например, в motion blur — из карты скоростей генерировать геометрические линии, по которым блурится картинка (так делает Lost Planet)). Совсем из другой области — например, делать рендер в Cubemap за один проход, GS выясняет в какие стороны cubemap попадает треугольник, и разбивает его на несколько. Основное препятствие использования GS — их скорость на современном железе. Тормозят. Основная причина — «анти-параллельность» GS, то есть так как шейдер может выдавать variable input и GPU обязана сохранять последовательность вывода треугольников, нужно вводить промежуточную стадию, пишушую в память, а потом делать финальный Gather, убивающий дырки.
Stream Out
Это возможность записывать результат работы Vertex Shader/Geometry Shader в память. Например, кешировать обработку геометрии или вообще геометрию, созданную GS. Можно считать итеративные эффекты, типа Cloth/Water. То есть теперь можно напрямую трансформить и записывать геометрию на GPU, не только рисовать пиксели в Render Target. Также есть возможность читать в шейдере из буфера в памяти по индексу, то есть иметь достаточно большую read-only shared memory. NV например предлагает там константы анимации хранить для инстансинга.
Уменьшение количества draw calls и переключений состояний
Появились массивы текстур, то есть контейнер одинаковых по размеру и формату текстур, из которого шейдер может выбирать по индексу (в DX10.1 — можно и cubemap arrays). Это тот самый atlasing done right — раньше когда в одной текстуре хранили несколько разных, приходилось беспокоиться за мип-левелы, оставлять зазор между текстурами и т. д. Теперь не надо. В шейдер приходят primitive/instance id, в зависимости от instance ID можно использовать другой набор текстур/координат/whatever. Ожидается, что dynamic branch в шейдере быстрый (лучше, чем в DX9-hardware), поэтому можно передавать Material ID и бранчиться по материалам в шейдере. То есть, в теории, можно за один вызов генерировать большое количество геометрии с разными параметрами, текстурами и вообще материалами. На практике, больше всего мешает таки стоимость dynamic branch и проблем, с ним связанных (вычисление градиентов текстурных координат). А остальное — вполне можно и нужно использовать.
Multi-sampling antialiasing features
Небольшая фича, ради одной которой можно переходить на DX10. Теперь в шейдере можно читать каждый MSAA-семпл отдельно, то есть писать свой собственный AA-фильтр, вменяемо семплить при процессинге и вообще использовать MSAA RT как текстуру. Ещё и AlphaToCoverage вместе с этим теперь официально присутствует. В D3D10.1 это можно делать и с depth textures.
Поддержка depth textures
Теперь depth buffer можно использовать как текстуру. Можно сказать, чтобы при семплинге сравнивал со значением и делал фильтрацию соседей, можно достать чистый depth value. Можно даже stencil value достать.
Другие интересные возможности
- есть рендер в volume texture
- в DX10.1 можно скопировать из обычной текстуры в сжатую на GPU
- есть настоящий conditional render, то есть возможность выкидывать целый draw call по результатам работы GPU асинхронно (можно делать occlusion culling полноценно)
Дополнительные факты
Операционная система Windows XP не поддерживает DX10. Причина в том, что перенос новой драйверной модели невозможен — требуется слишком много изменений в ядре операционной системы. Если же переносить только набор новых функциональных возможностей DX10, то тоже возникают проблемы: виртуализацию и шедулинг невозможно осуществить в старой модели драйвера, перенос аппаратных возможностей — слишком большой объём работы для Microsoft и IHV.
Ссылки
См. также
3dic.academic.ru
Direct3D 11 - это... Что такое Direct3D 11?
Direct3D 11 (D3D11) — компонент интерфейса программирования приложений (англ. API) DirectX 11, 11-я версия Direct3D, преемник Direct3D 10/10.1. Direct3D 11 обеспечивает функции для взаимодействия операционной системы и приложений с драйверами видеокарты. Эти функции не привязаны к следующей операционной системе в линейке Windows (Windows 7) и доступны в Windows Vista. Частично D3D11 работает на видеокартах уровня Direct3D 9-10.
Первые предварительные версии появились в ноябре 2008 года.
Официальная финальная версия вышла 22 октября 2009 года в составе Windows 7. 28 октября 2009 года DirectX 11 стал официально доступен для Windows Vista и Windows Server 2008 посредством скачивания через Windows Update.[1]Тесселяция
В D3D11 добавляется 3 дополнительных стадии конвейера визуализации, целью введения которых является эффективная тесселяция поверхностей. Более подробно стадии разбираются в книге Real-Time Rendering, 3rd Edition в главе Graphics Processing Unit.
Конвейер D3D11 включает три новых стадии между стадиями вершинного и геометрического шейдера. Две из них являются программируемыми (стадии оболочечного (hull shader) и domain шейдеров) и одна — конфигурируемая (стадия тесселяции):
Представленный конвейер оперирует сетками, заданными поверхностными патчами. Основными примитивами D3D11 являются треугольные и квадратные патчи. Форма каждого патча определяется числом контрольных точек. В вершинном шейдере эти точки трансформируются, скинятся и (или) морфятся последовательно.
Оболочечный шейдер вызывается для каждого патча. В качестве входных данных используются контрольные точки патча из вершинного шейдера. Оболочечный шейдер имеет два основных применения. Первое (опционально) — это конвертирование контрольных точек из одного представления в другое. Например, он позволяет реализовать метод, представленный в статье Approximating Catmull-Clark Subdivision Surfaces with Bicubic Patches. После этого шейдера контрольные точки пересылаются напрямую дальше, минуя тесселятор. Другое применение — вычисление подходящего параметра тесселяции, который затем передаётся на стадию тесселяции. Такой подход позволяет делать адаптивную тесселяцию, которая может быть использована в случае видозависимых уровней детализации (LOD). Параметр тесселяции определяется для каждой грани патча и варьируются в диапазоне от 2 до 64. Это означает, что каждая грань треугольного (или квадратного) патча может быть разбита на 2 (или максимум 64) грани.
Стадия тесселятора представлена фиксированным набором функции (хорошо конфигурируема), которые используют параметр тесселяции для подразбиения патча на несколько треугольников или квадов. Тесселятор не имеет доступа к контрольным точкам — все решения о разбиении принимаются на основе конфигурационных и тесселяционных параметров, передаваемых из оболочечного шейдера. Каждая вершина после стадии тесселяции передаётся в domain шейдер, причём передаются только координаты параметризации (parametrization coordinates).
Domain shader оперирует parametrization coordinates патча для каждой вершины раздельно, хотя имеется возможность получить доступ к трансформированным контрольным точкам для всего патча. Domain шейдер отправляет всю информацию о вершине (позицию, текстурные координаты, и т. п.) в геометрический шейдер (или на стадию клипирования, если геометрический шейдер не задан). По сути дела, он оценивает представление поверхности в каждой точке. На данной стадии может быть применён метод карт смещения (displacement mapping).
Полезные ссылки:
Вычислительные шейдеры и неупорядоченная память
Direct3D 11 вводит новый тип шейдера — вычислительный шейдер (Compute Shader). Вычислительный шейдер вызывается как регулярный массив потоков. Потоки делятся на группы. Каждая группа имеет 32 Кб памяти, разделяемой между потоками группы. Таким образом потоки в группе могут обмениваться результатами, улучшая свою производительность. Также потоки могут производить чтения и записи с произвольным доступом к графическим ресурсам: текстурам, массивам вершин, рендер таргетам. Эти доступы к памяти неупорядочены, хотя синхронизация различных инструкций осуществляется, когда это действительно необходимо.
Пиксельные (фрагментные) шейдеры могут также читать по произвольному адресу, что позволяет записывать структуры данных, которые могут быть затем использованы в вычислительном шейдере, или наоборот. Стоит отметить, что пиксельные шейдеры всегда имели возможность произвольного доступа на чтение через текстурные лукапы.
Вычислительные шейдеры могут также производить операции такие, как summed-area tables, быстрое Фурье-преобразование значительно быстрее, чем ранее применяемые методы на графическом процессоре. На данный момент Microsoft исследует библиотеки, обеспечивающие подобные расчёты. Microsoft считает, что алгоритмы, такие как A-буфер визуализация и трассировка лучей могут также быть осуществлены эффективно, но на данный момент нет реальных показателей, свидетельствующих об их эффективности.
Вызов вычислительного шейдера заменяет все стадии конвейера визуализации. Тем не менее, можно смешивать вычислительные шейдеры и традиционный рендер путём использования их результатов. Например, обработка изображения после визуализации вычислительным шейдером (можно загружать дополнительные структуры данных).
Полезные ссылки:
Многопоточная визуализация
D3D10 позволяет передавать команды визуализации только из одного потока (на данный момент существует специальный многопоточный режим, но из-за низкой производительности Майкрософт не рекомендует использовать его). Как известно, передача команд визуализации через Direct3D предполагает использование дополнительных вычислительных ресурсов CPU. Учитывая тенденцию увеличения числа ядер центрального процессора, вводится поддержка более продвинутой многопоточности, чтобы распределять эту работу между несколькими потоками, тем самым производя её более эффективно.
Direct3D 11 даёт возможность создавать дисплейные списки из нескольких потоков и выполнять их из главного потока визуализации. Кроме того, устройство, которое создаёт ресурсы, было вынесено из контекста, который передаёт команды визуализации. Это позволяет создавать ресурсы асинхронно. Отложенные контексты (Deferred Contexts) используются для создания дисплейных списков и прямой контекст (Immediate Context) для передачи команд визуализации на GPU, включая обработку дисплейных списков, созданных в отложенных контекстах.
В отличие от других возможностей, в Direct3D 11 многопоточная визуализация реализуется программно через драйвер. Соответствующие драйверы D3D10 (возможно, даже D3D9) позволяют выполнять многопоточную визуализацию гораздо эффективней, чем ранее. Определённый уровень многопоточности будет доступен даже без новых драйверов, однако пока неясно, какие ограничения будут в этом случае.
Другие возможности
Поддержка динамической линковки шейдеров (по аналогии Cg). Это позволяет разделить написание и компиляцию шейдеров света и материалов. Позднее связывание производится при выставлении шейдера. Этот подход является решением проблемы комбинаторного взрыва в случае различных источников света и материалов (он и некоторые другие проблемы обсуждаются в секции 7.9 книги Real-Time Rendering, 3rd Edition)
Добавлены два новых формата сжатых текстур. BC6 поддерживает широкий динамический диапазон RGB текстуры, используя при этом 1 байт на каждый тексель (взамен 6 байт в случае 16-битных RGB вещественных текстуры). BC7 поддерживает узкий динамический диапазон RGB или RGBA текстур. Он также использует 1 байт на тексель (как DXT5/BC3), но предоставляет значительно лучшее качество по сравнению с форматами текстур D3D10. Оба новых формата используют несколько типов блоков — утилита для сжатия выбирает соответствующий тип блока на основе его содержания.
Форматы блоков сжатия D3D9 и D3D10 основаны на идее, что каждый блок 4 × 4 из текселей содержит все свои значения в виде одной линии, и биты каждого текселя кодируют позицию в этой линии. Например, в DXT1/BC1 строка в пространстве RGB представляет две конечные точки RGB, и каждый тексель использует два бита, чтобы указать какой цвет используется из четырёх точек вдоль линии.
Новые форматы D3D11 поддерживают типы блоков с одной, двумя и даже тремя (в случае BC7) цветовыми линиями. Существует компромисс между числом линий и числом точек вдоль такой линии, поскольку каждый блок занимает одинаковый объём памяти. В принципе, блок 4 × 4 с двумя цветовыми линиями требует дополнительно 16 бит на каждый блок для задания какая линия каждого текселя была связана с ним (в случае трёх цветовых линий потребуется ещё больше бит). Для снижения требований по памяти поддерживаются только небольшой набор возможных моделей цветовых линий. Для каждого блока утилита упаковки выбирает лучший вариант из этого подмножества.
Direct3D 11 имеет более жёсткую спецификацию текстур. Результаты декомпрессии должны быть точными и субтексельная/субмип фильтрация должна обеспечивать точность не менее 8 бит.
Direct3D 11 позволяет использовать текстуры, имеющие максимальный размер в диапазоне от 8K-16K текселей. Отметим, что 16K х 16K DXT1/BC1 текстура занимает 128MB — не так много игр будет использовать такие большие текстуры, но это может быть подходяще для методик наподобие мегатекстуры. В общем, теперь в D3D11 ресурс может иметь размер до 2 Гб.
Аппаратное обеспечение может дополнительно поддерживать (опционально) вещественные числа с плавающей точкой двойной точности.
На Gamefest 2008 также был представлен слайд с множеством других новшеств, детали которых не были пояснены:
- Адресуемый потоковый вывод (Addressable Stream Out)
- Непрямая отрисовка (Draw Indirect)
- Улучшенный Gather4 (Improved Gather4)
- Instance programming model для геометрических шейдеров (Geometry shader instance programming model)
- Min-LOD texture clamps
- Conservative oDepth
- Pull-model attribute eval
- Read-only depth or stencil views
SlimDX и SharpDX поддерживают DirectX 11. XNA - нет
Игры с поддержкой DirectX 11
Кроме того, поддержка DirectX 11 внедрена в следующие игровые движки:
См. также
Примечания
Ссылки
dikc.academic.ru
Direct3D 10 - это... Что такое Direct3D 10?
Direct3D 10 — набор API функций для взаимодействия с видеокартой; поддерживается аппаратно видеокартами класса NV GeForce 8x00, ATI Radeon 2x00 и выше.
Direct3D 10 (D3D10) — компонент интерфейса программирования приложений (англ. API) DirectX 10, 10-я версия Direct3D, преемник Direct3D 9. Direct3D 10 обеспечивает функции для взаимодействия операционной системы и приложений с драйверами видеокарты. Эти функции привязаны к операционной системе в линейке Windows и доступны в Windows Vista и Windows 7 . Частично D3D10 работает на видеокартах уровня Direct3D 9.Официальная финальная версия вышла 10 ноября 2006 года в составе Windows Vista.
Далее приведены ключевые особенности и отличия от Direct3D версии 9.
Возможности и особенности
Новая модель драйвера
В Windows Vista совершенно новая модель драйвера — WDDM (Windows Display Driver Model, ранее называемая LDDM — Longhorn Display Driver Model) — серьезное изменение в модели видеодрайвера со времен появления аппаратного ускорения. В XDDM (Windows XP Display Driver Model) каждый вызов DirectX добавлял указатель команды (токен) в буфер команд в независимом от видеокарты формате. Когда DX Runtime решал, что буфер достаточно заполнен, вызывалась функция драйвера (в режиме ядра), которая получала этот буфер. После этого драйвер разбирал этот буфер и передавал данные видеокарте. То есть никаких функций драйвера в пользовательском режиме не было. Развитие видеокарт и, как следствие, усложнение буфера команд привело к тому, что драйвер стал немыслимо большим и в случае любой ошибки провоцировал BSOD. Также в XDDM у операционной системы нет способов установления приоритета, управления видеопамятью, планирования вызовов DX, что затрудняет разделение видеокарты между несколькими процессами — причина «потери устройства».
В новой модели драйвера сделано разделение между пользовательской и работающей в режиме ядра частью драйвера. Все вызовы DX напрямую идут в пользовательский драйвер, который готовит сразу буфер с содержимым, зависящим от оборудования. Этот буфер передаёт данные в ядро операционной системы, откуда они идут на видеокарту. Таким образом вся тяжёлая работа выполняется в пользовательской части, а в ядре - пересылка собранного буфера в DMA-трансфер видеокарты. Как итог, если пользовательский драйвер упадет, ничего страшного не случится — закроется конкретное приложение (но не BSOD). И у драйвера больше контроля (когда и сколько вызовов функций ядра делать). Также DX Runtime становится совсем тонкий — нет буферов команд, напрямую вызываются функции драйвера. Кроме этого между пользовательскими и ядерными частями есть планировщик заданий, который выбирает какие собранные буфера отправлять видеокарте (разделение GPU на много процессов).
Виртуализация видеопамяти
Теперь если не хватает видеопамяти, то ресурсы переносятся в системную (откуда могут быть отсвоплены). За счёт наличия у Windows Vista контроля выделения видеопамяти (ранее, у драйвера) можно распределять её более эффективно, чем POOL_MANAGED в XDDM. На данном этапе это работает на программном уровне — планировщик GPU перед передачей DMA-пакета карте загружает все нужные текстуры в видеопамять (умеет подгружать их заранее, пока GPU занят другим и свободна шина). Если приложение полноэкранное, все лишнее из видеопамяти будет перенесено в системную память по мере необходимости; если в оконном режиме, то происходит разделение памяти между текущими процессами. Если требуется гарантировать 100 % наличие ресурса в видеопамяти, то необходимо использовать полноэкранный режим и контроль над размером выделений.
Отсутствие ситуации «потери устройства» (Device Lost)
В предыдущих версиях по различным причинам мог происходить Device Lost, после чего требовалось загружать все ресурсы в видеопамять заново и производить восстановление объектов. С новой моделью драйвера этой проблемы больше не существует. Возможен только Device Removed, который означает что-то вроде «выдернули видеокарту»/«поставили новую версию драйвера» и встречается очень редко.
Убраны списки возможностей (D3D caps)
В DX10 больше нет капсов, как таковых. Гарантируется наличие всей функциональности, то есть если карта поддерживает DX10, то она обязана поддерживать последнюю версию шейдеров в полном объёме, поддерживать все форматы текстур, все возможные режимы фильтрации, шаблона (stencil) и всего остального. Более того, для DX10 написали спецификацию правил растеризации, то есть теперь картинка на разных видеокартах на одинаковом коде всегда должна быть одинаковой и совпадать с эталонным программным растеризатором. Если это не так, то это баг производителя видеокарты. В дальнейшем функциональность будет расширяться (пакет DX10.1, DX11 и т.д.).
Уменьшено время вызова функций DirectX
Уменьшено время вызова функций (в том числе DIP) на CPU. По данным презентаций Microsoft можно наблюдать 10x уменьшение времени. Это существенно, так как тяжёлая игра может проводить около 10+ миллисекунд в вызовах DX. Большую часть времени вызова ранее уходило на Runtime и Driver. теперь driver model фактически ничего не делает, а сразу предоставляет исполнение драйверу.
State Objects и Constant Buffers
Появились State Objects — объекты, которые можно предварительно собрать при создании и потом быстро устанавливать на видеокарте. Добавлены Constant Buffers, позволяющие более эффективно выставлять константы шейдеров.
Использование объектов-состояний
Все Set*State заменены на объекты-состояния (State Objects). Состояния разделены по нескольким группам:
- Rasterizer State — fill mode, cull mode, depth bias, multisample, scissor и т. д.
- Blend State — alpha blend, color write mask, blend op и т. д.
- Depth State — depth func, stencil func и т. д.
- SamplerState — tex filtering, clamping и т. д.
Состояния для каждой группы ставятся целиком, а не каждый по отдельности, как в D3D9. Для каждой группы можно создать State Object, которому при создании указывается полный набор состояний группы, и «установить» можно только его. Создание State Object — дорогая и медленная операция и должна вызываться редко. Мотивация этого нововведения — такой API позволяет драйверу сгенерировать набор команд видеокарте заранее (при создании State Object) и не генерировать его каждый раз во время рендера при вызовах Set*State.
Буфера и биндинг
Для основных типов данных (вершин, индексов, констант) введён единый буфер — ID3D10Buffer — набор байтов в памяти. Type safe обеспечивается за счёт указания при создании содержимого буфера. Для ресурсов введены отдельные объекты для биндинга к конвейеру — resource views. То есть сначала создаем текстуру как объект в памяти, а потом её resource view как инпут для шейдера или как render target, и уже с этим view вызываем PSSetShaderResources (вместо SetTexture) и OMSetRenderTargets (вместо SetRenderTarget). Стоит отметить, что у одного ресурса может быть несколько resource views.
Такой принцип позволяет работать обобщенно. Существуют «бестипные» (typeless) ресурсы, то есть ресурсы, которые не имеют определённого типа (не указан при создании) — например, DXGI_FORMAT_R32G32B32_TYPELESS. Тип таких ресурсов выбирается во время создания view (например, DXGI_FORMAT_R32G32B32_UINT или DXGI_FORMAT_R32G32B32_FLOAT) и выбора элемента/слайса из массива текстур/объёмной текстуры.
Использование буферов констант
Set*ShaderConstant заменены на Constant Buffers — группы констант (буфер на n констант), устанавливающихся за раз. Группу можно локать и записывать как обычный буфер. Биндинг к шейдеру производится начиная с некоторого слота.
Таким образом использование констант сводится к разделению их на несколько групп по частоте обновления (per-object, per-material, per-pass, per-scene) и созданию для каждой группы Constant Buffer. Помимо дополнительной производительности такой подход даёт драйверу высокоуровневую картину — больше возможностей для оптимизации.
Параметры шейдеров
VertexDeclaration заменён на Input Layout. Он требует при создании Shader Input Signature, то есть список input-параметров шейдера. Созданный объект можно использовать как Vertex Declaration с любым шейдером, имеющим такой же список input-параметров. В D3D9 Vertex Declaration устанавливался независимо от шейдера при рендере и поэтому драйверам приходилось серьёзно модифицировать сетап при смене vdecl. Сейчас vdecl жёстко привязан ко входу шейдера, что позволяет драйверу предвычислять все заранее.
Убраны asm-шейдеры
Шейдеры больше нельзя писать на ассемблере — нужно пользоваться HLSL. Хотя ассемблер для shader model 4.x есть и можно смотреть результат компиляции шейдеров в него, но больше нет возможности получить бинарный код шейдера из текста ассемблера (то что делали psa.exe/vsa.exe). Отреверсинженирить бинарный код, впрочем, никто не мешает.
Компилятор HLSL 4.0
Чтобы было легче портировать код шейдеров, компилятор умеет компилировать HLSL-шейдеры старых версий (SM2.0, SM 3.0) в SM4.0. В новом HLSL добавили атрибуты для хинтов компилятору — размотку циклов и выбор dynamic vs static branching для условных переходов.
Эволюционные изменения в шейдерах
В Shader Model 4 добавлены целочисленные инструкции и битовые операции (можно считать в честном fixed point и передавать булевые флажки), убрано ограничение на количество инструкций (но очень длинный шейдер может упереться в ограничение по времени выполнения пакета на GPU, до 10 сек)
Геометрические шейдеры (Geometry Shader)
Геометрический шейдер — дополнительный шейдер между вершинным (Vertex Shader) и пиксельным (Pixel Shader), который может генерировать примитивы. На вход ему подается примитив с информацией о соседях, на выход — можно сгенерировать несколько (не фиксированное число). Основная идея — наконец генерировать геометрию на GPU. Geometry Shaders очень плохо подходят для тесселяции и нужны для всяческой локальной генерации геометрии по мелочи. Например, можно патикл строить по одному вертексу или использовать стрипы геометрии в post-processing (например, в motion blur — из карты скоростей генерировать геометрические линии, по которым блурится картинка (так делает Lost Planet)). Совсем из другой области — например, делать рендер в Cubemap за один проход, GS выясняет в какие стороны cubemap попадает треугольник, и разбивает его на несколько. Основное препятствие использования GS — их скорость на современном железе. Тормозят. Основная причина — «анти-параллельность» GS, то есть так как шейдер может выдавать variable input и GPU обязана сохранять последовательность вывода треугольников, нужно вводить промежуточную стадию, пишушую в память, а потом делать финальный Gather, убивающий дырки.
Stream Out
Это возможность записывать результат работы Vertex Shader/Geometry Shader в память. Например, кешировать обработку геометрии или вообще геометрию, созданную GS. Можно считать итеративные эффекты, типа Cloth/Water. То есть теперь можно напрямую трансформить и записывать геометрию на GPU, не только рисовать пиксели в Render Target. Также есть возможность читать в шейдере из буфера в памяти по индексу, то есть иметь достаточно большую read-only shared memory. NV например предлагает там константы анимации хранить для инстансинга.
Уменьшение количества draw calls и переключений состояний
Появились массивы текстур, то есть контейнер одинаковых по размеру и формату текстур, из которого шейдер может выбирать по индексу (в DX10.1 — можно и cubemap arrays). Это тот самый atlasing done right — раньше когда в одной текстуре хранили несколько разных, приходилось беспокоиться за мип-левелы, оставлять зазор между текстурами и т. д. Теперь не надо. В шейдер приходят primitive/instance id, в зависимости от instance ID можно использовать другой набор текстур/координат/whatever. Ожидается, что dynamic branch в шейдере быстрый (лучше, чем в DX9-hardware), поэтому можно передавать Material ID и бранчиться по материалам в шейдере. То есть, в теории, можно за один вызов генерировать большое количество геометрии с разными параметрами, текстурами и вообще материалами. На практике, больше всего мешает таки стоимость dynamic branch и проблем, с ним связанных (вычисление градиентов текстурных координат). А остальное — вполне можно и нужно использовать.
Multi-sampling antialiasing features
Небольшая фича, ради одной которой можно переходить на DX10. Теперь в шейдере можно читать каждый MSAA-семпл отдельно, то есть писать свой собственный AA-фильтр, вменяемо семплить при процессинге и вообще использовать MSAA RT как текстуру. Ещё и AlphaToCoverage вместе с этим теперь официально присутствует. В D3D10.1 это можно делать и с depth textures.
Поддержка depth textures
Теперь depth buffer можно использовать как текстуру. Можно сказать, чтобы при семплинге сравнивал со значением и делал фильтрацию соседей, можно достать чистый depth value. Можно даже stencil value достать.
Другие интересные возможности
- есть рендер в volume texture
- в DX10.1 можно скопировать из обычной текстуры в сжатую на GPU
- есть настоящий conditional render, то есть возможность выкидывать целый draw call по результатам работы GPU асинхронно (можно делать occlusion culling полноценно)
Дополнительные факты
Операционная система Windows XP не поддерживает DX10. Причина в том, что перенос новой драйверной модели невозможен — требуется слишком много изменений в ядре операционной системы. Если же переносить только набор новых функциональных возможностей DX10, то тоже возникают проблемы: виртуализацию и шедулинг невозможно осуществить в старой модели драйвера, перенос аппаратных возможностей — слишком большой объём работы для Microsoft и IHV.
Ссылки
См. также
dic.academic.ru
Direct3D 11 - это... Что такое Direct3D 11?
Direct3D 11 (D3D11) — компонент интерфейса программирования приложений (англ. API) DirectX 11, 11-я версия Direct3D, преемник Direct3D 10/10.1. Direct3D 11 обеспечивает функции для взаимодействия операционной системы и приложений с драйверами видеокарты. Эти функции не привязаны к следующей операционной системе в линейке Windows (Windows 7) и доступны в Windows Vista. Частично D3D11 работает на видеокартах уровня Direct3D 9-10.
Первые предварительные версии появились в ноябре 2008 года.
Официальная финальная версия вышла 22 октября 2009 года в составе Windows 7. 28 октября 2009 года DirectX 11 стал официально доступен для Windows Vista и Windows Server 2008 посредством скачивания через Windows Update.[1]Тесселяция
В D3D11 добавляется 3 дополнительных стадии конвейера визуализации, целью введения которых является эффективная тесселяция поверхностей. Более подробно стадии разбираются в книге Real-Time Rendering, 3rd Edition в главе Graphics Processing Unit.
Конвейер D3D11 включает три новых стадии между стадиями вершинного и геометрического шейдера. Две из них являются программируемыми (стадии оболочечного (hull shader) и domain шейдеров) и одна — конфигурируемая (стадия тесселяции):
Представленный конвейер оперирует сетками, заданными поверхностными патчами. Основными примитивами D3D11 являются треугольные и квадратные патчи. Форма каждого патча определяется числом контрольных точек. В вершинном шейдере эти точки трансформируются, скинятся и (или) морфятся последовательно.
Оболочечный шейдер вызывается для каждого патча. В качестве входных данных используются контрольные точки патча из вершинного шейдера. Оболочечный шейдер имеет два основных применения. Первое (опционально) — это конвертирование контрольных точек из одного представления в другое. Например, он позволяет реализовать метод, представленный в статье Approximating Catmull-Clark Subdivision Surfaces with Bicubic Patches. После этого шейдера контрольные точки пересылаются напрямую дальше, минуя тесселятор. Другое применение — вычисление подходящего параметра тесселяции, который затем передаётся на стадию тесселяции. Такой подход позволяет делать адаптивную тесселяцию, которая может быть использована в случае видозависимых уровней детализации (LOD). Параметр тесселяции определяется для каждой грани патча и варьируются в диапазоне от 2 до 64. Это означает, что каждая грань треугольного (или квадратного) патча может быть разбита на 2 (или максимум 64) грани.
Стадия тесселятора представлена фиксированным набором функции (хорошо конфигурируема), которые используют параметр тесселяции для подразбиения патча на несколько треугольников или квадов. Тесселятор не имеет доступа к контрольным точкам — все решения о разбиении принимаются на основе конфигурационных и тесселяционных параметров, передаваемых из оболочечного шейдера. Каждая вершина после стадии тесселяции передаётся в domain шейдер, причём передаются только координаты параметризации (parametrization coordinates).
Domain shader оперирует parametrization coordinates патча для каждой вершины раздельно, хотя имеется возможность получить доступ к трансформированным контрольным точкам для всего патча. Domain шейдер отправляет всю информацию о вершине (позицию, текстурные координаты, и т. п.) в геометрический шейдер (или на стадию клипирования, если геометрический шейдер не задан). По сути дела, он оценивает представление поверхности в каждой точке. На данной стадии может быть применён метод карт смещения (displacement mapping).
Полезные ссылки:
Вычислительные шейдеры и неупорядоченная память
Direct3D 11 вводит новый тип шейдера — вычислительный шейдер (Compute Shader). Вычислительный шейдер вызывается как регулярный массив потоков. Потоки делятся на группы. Каждая группа имеет 32 Кб памяти, разделяемой между потоками группы. Таким образом потоки в группе могут обмениваться результатами, улучшая свою производительность. Также потоки могут производить чтения и записи с произвольным доступом к графическим ресурсам: текстурам, массивам вершин, рендер таргетам. Эти доступы к памяти неупорядочены, хотя синхронизация различных инструкций осуществляется, когда это действительно необходимо.
Пиксельные (фрагментные) шейдеры могут также читать по произвольному адресу, что позволяет записывать структуры данных, которые могут быть затем использованы в вычислительном шейдере, или наоборот. Стоит отметить, что пиксельные шейдеры всегда имели возможность произвольного доступа на чтение через текстурные лукапы.
Вычислительные шейдеры могут также производить операции такие, как summed-area tables, быстрое Фурье-преобразование значительно быстрее, чем ранее применяемые методы на графическом процессоре. На данный момент Microsoft исследует библиотеки, обеспечивающие подобные расчёты. Microsoft считает, что алгоритмы, такие как A-буфер визуализация и трассировка лучей могут также быть осуществлены эффективно, но на данный момент нет реальных показателей, свидетельствующих об их эффективности.
Вызов вычислительного шейдера заменяет все стадии конвейера визуализации. Тем не менее, можно смешивать вычислительные шейдеры и традиционный рендер путём использования их результатов. Например, обработка изображения после визуализации вычислительным шейдером (можно загружать дополнительные структуры данных).
Полезные ссылки:
Многопоточная визуализация
D3D10 позволяет передавать команды визуализации только из одного потока (на данный момент существует специальный многопоточный режим, но из-за низкой производительности Майкрософт не рекомендует использовать его). Как известно, передача команд визуализации через Direct3D предполагает использование дополнительных вычислительных ресурсов CPU. Учитывая тенденцию увеличения числа ядер центрального процессора, вводится поддержка более продвинутой многопоточности, чтобы распределять эту работу между несколькими потоками, тем самым производя её более эффективно.
Direct3D 11 даёт возможность создавать дисплейные списки из нескольких потоков и выполнять их из главного потока визуализации. Кроме того, устройство, которое создаёт ресурсы, было вынесено из контекста, который передаёт команды визуализации. Это позволяет создавать ресурсы асинхронно. Отложенные контексты (Deferred Contexts) используются для создания дисплейных списков и прямой контекст (Immediate Context) для передачи команд визуализации на GPU, включая обработку дисплейных списков, созданных в отложенных контекстах.
В отличие от других возможностей, в Direct3D 11 многопоточная визуализация реализуется программно через драйвер. Соответствующие драйверы D3D10 (возможно, даже D3D9) позволяют выполнять многопоточную визуализацию гораздо эффективней, чем ранее. Определённый уровень многопоточности будет доступен даже без новых драйверов, однако пока неясно, какие ограничения будут в этом случае.
Другие возможности
Поддержка динамической линковки шейдеров (по аналогии Cg). Это позволяет разделить написание и компиляцию шейдеров света и материалов. Позднее связывание производится при выставлении шейдера. Этот подход является решением проблемы комбинаторного взрыва в случае различных источников света и материалов (он и некоторые другие проблемы обсуждаются в секции 7.9 книги Real-Time Rendering, 3rd Edition)
Добавлены два новых формата сжатых текстур. BC6 поддерживает широкий динамический диапазон RGB текстуры, используя при этом 1 байт на каждый тексель (взамен 6 байт в случае 16-битных RGB вещественных текстуры). BC7 поддерживает узкий динамический диапазон RGB или RGBA текстур. Он также использует 1 байт на тексель (как DXT5/BC3), но предоставляет значительно лучшее качество по сравнению с форматами текстур D3D10. Оба новых формата используют несколько типов блоков — утилита для сжатия выбирает соответствующий тип блока на основе его содержания.
Форматы блоков сжатия D3D9 и D3D10 основаны на идее, что каждый блок 4 × 4 из текселей содержит все свои значения в виде одной линии, и биты каждого текселя кодируют позицию в этой линии. Например, в DXT1/BC1 строка в пространстве RGB представляет две конечные точки RGB, и каждый тексель использует два бита, чтобы указать какой цвет используется из четырёх точек вдоль линии.
Новые форматы D3D11 поддерживают типы блоков с одной, двумя и даже тремя (в случае BC7) цветовыми линиями. Существует компромисс между числом линий и числом точек вдоль такой линии, поскольку каждый блок занимает одинаковый объём памяти. В принципе, блок 4 × 4 с двумя цветовыми линиями требует дополнительно 16 бит на каждый блок для задания какая линия каждого текселя была связана с ним (в случае трёх цветовых линий потребуется ещё больше бит). Для снижения требований по памяти поддерживаются только небольшой набор возможных моделей цветовых линий. Для каждого блока утилита упаковки выбирает лучший вариант из этого подмножества.
Direct3D 11 имеет более жёсткую спецификацию текстур. Результаты декомпрессии должны быть точными и субтексельная/субмип фильтрация должна обеспечивать точность не менее 8 бит.
Direct3D 11 позволяет использовать текстуры, имеющие максимальный размер в диапазоне от 8K-16K текселей. Отметим, что 16K х 16K DXT1/BC1 текстура занимает 128MB — не так много игр будет использовать такие большие текстуры, но это может быть подходяще для методик наподобие мегатекстуры. В общем, теперь в D3D11 ресурс может иметь размер до 2 Гб.
Аппаратное обеспечение может дополнительно поддерживать (опционально) вещественные числа с плавающей точкой двойной точности.
На Gamefest 2008 также был представлен слайд с множеством других новшеств, детали которых не были пояснены:
- Адресуемый потоковый вывод (Addressable Stream Out)
- Непрямая отрисовка (Draw Indirect)
- Улучшенный Gather4 (Improved Gather4)
- Instance programming model для геометрических шейдеров (Geometry shader instance programming model)
- Min-LOD texture clamps
- Conservative oDepth
- Pull-model attribute eval
- Read-only depth or stencil views
SlimDX и SharpDX поддерживают DirectX 11. XNA - нет
Игры с поддержкой DirectX 11
Кроме того, поддержка DirectX 11 внедрена в следующие игровые движки:
См. также
Примечания
Ссылки
dic.academic.ru
