11-13-2015 11:55 AM
11-25-2015 05:26 PM
"gunair" wrote:
Hello from Germany,
a few days ago, nvidia released their Gameworks VR and Designwoks VR SDK - Final versions 1.0!
And Epic Games has announced support for GameWorks VR features (with SLI VR !!!) in an upcoming version of the Unreal Engine 4.3.
I hope, Unity3d (I'm working with) is doing the same very soon!
🙂
11-25-2015 09:15 PM
11-25-2015 11:22 PM
11-25-2015 11:56 PM
11-26-2015 01:05 AM
11-27-2015 02:22 AM
"galopin" wrote:
And about hurting sells, we are talking about VR, the market is still to be proven
11-27-2015 06:42 AM
"LogicalIncrements" wrote:"MichaelNikelsky" wrote:
VR SLI is quite different from normal AFR-SLI. AFR-SLI does not work with VR or any application that requires a sync-point.
The way AFR-SLI works is by emitting all the commands to render a frame to one GPU and as soon as all the commands are emitted it switches to the next GPU for the next frame. If you introduce a sync-point, like it is done for VR to control latency, you would basically wait for the first GPU to finish rendering the frame before continuing with the next frame. This makes AFR-SLI pretty useless since the first GPU is idle after that anyways so you don´t need to use the second GPU at all. Even when managing to render the first eye on one GPU and the second eye on the other GPU you would still be limited by the syncing since you need to wait for the second GPU to finish rendering. However, not using syncing is even worse since you might end up with different frames displayed on the left and right eye.
VR-SLI works (assumingly) completely different since it basically sents the rendering commands to both GPUs in parallel and just gives them different viewports/cameras/what ever you call it. This works even when using sync-points (although I would argue that it is not longer necessary).But unlike AFR-SLI, which pretty much works without doing anything in the application (unless the application does something stupid of course...) the application needs to be aware of the VR-SLI feature so it only does one rendering pass for both eyes and feed the GPU with all the necessary buffers.
Hope this makes it a bit clearer.
Thank you for this awesome explanation, Michael! It makes much more sense to me now.
11-27-2015 08:50 AM
"CogSimGuy" wrote:
I'm not sure this explanation is true...if you read the nVidia white paper on VR SLI they talk of broadcasting the draw calls to both GPUs simultaneously however they also talk of the requirement to blit one "eye" frame back over to the other card before pushing to the VR device which imposes a slowdown.
11-27-2015 07:43 PM
"MichaelNikelsky" wrote:
About the slowdown.....well, for normal stereo rendering we are seeing a near perfect factor of 2 performance increase with no additional perceived latency, so the required blit is very cheap.
11-28-2015 01:18 AM
"galopin" wrote:
This is not totally true,