| Content Creation Tools and Multi-GPU

When it comes to multi-GPU (mGPU), most developers immediately think of complicated Crossfire setups with two or more GPUs and how to make their game run well on those setups. This is however only one side of the mGPU story – the other one is mGPU during content creation. If you’re a developer working on a game, you should think of using mGPU to make your life easier.

One tool per GPU

In many cases, artists will run your in-game editor or preview while working with other DCC tools like Maya® or Mari®. In this case these DCC applications must share resources with your editing tool as well as the desktop compositor. Especially when working with dense geometry and high-resolution textures, memory can easily become a bottleneck – more so as the editing tools are optimized for fast iteration time, not minimal resource usage. In this case, you can get a much better user experience by using an mGPU system and forcing your tool to use the second GPU.

This can be easily done in all modern graphics APIs: Direct3D® 11 allows you to enumerate your adapters, and just picking the second one is usually fine as most applications will pick the first one by default. Make sure to not simply call D3D11CreateDevice () with a null adapter, instead, enumerate them all and pick an appropriate one. You can reuse the same code for Direct3D 12. 

For Vulkan®, this requires a (currently experimental) extension to associate a Vulkan device with the corresponding D3D device. You can assume that most applications will just pick the first adapter, and if you want to know which of your Vulkan devices that is, you can use the VK_KHX_external_memory_capabilities extension. It provides access to the LUID of a physical device, which can be queried from the DXGI device. Please keep in mind that this extension is experimental: The idea is you can test it today and give feedback whether it works, and eventually, it’ll get replaced by a KHR variant. It’s very likely that the final extension will look very similar, but until then, please use this for your internal tools only and don’t ship yet.

Sample

To get you started, I’ve written a tiny sample which shows you how to enumerate DXGI adapters (which works for both 11 and 12), and how to enumerate the Vulkan devices. Here’s the sample output for a machine with two Radeon RX 580, and one Radeon Fury X:

Enumerating DXGI devices
    DXGI Adapter:  Radeon RX 580 Series - LUID: 00000000001251cd
    DXGI Adapter:  Radeon RX 580 Series - LUID: 0000000000126510
    DXGI Adapter:  AMD Radeon (TM) R9 Fury Series - LUID: 000000000000be80
    DXGI Adapter:  Microsoft Basic Render Driver - LUID: 000000000000be66

Enumerating Vulkan devices
    Vulkan device: AMD Radeon (TM) R9 Fury Series - LUID: 000000000000be80
    Vulkan device: Radeon RX 580 Series - LUID: 00000000001251cd
    Vulkan device: Radeon RX 580 Series - LUID: 0000000000126510

That’s it! With the right affinity settings, you can use two GPUs to get robust performance in the most common case, where you need to run both your game and some DCC application, or even just the editor, at the same time.

| OTHER POSTS BY MATTHAEUS CHAJDAS

Fast compaction with mbcnt

With shader extensions, we provide access to a much better tool to get compaction done: GCN provides a special op-code for compaction within a wavefront.

GCN Shader Extensions for Direct3D and Vulkan

One of the mandates of GPUOpen is to give developers better access to the hardware, and this post details extensions for Vulkan and Direct3D12 that expose additional GCN features to developers.

Vulkan barriers explained

Vulkan barriers are unique as they requires you to provide what resources are transitioning and also specify a source and destination pipeline stage.

Optimizing Terrain Shadows

One thing which is often forgotten is shadow map rendering. As the tessellation level of the terrain is not optimized for the shadow camera, but for the primary camera, this often results in a very strong mismatch and shadow maps end up getting extremely over-tessellated.

Matthaeus Chajdas
Matthäus Chajdas is a developer technology engineer at AMD. Links to third party sites, and references to third party trademarks, are provided for convenience and illustrative purposes only. Unless explicitly stated, AMD is not responsible for the contents of such links, and no third party endorsement of AMD or any of its products is implied.

| YOU MAY ALSO LIKE...

Tutorials Library

Browse all our fantastic tutorials, including programming techniques, performance improvements, guest blogs, and how to use our tools.

Samples Library

Browse all our useful samples. Perfect for when you’re needing to get started, want to integrate one of our libraries, and much more.