#Benchmark test gpu dx12 free

If you're building a new system, there's really absolutely no reason you'd want to buy – for example – an R9 Fury X and GTX 980 Ti and run them together. Use Case Limitations & the 'Why?'Ī few housekeeping notes: The use cases for multiple, off-brand GPUs are exceedingly limited, as we discuss in the video. A single R9 390X and single GTX 970 were also tested for baseline performance. MDA also allows for multiple, off-brand or off-model GPUs to function in somewhat harmonious processing.įor our tests, we used the MDA approach to combine an R9 390X and GTX 970 together – more just out of interest than anything – and LDA for “standard” SLI testing of 2x GTX 970s. LDA works with SLI bridges and CrossFire bridges, MDA works by just running two display adapters without bridges, relying on the PCI-e bus for communication. Ashes can support both LDA (linked display adapter – or traditional SLI/CrossFire) and MDA (multi-display adapter). Multi-GPU configurations within Ashes of Singularity's Dx12 environment operate using arbitrary alternate frame rendering (or AFR). The job approach of Nitrous means that tasks go to as many cores as possible at all times, without regard for any special “render core” or “physics core.” Arbitrary AFR & “SLIFire” Just like modern web development philosophy, new APIs push asynchronous processing through the GPU pipeline so that fewer tasks 'wait in line,' thus speeding-up the entire render interval. Despite being a parallel processing unit, the GPU often finds itself queue-blocked by some other job in the pipe – or even by the CPU, which translates draw calls on the older APIs. It's sort of like “parallelizing” an already parallel processor (the GPU). Leveraging Dx12 and its new Nitrous engine, Ashes of Singularity developers Oxide are also promoting the advantages of asynchronous processing. You're not going to get the benefit of Dx12 or the Vulkan stuff until you do more fundamental refactoring. You can take a Dx11 renderer and make it Dx12 pretty quickly. It's not just adding more jobs, it's also about refactoring some of the pipeline, how you deal with the data, how you organize your resources so you can be more parallel, which is how you get the real power of Dx12 or Vulkan. They have similar engines, similar multi-core, multi-threading, multi-job paradigms. “Refactoring the low-end of the engine will work for Vulkan. In the interview with Roberts, the CIG CEO behind Star Citizen told us about the roadmap to Dx12 and steps required to adequately build a game for the new API:

#Benchmark test gpu dx12 free

These new philosophies to task management are what ultimately free the CPU from its burden, allowing more even distribution of processing and enabling a less 'clogged' task pipeline. The Nitrous engine takes this aforementioned “job-based” approach, something we've discussed with Chris Roberts. That's why you'll often see games push the overwhelming majority of their processing to Core 1, showing the most utilization in resmon or other monitoring tools.

As an example, a generic CryEngine game might spawn a thread for physics processing (CPU), one for rendering, one for game logic or AI, one for audio, et cetera, and this approach creates an imbalanced workload distribution that's exacerbated on threads which receive the most intensive job.

Most of the industry's ubiquitous engines, CryEngine included, assigned tasks to specific threads. What is “Explicit Multi-GPU” in DirectX 12?Īshes of Singularity runs on Oxide Games' “Nitrous” 4th-gen engine, which takes a job-based approach to task management. Ashes of Singularity – DirectX 12 Benchmark with R9 390X & GTX 970