Thats not really a difference Xfire and SLi had options for SFR in older Dx's too back all the way to Dx9I think amd covered that too specifically noting the difference between Dx11/Dx12
Thats not really a difference Xfire and SLi had options for SFR in older Dx's too back all the way to Dx9
So, we need to hope that some developers out there are not rushed by their publishers and show more dedication to a 5-7% marketshare than they do for the whole PC gaming community when they do their usual console port - allegedly optimized for PC, when sometimes you even get Press "Triangle/Circle/Box" to continue? Hm, hope dies last.
If Civ VI engine is same continuity as the previous engine, I'm quite sure they will, they supported even SFR already in Civ:BE (Mantle-version)Well it does happen from time to time. I'm actually interested to see if the next Civilization game does M-GPU in the engine again like they did with Civ V.
Regards,
SB
Well it does happen from time to time.
You can totally do explicit mGPU on NVIDIA cards. We've seen that first-hand with AotS, and by and large it even works well.Yeah I was hoping to also see Nvidia focus on the benefits of Dx12 for multiple GPU rendering. Unfortunately it appears they've done the stupid thing and doubled down on AFR through the driver along with reinforcing the need for physical bridges.
But since that doesn't lock you into their eco-system, it's not something they'd want to promote.
Regards,
SB
You can totally do explicit mGPU on NVIDIA cards. We've seen that first-hand with AotS, and by and large it even works well.
NVIDIA's position is basically that implicit mGPU probably isn't going away any time soon, and that it's handy to be able to keep mGPU traffic off of the PCIe bus. But the use of SLI bridges is not mutually exclusive from supporting explicit mGPU.
There's a question with explicit multi GPU that has been stuck in my mind for a while now but haven't come around to ask someone yet... Why it seems hasn't anyone experimented with this on DX11?Screen space techniques and temporal reprojection do not prevent multi-gpu techniques. AFR doesn't work well with techniques using last frame data, but who would want to use AFR in DX12? AFR adds one extra frame of latency. AFR was fine when developers could not write their own custom load balancing inside a frame. The DX9-11 driver had to automatically split workload between two GPUs and splitting odd/even frames worked best with no extra developer support needed. This was a big compromise.
I would have included some multi-gpu and async compute thoughs in my Siggraph 2015 presentation, if I had more time. With GPU-driven rendering, it is highly efficient to split the viewport in half and do precise (sub-object) culling for both sides to evenly split the workload among two GPUs. This is much better than AFR.
Temporal data reuse is a very good technique. Why would anyone want to render every pixel completely from the scratch at 60 fps? The change between two sequential images is minimal. Most data can/could be reused to speed up the rendering and/or to improve the quality. It is also a well known (and major) optimization to reuse shadow map data between frames. It's easy to save 50% or more of your shadow map rendering time with it. AFR chokes on this optimization as well. Sure you can brute force refresh everything every frame if you detect AFR, but this makes no sense. DX12 finally allows developers to use modern optimized techniques and make them work perfectly with multi-GPU. There is no compromise.
Until I read the footnotes I discount GoW. The rest seems reasonable although deceptive for Hitman given it's issues you guys say in chapter 1 versus 2.
It's worth noting that custom SFR doesn't have to be 50/50 split. You can dynamically adjust the split based on GPU performance differences. Works much better in situations when you upgrade your GPU (GTX 970 + GTX 1080 for example). Or with a fast iGPU + entry level DGPU.I think amd covered that too specifically noting the difference between Dx11/Dx12
DX11 shared resources (between two devices) have huge limitations:There's a question with explicit multi GPU that has been stuck in my mind for a while now but haven't come around to ask someone yet... Why it seems hasn't anyone experimented with this on DX11?
I mean you can fire up two D3D11 devices just the same as D3D12 devices. I realize performance might not be quite up there with DX12 but is hit just so big that no one even bothered to try?
These tests were performed using the High preset.Same for AMD probably. The game has an Ultra preset. And an HBAO+ option, where NV has the lead.overclock3d(where that image comes from) did test it at 4k and found Fury X double-digit faster.
http://www.overclock3d.net/reviews/...son_16_4_2_-_directx_12_performance_boosted/5
And also 4k (appreciate they are limited in their testing),These tests were performed using the High preset.Same for AMD probably. The game has an Ultra preset. And an HBAO+ option, where NV has the lead.
These tests were performed using the High preset.Same for AMD probably. The game has an Ultra preset. And an HBAO+ option, where NV has the lead.
And also 4k (appreciate they are limited in their testing),
which is not really the best resolution to test these IMO.
Cheers
I am saying it is better to use 1440p with uncapped frames, along with showing 4k.pcper's review of 1080 uses high too, though it does show 980Ti in lead at 1440p while being equal at 4k.
As for HBAO+ option, I'm not sure if it's there but giving nvidia the lead wouldn't be a surprise.
4k high is better than 4k ultra surely if you're using that reasoning.
overclock3d(where that image comes from) did test it at 4k and found Fury X double-digit faster.
http://www.overclock3d.net/reviews/...son_16_4_2_-_directx_12_performance_boosted/5
Though the problem with such upto benchmarks is that the game can favor different cards in different conditions, for instance I looked at a benchmark of Tomb Raider pitting Fury X against Titan X and while Titan X was mostly faster the video still had parts where Fury X was consistently around 10% faster.