Serious Sam VR mGPU AMD RX 480 Follow Up @ [H]

FrgMstr

Just Plain Mean
Staff member
Joined
May 18, 1997
Messages
55,532
Serious Sam VR mGPU AMD RX 480 Follow Up - We all know that Virtual Reality gaming is still in its infancy and we have seen lots of great gaming moments already. As the content moves forward so is the way game developers are taking advantage of the technologies available to them to make our VR game run better enhancing our VR experience. Croteam has mGPU working now AMD's RX 480!
 
What about Fury X CF?
First off, it is not CrossFire, it is mGPU.
Second, I do not have two Fury X cards. I had to buy the one I am using.
Croteam did not mention anything about Fury X working, but I will ask.
 
Thanks. I only know that Fury (X/Nano/Non-X), 390(X) and R9 290(X) are listed as being "VR Ready Premium" at Radeon™ VR Ready | AMD

I'd test with my Radeon Pro Duos, but I haven't jumped into getting a headset quite yet. Just reading great reviews like these while I wait for more games.
 
I wonder how the 470 and 460 compare using mGPU. Could be a low budget VR winner?
 
So as a generic statement, I'm understanding that if a VR game does not support or have "mGPU" a Crossfire or SLi set up will not utilize both cards???

Sorry, but I do not have a VR set up as of yet. Just trying to get a feel for the tech and decide if it's worth it at this early stage.
 
So as a generic statement, I'm understanding that if a VR game does not support or have "mGPU" a Crossfire or SLi set up will not utilize both cards???

Sorry, but I do not have a VR set up as of yet. Just trying to get a feel for the tech and decide if it's worth it at this early stage.

Not in the way mGPU is supposed to work. From what they are alluding too, mGPU allows each card to run 1 display in VR. Instead of CF/SLI that normally combines both cards rendering on a single display
 
So as a generic statement, I'm understanding that if a VR game does not support or have "mGPU" a Crossfire or SLi set up will not utilize both cards???

Sorry, but I do not have a VR set up as of yet. Just trying to get a feel for the tech and decide if it's worth it at this early stage.
Unless the game/application is programmed to support mGPU, it will not use it at this time.
 
This is great. This is honestly what i've been waiting for for VR.

One GPU per eye. Need to see more and more of this happening

Disappointed we haven't seen more of VR SLI yet. Feels like there's more potential here for multi-GPU configurations with VR than there ever was with the myriad issues hounding standard XF/SLI.
 
I assume this is only working with AMD cards currently, using LiquidVR?

Also, I didn't see it mentioned, but can you use two dissimilar cards for mGPU or only identical?
 
I would love to see some sort of subjective analysis on IQ for the higher-end GPU configurations that are managing to get a lot of frame time headroom left over. A lot of content seems to benefit from manually cranking up the eye buffer size (supersampling), so it would be cool to see in what cases you can get a significant qualitative difference between, say, a 1070 and a Titan in cases where both are already managing 90fps at "highest".
 
I would love to see some sort of subjective analysis on IQ for the higher-end GPU configurations that are managing to get a lot of frame time headroom left over. A lot of content seems to benefit from manually cranking up the eye buffer size (supersampling), so it would be cool to see in what cases you can get a significant qualitative difference between, say, a 1070 and a Titan in cases where both are already managing 90fps at "highest".
How would you like that measured objectively?
 
The objective way to do it would be to scale the supersampling for each card respectively with the aim of having maximum possible sampling while keeping the frame times consistently below the reprojection threshold. This might also showcase bottlenecks with the differing VRAM sizes as the eyebuffer sizes can get rather large, which would also impact multi-GPU where one eyebuffer is having to get copied across the bus when it's completed. Certain content benefits more from supersampling than others depending on game engine, assets used, etc (text legibility being a big one), so that would leave room for you to add your subjective assessment as to whether the improved fidelity had value on a game by game basis.
 
The objective way to do it would be to scale the supersampling for each card respectively with the aim of having maximum possible sampling while keeping the frame times consistently below the reprojection threshold. This might also showcase bottlenecks with the differing VRAM sizes as the eyebuffer sizes can get rather large, which would also impact multi-GPU where one eyebuffer is having to get copied across the bus when it's completed. Certain content benefits more from supersampling than others depending on game engine, assets used, etc (text legibility being a big one), so that would leave room for you to add your subjective assessment as to whether the improved fidelity had value on a game by game basis.
Yeah, that is not going to happen. We are moving away from apples-to-oranges comparisons. If I was doing one review a week on one card then I could go that route, but the fact of the matter is that is simply more depth than is needed in the VR world at this moment IMO.
 
Negative. I must have been half asleep and didn't see the link. :/

Read it now though. Very interesting! Thanks for the great work Kyle. I'm extremely excited to see LiquidVR & VR-SLI working in titles. Especially such a demanding and fun title like SS! I tried Nvidia Funhouse a while ago with my 1070 SLI and found VR-SLI not to be working properly. One GPU was around 70% utilized while the other was @ 20% utilization. Looked to me as if the 2nd GPU was just picking up the PhysX workload and not one eye to each GPU as VR-SLI was intended, asI would expect to see equal GPU use from both cards. I may have to revisit it though.

Did you get the same result with VR-SLI Kyle or was it working properly for you in Funhouse or any other game? Also is there a certain way to activate VR-SLI on the Nvidia control panel, or do you just enable SLI as we normally do?
VRSLI is NOT working in SSVR as this time, but devs say it will in the future. As covered in this article, and linked as well, yes VRSLI works in Funhouse. mGPU for both AMD and NVIDIA has to be specifically coded for in the VR game; you don't have to enable anything on your end for AMD. I don't remember if I had to enabled SLI for Funhouse or not.
 
What is Async Reprojection?

Currently showcased here:
http://developer.amd.com/tools-and-sdks/graphics-development/liquidvr/

...but not sure for how long, so will re-post:

Asynchronous shaders have the ability to perform compute operations concurrently, i.e. in parallel with rendering tasks. This is a key capability of the new generation of graphics APIs, including Mantle, DirectX® 12, and Vulkan™. AMD’s Graphics Core Next (GCN) architecture, currently the only architecture to support this functionality, was designed to efficiently process multiple command streams in parallel.



In the context of virtual reality, when rendering images to virtual reality headsets, low latency is critical to avoid nausea and motion sickness. One of the challenges associated with reducing latency is ensuring that the GPU has access to the latest head position information when it is rendering each frame. Even if the information is fresh when rendering begins, it may already be stale by the time the frame completes.

Asynchronous Time Warp addresses this issue by obtaining fresh head tracking information after each frame finishes rendering, using it to warp the frame to appear as if it was rendered from the new viewpoint. This warping makes use of a compute shader, and needs to be executed with high priority to avoid adding latency back into the pipeline. Executing it asynchronously allows latency to be minimized and helps eliminate stuttering, since context switching and pre-emption overhead can be avoided.
 
Back
Top