Directx 12 multi gpu

На данный момент обсуждения идут, в основном, вокруг низкоуровневых тестов DirectX 12, поскольку меньшая избыточная вычислительная нагрузка обещает прирост производительности. Новый API позволяет использовать видеокарты AMD и NVIDIA одновременно, теоретически складывая их ресурсы производительности.

DirectX 12 Multi-GPU Explicit Multi-Adapter или Multi Display Adapter – такими терминами сегодня описывается взаимодействие разных GPU. Технология стала возможной благодаря доступу к API на более глубоком уровне. Теперь разработчики получают более эффективные средства управления памятью и многими другими компонентами «железа». Работа систем multi-GPU под DirectX 11 была полностью в руках разработчиков драйверов. Под DirectX 12 «власть» перешла к разработчикам игр. Издание Anandtech провело первые тесты Multi-GPU Explicit Multi-Adapter. Для теста издание получило специальный билд игры Ashes of Singularity от Oxides Games.

Технология Multi-GPU

Но сначала позвольте сказать пару слов о технологии multi-GPU: появление интерфейса PCI Express для взаимодействия видеокарты и остальной системы привел к тому, что AMD и NVIDIA смогли использовать технологию AFR (Alternate Frame Rendering) для простой поддержки multi-GPU. AFR подразумевает поочередное вычисление кадров на каждом GPU. Вносить какие-либо изменения в игру или игровой движок при этом не требуется. Разработчикам AMD и NVIDIA достаточно внести в драйверы соответствующую поддержку, чтобы отличия по времени вывода отдельных кадров не приводили к появлению артефактов. AMD представила технологию сглаживания кадров Frame Pacing, NVIDIA тоже ответила собственной аппаратно-программной технологией. Кроме того, синхронизация частоты кадров между GPU и панелью дисплея в виде FreeSync и G-Sync позволяет минимизировать появление артефактов.
Но выбор аппаратной платформы оставался ограниченным. NVIDIA позволяла взаимодействие только идентичных моделей видеокарт, AMD предоставила большую гибкость, по крайней мере, использование видеокарт на одном GPU (например, Radeon R9 290 и Radeon R9 290X). Конечно, тому есть причина – видеокарты разного уровня производительности не могут в AFR рассчитывать кадры за сравнимое время. Решение может заключаться в технологии SFR (Spit Frame Rendering), но она так и не стала популярной. О SFR мы поговорим чуть позже.
Впрочем, уже совершались попытки объединить видеокарты разных производителей без использования официальных режимов SLI и Crossfire. В 2010 году LucidLogix представила технологию Hydra. С помощью дополнительного чипа и программного обеспечения технология распределяла вызовы DirectX и OpenGL между совместимыми видеокартами. Но при этом имелись весьма серьезные ограничения по аппаратной базе и по программной поддержке. Все это привело к тому, что технология Hydra так и не смогла набрать популярность, уйдя в небытие.

DirectX 12 и Multi-Adapter

С появлением DirectX 12 Microsoft представила три режима multi-adapter. В самом простом случае используется упомянутая выше технология AFR с видеокартами одного производителя AMD или NVIDIA. Но данный режим ограничивает возможности игровых разработчиков, но вместе с тем уменьшает вероятность потенциального возникновения ошибки из-за глубокого доступа к «железу». Большая часть работы для поддержки выполняется в драйвере, а не под DirectX 12.

DirectX 12 обеспечивает более глубокий доступ к «железу» даже в системах multi-GPU. Для этого Microsoft представила режим Explicit Multi-Adapter (EMA). В нем игровые разработчики явно задают параметры поддержки multi-GPU. Для каждого одиночного GPU определяется доступ к памяти, описывается взаимодействие GPU между собой – и вся эта поддержка должна быть запрограммирована заранее. Ответственность за работу связки видеокарт теперь полностью лежит в руках разработчиков, что привносит определенные риски. Дополнительные усилия разработчиков не стоит недооценивать, а ошибки должен будет исправлять разработчик, а не Microsoft, AMD или NVIDIA.

В режиме EMA возможны два разных режима: Linked Mode и Unlinked Mode. В режиме Unlinked Mode обеспечивается базовая функциональность EMA, в режиме Linked Mode функциональность расширяется, но ограничения по используемому в комбинации «железу» становятся более строгими. Например, можно использовать только системы SLI и CrossFire под DirectX 12. В режиме Unlinked Mode вы можете комбинировать разные видеокарты, в том числе и от разных производителей. Возможна комбинация дискретного и интегрированного GPU.

В режиме Unlinked Mode каждый графический процессор считается самостоятельной аппаратной единицей, со своей памятью, командным процессором и т.д. EMA под DirectX 12 позволяет обмениваться данными между аппаратными единицами, причем на глубоком уровне, а не просто готовыми кадрами. Можно обмениваться частично просчитанными кадрами или данными в буферах, что позволяет выйти на новые уровни совместного рендеринга на нескольких GPU. На первый взгляд все звучит просто, стал возможен обмен данными, что открывает доступ к алгоритмам, ранее недоступным. Но на практике все сложнее. Данные придется передавать по интерфейсу PCI Express, что намного медленнее связи между GPU и локальной видеопамятью, да и задержки довольно большие. Так что разработчикам следует определить, какие данные имеет смысл передавать между GPU, чтобы интерфейс PCI Express не стал «узким местом». Также следует определиться, в каком виде передавать данные. У разных производителей и даже разных поколений GPU зачастую используются разные форматы данных, которые не всегда просто перевести из одного в другой. Придется прилагать дополнительные усилия, необходимые для реализации EMA в Unlinked Mode. Впрочем, фокусом Unlinked Mode в EMA является все же совместная работа дискретных и интегрированных GPU, но и здесь могут использоваться GPU разных производителей.

Режим Linked Mode можно рассматривать как форму SLI или Crossfire под DirectX 12, аппаратные ресурсы в Linked Mode комбинируются в своего рода «видеокарту». Пользователь и игровой движок «видят» только один GPU и память. Аппаратные ресурсы здесь будут использоваться более тесно и глубоко, что открывает больше возможностей, но при этом накладываются дополнительные ограничения на «железо». Самый большой потенциал производительности можно будет раскрыть через Linked Mode, а самый большой уровень гибкости – через Unlinked Mode. Если разработчики хотят приложить минимальные усилия, и им достаточно базовой функциональности системы multi-GPU, то достаточно поддержать простой вариант EMA, доверившись квалификации разработчиков драйверов AMD и NVIDIA. Но поскольку только разработчики игры в полной мере владеют всеми нюансами своего продукта, то поддержка Linked и Unlinked Mode тоже весьма желательна.

EMA в Ashes of Singularity

Oxides Games и Ashes of Singularity на прошлой неделе открыли ранний доступ Steam к своей игре. Стратегия реального времени должна выйти в 2016 году. Она станет первой игрой данного жанра с поддержкой DirectX 12, а разработчики Oxides Games первыми постарались полностью задействовать возможности DirectX 12. AMD и Microsoft в сотрудничестве со студией разработчиков смогли построить технологическую демонстрацию на основе игры. Для демонстрации EMA разработчики Oxides Games использовали технологию AFR. Они управляли распределением кадров по отдельным GPU – ранее эту работу выполнял драйвер. Также разработчикам пришлось самостоятельно решать вопрос передачи кадров от дополнительных GPU на основной, а также реализовывать сглаживание частоты кадров (Frame Pacing). Технология AFR лучше всего работает при использовании идентичных видеокарт, поскольку они справляются с расчетом кадров за близкое время. В любом случае, данная реализация идет дальше, чем привычные варианты AMD и NVIDIA. Вы можете комбинировать разные GPU от разных производителей, что позволяет одновременно работать, например, GeForce GTX Titan X с GeForce GTX 980 Ti. Но для работы все видеокарты должны поддерживать DirectX 12. И наши коллеги Anandtech провели многочисленные тесты.
Игра Ashes of Singularity по-прежнему находится в альфа-состоянии. И поддержка Unlinked Mode EMA является экспериментальной. Можно использовать только определенную комбинацию драйверов AMD и NVIDIA, но результаты оказались намного лучше, чем можно было ожидать. Oxides Games сначала будет улучшать Unlinked Mode, после чего перейдет к поддержке Linked Mode. Здесь ожидается прирост производительности в диапазоне 5-10%.

Ниже приведены результаты первых тестов:

Пару слов о результатах. Прирост производительности пары Radeon R9 X Fury и Radeon R9 Fury оказался весьма впечатляющим, то же самое можно сказать о смешанном режиме Radeon R9 Fury X и GeForce GTX 980 Ti. Выбор других основных видеокарт дает уже меньшую разницу. От Unlinked Mode могут выиграть даже старые видеокарты.
В BUILD 2015 Microsoft уже представила функционирующий режим Unlinked Mode в теории, но появление независимых тестов можно назвать хорошим признаком, указывающим на текущее состояние разработки. Но все же пока еще можно говорить только о раннем состоянии перехода с DirectX 11 на DirectX 12. Пройдет несколько месяцев, прежде чем на рынке начнут появляться игры. А до поддержки DirectX 12 всеми разработчиками пройдут годы. То же самое касается реализации всех сопредельных технологий. Большинство разработчиков наверняка довольно быстро воспользуются преимуществом производительности благодаря уменьшению избыточной нагрузки. Но до повсеместной реализации EMA, режимов Unlinked и Linked Mode пройдет намного больше времени. Геймерам пока только остается ждать соответствующей поддержки со стороны разработчиков.

This blog post is about explicit multi-GPU programming that became possible with the introduction of the DirectX 12 API. In previous versions of DirectX, the driver had to manage multiple SLI GPUs. Now, DirectX 12 gives that control to the application. There are two parts in this blog post. In this first part, I’ll explain how multiple GPUs are exposed in the DirectX API, giving some pointers to the API documentation. Please look for further details in the documentation itself. In the second part, I’ll describe a technique called frame pipelining — a new way for utilizing multiple GPUs that was not possible before DirectX 12.

Background

Since the launch of SLI, a long time ago, utilization of multiple GPUs was handled automatically by the display driver. The application always saw one graphics device object no matter how many physical GPUs were behind it. With DirectX 12, this is not the case anymore. But why start doing something manually that has been working automatically? Because, actually, for a good while before DirectX 12 arrived, the utilization of multiple GPUs has not been that automatic anymore.

As rendering engines have grown more sophisticated, the distribution of rendering workload automatically to multiple GPUs has become problematic. Namely, temporal techniques that create data dependencies between consecutive frames make it challenging to execute alternate frame rendering (AFR), which still is the method of choice for distribution of work to multiple GPUs. In practice, the display driver needs hints from the application to understand which resources it must copy from one GPU to another and which it should not. Data transfer bandwidth between GPUs is very limited and copying too much stuff can make the transfers the bottleneck in the rendering process. Giving hints to the driver can be implemented with NVAPI or by making additional Clear() or Discard() calls for selected resources.

Consequently, even when you didn’t have explicit control over multiple GPUs, you had to understand what happened implicitly and give the driver hints for doing it efficiently in order to get the desired performance out of multi-GPU setups. Now with DirectX 12, you can take full and explicit control of what is happening. And you are no longer limited to AFR. You are free to invent new ways of making use of multiple GPUs that better suit your application.

Adapters — Multiple or Linked Together

DirectX 12 exposes two alternate ways of controlling multiple physical GPUs. They can be controlled as multiple independent adapters where each adapter represents one physical GPU. Alternatively, they can be configured as one “linked node adapter” where each node represents one physical GPU. However, it’s important to note that application cannot control how it sees multiple GPUs. It cannot link or unlink adapters. The selection is done by end user through display driver settings.

Image 1. Multiple physical GPUs seen as multiple adapters
Image 2. Multiple physical GPUs seen as a linked node adapter
Image 3. Enabling SLI in NVIDIA control panel enables linked node mode in DirectX 12 API

In practice, the linked node mode is meant for multiple equal, discrete GPUs, i.e. classic SLI setups. It offers a couple of important benefits. Within a linked node adapter, resources can be copied directly from memory of one discrete GPU to memory of another. The copy doesn’t have to pass through system memory. Additionally, when presenting frames from secondary GPUs in AFR, there’s a special API for supporting connections other than PCIe. (See IDXGISwapChain3::ResizeBuffers1() in DirectX documentation.)

Image 4. In linked node adapter, connections other than PCIe can be utilized for presenting frames from secondary GPUs in alternate frame rendering

Today, all available linked node implementations link only equivalent GPUs. In practice, applications can build their load balancing between the nodes on this assumption. However, the linked node API doesn’t actually guarantee that nodes have equal performance. Someday, heterogeneous linked node adapters may be available making the load balancing less trivial.

Image 5. Today, linked node adapters are homogeneous in practice.

In this blog post, I’ll focus on linked node adapter due to its suitability for classic multi GPU setups.

Engine requirements

To explicitly utilize multiple GPUs, the renderer needs to be aware of their existence. This requires some new code infrastructure. Building the infrastructure can actually be the task that requires most effort. Once the infrastructure exists, it’s easier to experiment with different ways of utilizing all the GPUs in the system.

When using a linked node adapter, you create one ID3D12Device as you would with a single physical GPU. But various objects that you create through the ID3D12Device use node affinity masks to identify the nodes with which the object is associated. The affinity mask is a bitmask where each bit represents one node (physical GPU). Some objects are exclusive to one physical GPU meaning that exactly one bit in the node mask must be set. Others can be associated with (or created on) arbitrary GPUs.

Image 6. Node affinity bitmasks are used to reference nodes (GPUs)

For example, when you create a ID3D12CommandQueue for submitting work to the GPU, you specify a node mask to identify the physical GPU to which the command queue feeds work. The ID3D12CommandQueue is one of the APIs that are exclusive to one node. Likewise, the ID3D12CommandList objects are exclusive to one node. As a result, you have to replicate your command list pooling system for each node. ID3D12PipelineState, on the other hand, is an example of an object that can be associated with arbitrary nodes. You don’t have to create separate object for each node. The same pipeline state object can be set to command lists associated with any node.

When sharing resources, the application is responsible for synchronizing the command queues to avoid access conflicts. Also, the application must ensure that the queues see resources in the same state, i.e. the resource barriers set by different command queues must match. ID3D12Fence is the synchronization tool that is used for these purposes.

Image 7. Fences are used to synchronize resource access by different queues (GPUs)

DirectX 12 exposes “copy engines”, i.e. command queues that accept only command lists containing copy operations such as ID3D12GraphicsCommandList::CopyResource(). Copy engines are special hardware that can perform copy operations at the same time as graphics and compute engines are doing other work. They are additional parallel processing power available for copy operations. The number of copy engines available at hardware level varies on each GPU model, but a safe assumption is that there is at least one hardware copy engine available per each physical GPU. The copy engines are very useful in multi-GPU programming. Copying resources over PCIe bus is slow and the copy engines allow other processing on the GPU to go on while they are doing the slow copy operations. (However, copy engines are not good for copies within a physical GPU because they are not designed to operate faster than the PCIe bus allows. Graphics and compute engines are much faster for this purpose. Copy engines do have their place on single-GPU systems — for copying from system memory to video memory over the PCIe bus.)

Image 8. A copy engine can do the slow copies between GPUs while other engines continue working.

In a linked node adapter, there is a tier system for cross node sharing functionality. Tier 1 supports only copy operations on resources residing on other nodes. Tier 2 supports using resources through SRVs, CBVs and UAVs in draw and dispatch calls. The tier 2 functionality may seem convenient, but the parallel copy engines cannot do draw or dispatch calls and slowing down the other engines with cross node resource access is usually not wise.

When creating resources, you specify two separate node affinity masks: CreationNodeMask and VisibleNodeMask. The CreationNodeMask determines the node where the resource physically resides. VisibleNodeMask determines the nodes on which the resource is mapped for access. In the CreationNodeMask, exactly one bit must be set but in the VisibleNodeMask, arbitrary bits can be set. When a resource is accessed from other than creation node, data is transferred between nodes. The transferred data may be cached to avoid retransfer when it’s accessed again but the application should not rely on this. There are no guarantees about the caching behavior. I.e. the application cannot ensure that a given resource stays in cache and it cannot see whether or not a given resource is still in cache. For achieving reliable performance, manually replicating art assets (vertex buffers, textures etc) for each node that uses them is recommended. I.e. don’t just create resources on one node and make them visible to others. Using them through SRVs from other nodes is possible, but there’s no guarantees about the performance.

ID3D12DescriptorHeap objects are exclusive to one node. This means that regardless of whether you replicate the resource objects for each node that uses them or not, the resource views must be replicated in any case. Though when cross node access happens with copy engine, resource views are not used. Copy engine access just needs properly set bits in VisibleNodeMask.

If you implement classic AFR, you should manually duplicate all your resources to all nodes. This includes art assets, render targets and constant buffers and other dynamic resources. On each frame, you use the resources that reside on the node doing the rendering for that frame. You upload dynamic data from CPU to resources on that node and render to target resources on that node using asset resources residing on that node. The transfer of the rendered frame to the primary node (the node to which the monitor is attached) for presentation on screen is best done using the special API provided for it. (See again IDXGISwapChain3::ResizeBuffers1()). Possible data dependencies between the frames should be handled with additional resource copy operations using the copy engine.

This concludes part 1. The second part of the blog post examines frame pipelining, one new alternative to classic AFR that’s now possible with the exposed functionality.

Валерий Косихин

Эта статья была задумана как дань старой традиции: нам хотелось полюбоваться дорогими системами с несколькими GPU, как это было в 2014 и 2016 годах, а потом мы готовились с разочарованием признать, что технологии SLI и CrossFire уже утратили всякую практическую ценность. Но вместо этого получилось своего рода продолжение наших недавних публикаций про API нового поколения (см. первую и вторую части исследования), ведь большинство игр из нашей тестовой методики поддерживают Direct3D 12. Под этим API пара видеокарт работают совсем по-иному, нежели в Direct3D 11, и нет никакого смысла ограничиваться сравнением под формально устаревшим, но все еще преобладающим интерфейсом Direct3D 11.

А что касается главного вопроса (осталась ли какая-то польза в SLI и CrossFire), то придется признать, что похороны двухадаптерных систем снова откладываются! Да, в связи со сменой API возникли новые проблемы, связанные и c реализаций Multi-Adapter в Direct3D 12, и с пропускной способностью шины PCI Express, и с пресловутой процессорозависимостью игр. Но, с другой стороны, именно Direct3D 12 несет в себе возможности для того, чтобы их преодолеть.

⇡#Мультиадаптерный рендеринг в Direct3D 11

Для начала признаем намеренную неточность в названии статьи, которую могли заметить читатели, следящие за состоянием дел в области игровой графики. Действительно, марка CrossFire ушла в отставку еще в прошлом году. Теперь AMD описывает мультиадаптерные системы термином mGPU, поскольку сфера использования CrossFire (как и NVIDIA SLI) ограничена Direct3D 11, а кто, как не AMD, больше всех приветствует переход к Direct3D 12. Тем не менее сама технология никуда не делась, и даже в настройках драйвера Radeon по-прежнему называется именно так.

В целом оба производителя дискретных GPU сейчас прохладно относятся к мультиадаптерному рендерингу. Это заметно по тому, как сократилось разнообразие конфигураций, в которых работают SLI и CrossFire. Пропали видеокарты на основе двух графических процессоров, без которых прежде не обходилось ни одно обновление архитектуры. Драйверы AMD и NVDIA официально поддерживают не больше двух GPU. А ведь в 2011 году мы тестировали связки из трех и четырех видеокарт класса GeForce GTX 580, и в то время игры могли вполне неплохо загрузить три ускорителя высшего эшелона. К тому же NVIDIA загнала SLI в самый верх своей продуктовой линейки: младшей видеокартой в серии GeForce 10, которая имеет разъемы SLI, является сравнительно мощный и дорогой ускоритель GeForce GTX 1070.

Конечно, именно мощные видеокарты, как правило, и устанавливают парами, а утраченная возможность использовать три или четыре графических процессора по большей части была полезна только для набора рекордных баллов в 3DMark. Но потеря интереса к SLI и CrossFire со стороны хозяев рынка видеокарт отражает общий застой этого направления, к которому привело несоответствие между сложностью технических задач и низким спросом со стороны рядовых геймеров.

В концептуальном плане рендеринг при помощи множественных GPU — это вполне очевидная идея, которая логически следует из высокого параллелизма вычислений, но на практике такие технологии всегда были довольно-таки капризны и требовали постоянного внимания со стороны драйверописателей. В рамках Direct3D 11 функцию разделения нагрузки между несколькими видеоадаптерами целиком выполняет драйвер. Игровой движок, как и в случае одиночного GPU, отдает команды общей очередью, а драйвер распределяет их так, чтобы, пока первый графический процессор создает свой кадр видеоряда, второй GPU занимается следующим кадром (метод AFR — Alternate Frame Rendering). Для полноты картины стоит заметить, что мультиадаптерный рендеринг не сводится к AFR. В редких случаях используется метод SFR (Split Screen Rendering), в котором каждый GPU обрабатывает свою часть единого кадра, а Direct3D 12 предусматривает и более сложные режимы, но о последнем — чуть позже.

В идеале процедура мультиадаптерного рендринга в Direct3D 11 прозрачна для игрового движка и не требует дополнительных усилий от его разработчиков, но на практике все совсем не так просто. При использовании метода AFR нужно считаться с ограничениями в тех ситуациях, когда существуют зависимости между последовательными кадрами, а это практически неизбежно в современных играх. Как следствие, адекватная работа мультиадаптерной системы возможна только при наличии профилей настроек для каждой конкретной игры, благодаря которым драйвер получает подсказки о том, чем занимается движок, а разработчикам игры — в идеале — нужно понимать, что пытается сделать драйвер. Полезно использовать и проприетарный API (такой как NVAPI для GPU NVIDIA), открывающий доступ к GPU в обход уровня абстракции Direct3D, но даже в идеальных условиях не от каждой игры можно добиться хорошего масштабирования быстродействия на нескольких адаптерах.

Свой вклад в эту проблему вносит и пресловутая «процессорозависимость»: графические чипы сейчас развиваются быстрее, нежели быстродействие CPU архитектуры x86 с небольшим числом потоков, и это заметно даже в конфигурациях с одной мощной видеокартой, не говоря уже о двух. Наконец, как мы раз за разом видим по результатам группового теста GPU в какой-нибудь популярной игре, единственный адаптер высшего эшелона, скорее всего, удовлетворит любого геймера. С другой стороны, и разница в качестве изображения между низкими и максимальными настройками качества графики уже не та, что в золотые времена SLI и CrossFire. В результате побуждение наращивать кадровую частоту любой ценой сошло на нет, а раз так, то какой смысл для людей, работающих над драйверами GPU, вкладывать усилия в нишевую технологию мультиадаптерного рендеринга? Пока работа продолжается (особенно со стороны NVIDIA), но с пришествием Direct3D 12 ситуация может полностью измениться — причем как в лучшую, так и в худшую сторону.

⇡#Мультиадаптерный рендеринг в Direct3D 12

Новый графический API Microsoft предусматривает два различных подхода к программированию мультиадаптерного рендеринга. В режиме Implicit Multi-Adapter задачу разделения работы между GPU выполняет драйвер — как в Direct3D 11, со всеми его плюсами и минусами. С другой стороны, в режиме Explicit Multi-Adapter ресурсами графических процессоров целиком распоряжается игровой движок, и это одновременно и благословение, и проклятие, ведь в таком случае все зависит от готовности разработчиков вкладывать силы в поддержку Multi-Adapter.

При должном старании программисты смогут извлечь из связки GPU быстродействие, принципиально недостижимое в предыдущей версии API. В частности, можно отказаться от AFR и применять сложные методы распределения нагрузки между адаптерами — такие как конвейеризация кадров (Frame Pipelining), при которой несколько GPU выполняют различные этапы рендеринга одного кадра, а проблема зависимостей между соседними кадрами отсутствует как таковая. Кроме того, конвейеризацию можно использовать в пользу качества рендеринга, а не частоты смены кадров. К примеру, загрузить второй GPU расчетом глобального освещения, трассировки лучей, физики и так далее.

У Explicit Multi-Adapter есть два метода реализации: Linked Node и Unlinked Node. Первый метод — это аналог SLI и CrossFire в рамках новой парадигмы мультиадаптерного рендеринга. Как и в этих проприетарных технологиях, работающих на уровне драйвера под Direct3D 11, здесь несколько адаптеров представлены общими очередями команд: графика, вычисления общего назначения и очередь Copy для передачи данных по шине PCI Express. Проще говоря, игра «видит» несколько адаптеров как один, а принадлежность команды определенному GPU определяется так называемой маской узла.

Direct3D 12 Linked Node

Linked Node имеет несколько важных достоинств. В первую очередь, подразумевается общая архитектура и производительность узлов, что существенно упрощает задачу балансировки нагрузки. Также Linked Node позволяет узлам напрямую обращаться к оперативной памяти друг друга, минуя системную RAM. Наконец, при рендеринге методом AFR возможна передача кадров «ведущему» узлу через интерфейсы, отличные от PCI Express (то есть мостики SLI, поскольку AMD давно избавилась от специализированной шины в CrossFire).

В свою очередь, в Unlinked Node каждый узел предоставляет собственный набор очередей инструкций и допускает максимально гибкое управление ресурсами GPU. В частности, возможны асимметричные конфигурации из адаптеров неодинаковой мощности и различной архитектуры. Вполне жизнеспособна даже комбинация устройств AMD и NVIDIA в одной системе. Не менее заманчива возможность увеличить быстродействие дискретной графики за счет встроенного в центральный процессор GPU, который сможет выполнять финальные стадии обработки кадра (фактически, это частный случай конвейеризации кадров, и он не требует тщательной балансировки нагрузки, неизбежной в асимметричных связках GPU).

Переход графических адаптеров в Linked Node осуществляется на уровне драйвера, а для пользователя — включением опции SLI или CrossFire в настройках. Тем не менее не всякая игра сможет использовать адаптеры в Linked Node или, напротив, Unlinked Node. К примеру, Ashes of the Singilarity требует активации Unlinked Node, а остальные из наших тестов работают только в режиме Linked.

Direct3D 12 Unlinked Node

Чтобы получить Linked Node под Direct3D 12 на видеокартах NVIDIA, нужно связать их мостиком, иначе драйвер просто не даст включить SLI. Как сказано выше, Direct3D 12 позволяет использовать мостики по назначению в связанном режиме, но мы проверили: ни в одной из тестовых игр нет разницы по кадровой частоте между современным мостом HB SLI Bridge и простым гибким мостиком, которая в противном случае обязательно бы возникла. С одной стороны, это проблема, ведь мостик обеспечивает необходимую пропускную способность для передачи кадров между GPU в обход шины PCI Express даже в таких тяжелых режимах, как 4К. С другой, жесткие мостики с подсветкой, которые способны работать в двухканальном режиме и на повышенной частоте, — дорогое удовольствие, а в Direct3D 12 можно обойтись копеечным гибким интерфейсом.

⇡#Тестовый стенд, методика тестирования

В набор бенчмарков вошли девять игр 2016–2017 годов выпуска, среди которых шесть способны работать под API Direct3D 12. К Direct3D 11 прикованы только относительно старые игры — GTA V и The Witcher 3: Wild Hunt, а также Far Cry 5.

Что касается совместимости с мультиадаптерными системами под Direct3D 11, то она исключена в Ashes of the Singularity, а Battlefield 1 не поддерживает CrossFire. В остальных играх SLI и CrossFire работоспособны под старым API.

В режиме Direct3D 12 две видеокарты задействованы в Ashes of the Singularity, Battlefield 1, Deus Ex: Mankind Divided и Rise of the Tomb Raider. Tom Clancy’s The Division и Total War: WARHAMMER II этой возможности лишены. Кроме того, в Deus Ex: Mankind Divided под Direct3D 12 не работает связка из двух ускорителей Vega 64, хотя нет никаких проблем с Radeon RX 580.