This resulted in a solid performance boost in GPU bound scenarios, but we gained nothing in cases where we were constrained on the CPU. We discovered many similar problems and we worked on this simple solution for a couple of weeks and actually managed to fix almost all of the rendering issues. This can be fixed by setting affinity to both GPUs before any render to texture that needs to be read on both GPUs. Then we found out that we read from a surface that is empty on one GPU because we only rendered to that surface on the other one.

Easy fix – just forget texture states after rendering each eye. binding a texture on one GPU prevented us from binding the same texture on the other one because it was already marked as bound. The root cause of the incorrect eye display was that our engine wasn’t affinity-aware – e.g. One eye was displayed perfectly, while the other was completely black or just garbled. Compile, run, but unfortunately it did not work. After rendering the scene on the other GPU, it is copied to the first one and submitted to the VR compositor. After adding such support to the engine, we added the required calls so that the first rendering pass goes to the first GPU and the second rendering pass goes to the other GPU. Initially, we applied the same Keeping Things Simple philosophy to Affinity MGPU VR rendering as we initially did for single GPU and decided to do it in two separate passes. Affinity MGPU can either be done in one pass or with a separate pass for each eye, in which case we reap the GPU side benefits while the CPU workload stays the same. We wanted to add LiquidVR Affinity Multi-GPU rendering support to our engine because two GPUs can render the two eye views in almost half the time compared to a single GPU and this would greatly reduce our GPU bottlenecks. This is obviously what we want to have in the end, but the downside is that it’s often a lot harder to implement in an existing engine as it requires changing a lot of code.

Taking a single pass approach means we only run the rendering once per frame, for both eyes simultaneously, which significantly decreases CPU overhead. The more efficient approach would be to render the entire scene in one pass.

The problem with this approach is that it results in bad performance because it doubles the draw calls, but on the other hand it gives you a correctly rendered VR scene without too much effort. You’d usually do this by simply rendering the entire scene twice with different matrices for each eye. Similarly, when you first need to add virtual reality rendering support to an existing game engine, you want to do it as quickly as possible just to be able to see the results and then decide where to go from there.

You end up purchasing the most expensive pair of headphones that you should have bought in the first place. Inevitably, the cable is damaged and you’re back in the store – you already spent money on this and you don’t want to break the bank on headphones. You don’t want to spend too much money so you settle for a nice inexpensive wired pair with good sound but an inexpensive cable. Let’s say you’re in a store deciding which headphones to buy. This blog is guest authored by Croteam developer Karlo Jez and he will be giving us a detailed look at how Affinity Multi-GPU support was added to their game engine.

Vr supported gpu