Как изменить opengl на directx

Обновлено: 21.11.2024

Поделиться этим сообщением:

Последние несколько месяцев мы работали над двумя новыми интересными проектами в Collabora, и наконец пришло время поделиться информацией о них со всем миром:

Мы сотрудничаем с инженерами Microsoft DirectX для создания слоев отображения OpenCL и OpenGL, чтобы обеспечить поддержку OpenCL 1.2 и OpenGL 3.3 для всех устройств с Windows и DirectX 12!

Эта работа основана на большом количестве предыдущих работ. Прежде всего, мы строим это, используя Mesa 3D, с интерфейсом Gallium в качестве основы для слоя OpenGL и NIR в качестве основы для компилятора OpenCL. Мы также используем LLVM и SPIRV-LLVM-Translator от Khronos в качестве внешнего интерфейса компилятора.

Кроме того, мы используем опыт Microsoft в создании уровня трансляции D3D12, а также собственный опыт разработки Zink.

Что такое Mesa 3D?

Mesa 3D — это реализация нескольких графических технологий с открытым исходным кодом, включая OpenCL и OpenGL. Реализация OpenGL в Mesa надежна и используется в качестве основы для нескольких отраслевых драйверов OpenGL от нескольких поставщиков графических процессоров.

Помимо прочего, Mesa состоит из нескольких реализаций API (называемых средствами отслеживания состояния), а также интерфейса низкоуровневого драйвера Gallium. Интерфейс Gallium скрывает многие устаревшие детали OpenGL и преобразует вызовы OpenGL во что-то, что больше похоже на современные примитивы графического процессора.

Зачем переводить API?

Не все устройства под управлением Windows последовательно поддерживают OpenCL и OpenGL с аппаратным ускорением. Поэтому, чтобы улучшить совместимость приложений, мы создаем универсальное решение проблемы. Это означает, что поставщик графического процессора должен реализовать только драйвер D3D12 для своего оборудования, чтобы поддерживать все три API.

Ожидается, что этот уровень сопоставления также послужит отправной точкой при переносе старых приложений OpenCL и OpenGL на D3D12.

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

Реализация

Работа в основном разделена на три части: компилятор OpenCL, среда выполнения OpenCL и драйвер Gallium, который создает и выполняет буферы команд на графическом процессоре с помощью API D3D12.

Кроме того, оба компонента используют общий компилятор шейдеров NIR-to-DXIL. Для тех, кто не знаком с NIR, это внутреннее представление Mesa для шейдеров GPU. Точно так же DXIL — это внутреннее представление Microsoft, которое драйверы D3D12 будут использовать и преобразовывать в аппаратно-зависимые шейдеры.

Компилятор OpenCL

Компилятор OpenCL использует LLVM и SPIRV-LLVM-Translator для создания SPIR-V-представлений ядер OpenCL. Они, в свою очередь, передаются транслятору SPIR-V в NIR компании Mesa, где выполняются некоторые оптимизации и семантические преобразования. Затем представление NIR, наконец, передается в NIR-to-DXIL, который создает вычислительный шейдер DXIL и необходимые метаданные, чтобы его можно было выполнить на графическом процессоре во время выполнения с использованием D3D12.

Вот схема всего процесса, включая NIR-to-DXIL, который будет описан ниже:

Среда выполнения OpenCL

Хотя Mesa предоставляет реализацию OpenCL под названием Clover, мы не используем ее в этом проекте. Вместо этого у нас есть новая среда выполнения OpenCL, которая делает более прямой перевод в API DirectX 12.

NIR-в-DXIL

DXIL по существу представляет собой битовый код LLVM 3.7 с некоторыми дополнительными метаданными и проверкой. Это был технический выбор, который имел смысл для Microsoft, поскольку все основные поставщики драйверов уже использовали LLVM в наборе инструментов компилятора. Использование более старой версии формата битового кода LLVM обеспечивает хорошую совместимость с драйверами, поскольку формат битового кода LLVM обратно совместим.

Поскольку мы зависим от гораздо более поздней версии LLVM для внешнего интерфейса компилятора, мы, к сожалению, не можем легко использовать компилятор шейдеров DirectX в качестве внутреннего интерфейса компилятора. Компилятор шейдеров DirectX фактически является ответвлением LLVM 3.7, и в настоящее время мы используем LLVM 10.0 для внешнего интерфейса компилятора. Использование компилятора шейдеров DirectX потребовало бы от нас связать две разные версии LLVM в один и тот же двоичный файл, что привело бы к проблемам.

Мы также не можем легко использовать сам LLVM для генерации битового кода. Хотя формат битового кода LLVM совместим с предыдущими версиями, сам LLVM не является *совместимым вперед*. Это означает, что более новые версии LLVM не могут создавать формат битового кода, понятный более старым версиям. Это имеет смысл с точки зрения LLVM, поскольку никогда не задумывался как общий формат обмена.

Вместо этого мы решили реализовать собственный эмиттер DXIL. Это немного сложнее, чем кажется, потому что битовый код LLVM делает все возможное, чтобы сделать формат как можно более плотным. Например, LLVM хранит свой битовый код не как последовательность байтов и слов, а как битовые поля переменной ширины в длинной последовательности битов.

Есть много сложных деталей, которые нужно исправить, но в итоге у нас есть работающий компилятор.

Драйвер галлия D3D12

Драйвер D3D12 Gallium — это последняя часть головоломки. По сути, он берет команды OpenGL и с помощью транслятора NIR в DXIL превращает их в командные буферы D3D12, которые выполняются на графическом процессоре с помощью драйвера D3D12.

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

Но чтобы не оставить вас с пустыми руками, вот скриншот версии известного glxgears, wglgears для Windows:

Исходный код

В краткосрочной перспективе исходный код можно найти здесь. Мы намерены в ближайшее время перенести эту работу в основной репозиторий Mesa, поэтому он не является постоянным домом.

Дальнейшие шаги

Это всего лишь объявление, и предстоит еще много работы. У нас есть кое-что, что работает в некоторых случаях прямо сейчас, но мы только начинаем царапать поверхность.

Во-первых, нам нужно достичь целевого уровня функций. Наша цель на данный момент — пройти тесты на соответствие для OpenCL 1.2 и OpenGL 3.3. Нам предстоит пройти долгий путь, но, приложив немного усилий и пота, я уверен, что мы его добьемся.

Во-вторых, нам нужно поработать над совместимостью приложений. Сейчас мы сосредоточимся на приложениях для повышения производительности.

Мы также хотим воспроизвести это в Mesa. Таким образом, мы можем не отставать от исправлений и новых функций в Mesa, а другие водители также могут извлечь выгоду из того, что мы делаем.

Благодарности

Также важно отметить, что я не единственный, кто работает над этим. В нашу команду входят еще пять инженеров Collabora (Борис Брезиллон, Дэниел Стоун, Эли Турнье, Герт Воллни, Луи-Франсис Ратте-Булиан) и два инженера Microsoft DirectX (Билл Кристиансен, Джесси Натали).

Продолжить чтение: подробное изучение OpenGL вместо слоев DirectX

Похожие записи

Глубокое погружение в OpenGL и многоуровневость DirectX

Представляем Zink, реализацию OpenGL поверх Vulkan

Зинк: осеннее обновление

Похожие записи

Глубокое погружение в OpenGL и многоуровневость DirectX

Представляем Zink, реализацию OpenGL поверх Vulkan

Зинк: осеннее обновление

Комментарии (10)

>Не все устройства под управлением Windows последовательно поддерживают OpenCL и OpenGL с аппаратным ускорением.

И сколько устройств под управлением Windows поддерживают DirectX 12 и WDDM 2.9, которые необходимы для работы этого Франкенштейна OpenGL-on-DirectX-on-GPU-PV? Мой компьютер полностью поддерживает OpenGL 4.5 и Vulkan, но только WDDM 2.1.

Почему бы не дать людям возможность напрямую использовать OpenGL/OpenCL/Vulkan? Похоже, что со стороны Microsoft потребуется намного меньше инженерной работы.

Отказ от поддержки DirectX и переход всего мира на Vulkan/GL/CL потребует не меньше усилий со стороны Microsoft. Я не думаю, что разработчики, которые в настоящее время ориентируются на DirectX, будут этому очень рады, и им придется поддерживать его всегда.

Поставщики по-прежнему могут создавать собственные драйверы GL/CL, если захотят — как вы заметили, многие из них так и делают. Для OpenGL ES это даже несколько приемлемо.Но для полного OpenGL поддержка всего, от современных основных контекстов с сопоставимым конвейером рендеринга до DirectX и Vulkan, вплоть до старого конвейера с фиксированными функциями, невероятно сложна. Написание новой реализации OpenGL с нуля практически нецелесообразно. Вот почему у нас есть этот проект для повторного использования (и внесения улучшений) Mesa, потому что это действительно требует меньше усилий, чем если бы каждый поставщик придумал полную, совместимую и производительную реализацию GL/CL.

Я не предлагал Microsoft «перенести весь мир на Vulkan/GL/CL» или создать новую реализацию. Я сказал, что для Microsoft имеет смысл разрешить передачу поддержки драйверов для Khronos API гостю (в данном случае WSL). Встроенный эмулятор Android Studio делает это, так почему Microsoft не может?

Единственное техническое преимущество, которое я вижу в нынешнем подходе, заключается в том, что DirectX полностью доступен в Linux, что не имеет смысла для разработки программного обеспечения для Linux. Пытается ли Microsoft заставить людей писать программы для Linux, которые работают только в контексте WSL?

> Я сказал, что для Microsoft имеет смысл разрешить передачу поддержки драйверов для Khronos API гостевой системе (в данном случае WSL). Встроенный эмулятор Android Studio делает это, так почему Microsoft не может?

Конечно, поставщики могут это сделать, если захотят. Я предполагаю, что они, вероятно, не захотят, потому что это означает создание реализаций Linux EGL поверх их существующего драйвера Windows, что не так уж и просто.

Новый API /dev/dxg и подход Android/ChromeOS сильно различаются. /dev/dxg _не_ проходит через "API DirectX" в смысле вызовов D3D, которые вы используете для рендеринга. Это очень низкоуровневый API, очень похожий на DRM в Linux, который позволяет пользовательскому пространству распределять буферы, отправлять шейдерные программы, предварительно скомпилированные в аппаратный байт-код, для выполнения и синхронизироваться с этим выполнением — вот и все. Это то, что драйверы DirectX и OpenGL работают поверх Windows. Таким образом, чтобы запускать драйверы DirectX внутри WSL, вам необходимо портировать как ядро ​​DIrectX, так и каждый аппаратный драйвер для работы в Linux, или грубый эквивалент переноса всех Mesa и его драйверов. IHV также могли бы перенести свои драйверы OpenCL/GL на использование этого интерфейса, но для поддержания этого требуется значительная работа.

Эмуляции ChromeOS и Android используют VirGL, который вместо того, чтобы предоставлять низкоуровневый аппаратный интерфейс, эффективно передает вызовы OpenGL по сети после некоторой оптимизации на стороне гостя. VirGL не так эффективен, как подход /dev/dxg, и никогда не будет таким. Однако, как вы заметили, он максимально совместим: все, что вам нужно, это платформа виртуализации KVM и хост с драйверами OpenGL (ES).

> Единственное техническое преимущество, которое я вижу в нынешнем подходе, заключается в том, что DirectX полностью доступен в Linux, что не имеет смысла для разработки программного обеспечения для Linux. Пытается ли Microsoft заставить людей писать программы для Linux, которые работают только в контексте WSL?

Ни одно из решений (предоставление доступа к аппаратному интерфейсу или предоставление доступа к высокоуровневому API) на самом деле не лучше и не хуже другого; это просто разные компромиссы.

Спасибо за разъяснение. Но если /dev/dxg просто предоставляет доступ к аппаратному интерфейсу, почему бы не открыть этот аппаратный интерфейс с помощью существующих механизмов DRM?

Поскольку DRM не является полностью аппаратно-независимым интерфейсом (на самом деле вы не можете выполнять какие-либо команды графического процессора без специфичных для драйвера ioctl-ов, в основном называемых execbuf), и это также не собственный интерфейс виртуализации (как это сильно зависит от файловых дескрипторов). Он также не перенесен в Windows, поэтому вам нужно будет портировать инфраструктуру DRM каждого драйвера в Windows (с прокладками, учитывающими поведенческие различия между различными реализациями ОС драйверов поставщика) и найти способ виртуализации DRM?

В этом упражнении по переносу мы начнем с основ: переносим простой модуль визуализации для вращающегося куба с затенением вершин из OpenGL ES 2.0 в Direct3D, чтобы он соответствовал шаблону приложения DirectX 11 (универсальное приложение для Windows) из Visual Studio 2015. По мере прохождения процесса переноса вы узнаете следующее:

  • Как перенести простой набор буферов вершин во входные буферы Direct3D
  • Как перенести формы и атрибуты в буферы констант
  • Как настроить объекты шейдера Direct3D
  • Как базовая семантика HLSL используется при разработке шейдеров Direct3D
  • Как перенести очень простой GLSL на HLSL

Этот раздел начинается после того, как вы создали новый проект DirectX 11. Чтобы узнать, как создать новый проект DirectX 11, прочитайте статью Создание нового проекта DirectX 11 для универсальной платформы Windows (UWP).

В проекте, созданном по любой из этих ссылок, уже подготовлен весь код для инфраструктуры Direct3D, и вы можете сразу приступить к процессу переноса средства визуализации из Open GL ES 2.0 до Direct3D 11.

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

  1. Создание сетки куба из жестко заданных данных. Эта сетка представлена ​​в виде списка вершин, где каждая вершина имеет положение, вектор нормали и вектор цвета. Эта сетка помещается в буфер вершин для обработки конвейером затенения.
  2. Создание объектов шейдера для обработки сетки куба. Существует два шейдера: вершинный шейдер, обрабатывающий вершины для растеризации, и фрагментный (пиксельный) шейдер, окрашивающий отдельные пиксели куба после растеризации. Эти пиксели записываются в цель рендеринга для отображения.
  3. Формирование языка затенения, используемого для обработки вершин и пикселей в вершинном и фрагментном шейдерах соответственно.
  4. Отображение визуализированного куба на экране.

По завершении этого пошагового руководства вы должны быть знакомы со следующими основными различиями между Open GL ES 2.0 и Direct3D 11:

  • Представление буферов вершин и данных вершин.
  • Процесс создания и настройки шейдеров.
  • Языки затенения, а также входные и выходные данные для объектов затенения.
  • Варианты рисования экрана.

В этом пошаговом руководстве мы ссылаемся на простую и универсальную структуру средства визуализации OpenGL, которая определяется следующим образом:

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

Примечание. Любой код OpenGL ES 2.0 в этом разделе основан на реализации API Windows, предоставленной Khronos Group, и использует синтаксис программирования Windows C.

Что вам нужно знать

Технологии

Предпосылки

  • Необязательно. Просмотрите код переноса EGL в DXGI и Direct3D. Прочтите этот раздел, чтобы лучше понять графический интерфейс, предоставляемый DirectX.

Шаги

При переносе простого средства визуализации из OpenGL ES 2.0 первым шагом является настройка эквивалентных объектов вершинного и фрагментного шейдера в Direct3D 11 и обеспечение возможности взаимодействия основной программы с объектами шейдера после их компиляции.

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

После того как вы перенесли код, который создает и настраивает ваши буферы и объекты шейдеров, пришло время перенести код внутри этих шейдеров с языка шейдеров GL (GLSL) OpenGL ES 2.0 на язык шейдеров высокого уровня Direct3D 11. (HLSL).

Unity поддерживает графические API DirectX 11 (DX11) и OpenGL Core. На этой странице подробно описано, как их использовать.

Включение DirectX 11

DirectX 11 включен по умолчанию в Windows. Ваши игры и редактор Unity используют DX11 и возвращаются к DX9, когда DX11 недоступен.

Чтобы включить или отключить DirectX 11 для сборок игры и редактора, выберите «Правка» > «Настройки проекта» > «Проигрыватель», чтобы открыть настройки проигрывателя. Перейдите к «Другие настройки» и снимите флажок с Auto Graphics API для Windows. В появившейся панели выберите Direct3D11 и нажмите кнопку "минус" (-), чтобы удалить его, или нажмите кнопку "плюс" (+) и выберите Direct3D11 из списка, чтобы добавить его.

Добавление Direct3D11 в список графических API для Windows

После того, как Direct3D11 появится в списке, вы можете перетаскивать его вверх и вниз, чтобы определить приоритет, в котором выбран графический API. Редактор Unity и проигрыватель по умолчанию используют тот, это как запасной вариант, в порядке их перечисления.

ПРИМЕЧАНИЕ. Для DX11 требуется Windows Vista или более поздняя версия и как минимум графический процессор уровня DX10 (предпочтительно уровня DX11). Заголовок окна редактора Unity отображается в конце, когда он работает в режиме DX11.

Включение ядра OpenGL

OpenGL Core включен по умолчанию на Mac и Linux. Ваши игры и редактор Unity используют OpenGL Core на этих платформах.

Чтобы включить OpenGL Core в Windows и установить его по умолчанию, выберите «Правка» > «Настройки проекта» > «Проигрыватель», чтобы открыть настройки проигрывателя. Перейдите к «Другие настройки» и снимите флажок с Auto Graphics API для Windows. В появившейся панели нажмите кнопку плюса (+) и выберите OpenGLCore из списка, чтобы добавить его.

Добавление OpenGLCore в список графических API для Windows

OpenGL Core имеет следующие минимальные требования:

  • Mac OS X 10.8 (OpenGL 3.2), MacOSX 10.9 (OpenGL 3.2–4.1)
  • Windows с NVIDIA с 2006 г. (GeForce 8), AMD с 2006 г. (Radeon HD 2000), Intel с 2012 г. (HD 4000 / IvyBridge) (от OpenGL 3.2 до OpenGL 4.5)
  • Linux (от OpenGL 3.2 до OpenGL 4.5)

Вычислительные шейдеры

Вычислительные шейдеры позволяют использовать GPU в качестве параллельного процессора. Дополнительные сведения см. в документации по вычислительным шейдерам.

Тесселяция и геометрические шейдеры

Поверхностные шейдеры поддерживают простую тесселяцию и смещение. Дополнительную информацию см. в документации по тесселяции шейдеров поверхности.

При написании шейдерных программ вручную можно использовать полный набор функций модели шейдеров DX11 5.0, включая шейдеры геометрии, оболочки и домена.

Поверхностные шейдеры и DX11

Некоторые части конвейера компиляции шейдеров поверхности не понимают синтаксис HLSL, специфичный для DX11, поэтому, если вы используете функции HLSL, такие как StructuredBuffers, RWTextures и другой синтаксис, отличный от DX9, вам необходимо обернуть его в препроцессор только для DX11. макрос. Дополнительную информацию см. в документации по различиям между платформами.

Эффекты изображения, хорошо работающие с DX11 и OpenGL Core

  • Эффект глубины резкости (оптимизированное разбрызгивание текстуры боке)
  • Эффект «Шум и зернистость» (более качественные шумовые паттерны)
  • Эффект размытия в движении (фильтр реконструкции более высокого качества)

Примеры

На следующих снимках экрана показаны примеры того, чего можно добиться с помощью DirectX 11 и OpenGL Core.

Объемный взрыв на приведенных выше снимках визуализируется с помощью raymarching, что становится правдоподобным с Shader Model 5.0. Кроме того, поскольку он генерирует и обновляет значения глубины, он становится полностью совместимым с эффектами изображения на основе глубины, такими как глубина резкости или размытие в движении.

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

Подобно технике прически, показанной на предыдущем изображении, мех на этой паре тапочек также основан на создании геометрии, полученной из простой базовой сетки тапочек.

Эффект размытия на изображении выше (известный как боке) основан на нанесении текстуры поверх очень ярких пикселей. Это создает очень правдоподобное размытие объектива камеры, особенно при использовании в сочетании с визуализацией HDR.

На этом изображении показано преувеличенное размытие объектива. Это возможный результат использования нового эффекта глубины резкости.

Авторские права © Unity Technologies, 2017. Публикация: 5.6-001Н. Дата постройки: 12 июля 2017 г.

Было бы очень хорошо, если бы Minecraft: Java Edition работала с DirectX вместо OpenGL, потому что с OpenGL Minecraft использует больше мощности ПК, чем с DirectX. Я знаю, что Java поддерживает только OpenGL, но если создатели каким-то образом перейдут с Java на что-то более простое, это нарушит традицию, но позволит Minecraft работать лучше и быстрее.

7 комментариев

Опубликовать новый комментарий:

Пожалуйста, войдите, чтобы оставить комментарий.

Отсортировано по дате голосования

  • 10 апреля 2020 г., 13:19
  • Пожаловаться на комментарий
  • Действия с комментариями Постоянная ссылка

DirectX хорош, но будет работать еще медленнее. На второй или третьей странице был пост, в котором требовался Vulkan для рендеринга, а Vulkan — самый быстрый API рендеринга из всех.

  • 9 июля 2020 г., 22:13
  • Пожаловаться на комментарий
  • Действия с комментариями Постоянная ссылка

Java работает очень плохо! Directx или vulkan полностью изменили бы производительность игры

  • 04 сентября 2020 г., 20:05
  • Пожаловаться на комментарий
  • Действия с комментариями Постоянная ссылка
  • 25 сентября 2020 г., 01:40
  • Пожаловаться на комментарий
  • Действия с комментариями Постоянная ссылка

FatalAcacia Немного неправильно говорить, что OpenGL или DX "медленнее" или "быстрее", потому что производительность полностью зависит от программиста. Vulkan не «быстрее» сам по себе, но он НАМНОГО более низкоуровневый, поэтому он может быть быстрее, поскольку низкоуровневое программирование позволяет лучше контролировать оптимизацию.

  • 30 ноября 2020 г., 17:15
  • Пожаловаться на комментарий
  • Действия с комментариями Постоянная ссылка

Проблема с использованием DirectX заключается в том, что Minecraft Java предназначен для совместимости с платформой, а DirectX - нет. Также в minecraft java используется lwjgl, который включает только opengl и vulkan. Вероятно, поэтому, если вам нужен лучший движок рендеринга в майнкрафте, два варианта — более новый opengl или vulkan. Vulkan потребует больше работы, но если все сделано правильно, производительность будет намного выше, особенно для пользователей видеокарт AMD в Windows.

Unity может использовать графические API DirectX 11 и OpenGL Core со всеми ожидаемыми от них функциями: вычислительные шейдеры, шейдеры тесселяции, модель шейдеров 5.0 и т. д.

Включение DirectX 11

Этот параметр включен по умолчанию (т. е. в Windows ваши игры и редактор будут пытаться использовать DX11 и возвращаться к DX9, когда он недоступен). Чтобы включить DirectX 11 для сборок игры и редактора, включите параметр «Использовать DX11» в настройках проигрывателя.

ПРИМЕЧАНИЕ. Для DX11 требуется Windows Vista или более поздняя версия и как минимум графический процессор уровня DX10 (предпочтительно уровня DX11). Заголовок окна редактора Unity отображается в конце, когда он работает в режиме DX11.

Включение ядра OpenGL

Этот параметр включен по умолчанию для Mac и Linux (т. е. на этих платформах ваши игры и редактор будут использовать OpenGL Core).

Вы можете включить OpenGL Core в Windows и установить его по умолчанию, перейдя в настройки проигрывателя, сняв флажок «Auto Graphics API для Windows» и добавив OpenGL Core в список. Затем вы можете перетащить OpenGL Core в начало списка, если хотите использовать его по умолчанию.

Включение ядра OpenGL для Windows

ПРИМЕЧАНИЕ. Минимальные требования OpenGL Core:*

  • Mac OS X 10.8 (OpenGL 3.2), MacOSX 10.9 (OpenGL 3.2–4.1)
  • Windows с NVIDIA с 2006 г. (GeForce 8), AMD с 2006 г. (Radeon HD 2000), Intel с 2012 г. (HD 4000 / IvyBridge) (от OpenGL 3.2 до OpenGL 4.5).
  • Linux (от OpenGL 3.2 до OpenGL 4.5).

Эффекты изображения, которые могут использовать преимущества DX11/OpenGL Core

  • Эффект глубины резкости (оптимизированное разбрызгивание текстуры боке)
  • Эффект «Шум и зернистость» (более качественные шумовые паттерны)
  • Эффект размытия в движении (фильтр реконструкции более высокого качества)

Вычислительные шейдеры

Вычислительные шейдеры позволяют использовать GPU в качестве процессора с массовым параллелизмом. Подробнее о режиме см. на странице Compute Shaders.

Тесселяция и геометрические шейдеры

Шейдеры поверхности поддерживают простую тесселяцию и смещение, см. страницу Мозаика шейдеров поверхности.

При написании шейдерных программ вручную можно использовать полный набор функций модели шейдеров DX11 5.0, включая геометрические шейдеры, шейдеры оболочки и домена.

Поверхностные шейдеры и DX11

В настоящее время некоторые части конвейера компиляции поверхностных шейдеров не понимают синтаксис HLSL, специфичный для DX11, поэтому при использовании функций HLSL, таких как StructuredBuffers, RWTextures и другой синтаксис, отличный от DX9, вам необходимо включить его в макрос препроцессора только для DX11. Подробнее см. на странице «Различия платформ».

Примеры

На следующих снимках экрана показаны примеры возможностей DirectX 11/OpenGL Core.

Объемный взрыв на этих кадрах визуализируется с помощью raymarching, что становится правдоподобным с моделью шейдера 5.0. Более того, поскольку он генерирует и обновляет значения глубины, он становится полностью совместимым с эффектами изображения на основе глубины, такими как глубина резкости или размытие движения. Волосы на этом снимке реализованы с помощью шейдеров тесселяции и геометрии для динамического создания и анимации отдельных прядей волос. Затенение основано на модели, предложенной Kajiya-Kai, которая обеспечивает более правдоподобное рассеянное и зеркальное поведение. Подобно технике с волосами выше, показанный мех тапочек также основан на создании геометрии, испускаемой из простой базовой сетки тапочек. Эффект размытия на этом изображении (известный как боке) основан на нанесении текстуры поверх очень ярких пикселей. Это может создать очень правдоподобное размытие объектива камеры, особенно при использовании в сочетании с рендерингом HDR. Преувеличенное размытие объектива, как на скриншоте выше. Это возможный результат использования нового эффекта глубины резкости

Читайте также: