Ashes of Singularity: DirectX 12 Benchmark II review

Game reviews 126 Page 12 of 12 Published by

teaser

Conclusion

Final Words

Huge proper to Stardock for being the first to release an actually benchmark that no only is DirectX 12 compatible, but also up-to snuff with some of the hippest features like explicit mode Multi-GPU rendering. Currently there are concerns though, in CRAZY quality settings we the Radeons crawl up in performance so high that it makes our eyebrow's frown. At HIGH quality settings however we see a more balanced picture.  The second issue is that Radeon cards are locked in a VSYNC like state on display output. Internally in the game engine the framerates might be even reach 200 FPS, and such numbers are the output results from the benchmark. Unfortunately later in the rendering pipeline the output engine switches to VSYNC. We have confirmed this visually and backed that up with FCAT. Meaning your FPS will max out at 60 FPS or whatever your locked refresh rate is. That last measurement with FCAT is the right one as what is measured inside the game engine, is indicative only. 

Explicit mode Multi-GPU rendering then - it is just crazy to see a Radeon R9 Fury and a GeForce GTX 980 sit next to each other in the PCI-Express slots and actually working together. That feels a little dirteeeeh, ... but it surely is fun!  Now let me overlay a single GPU versus the two explicit mode Multi-GPUs:

Plot-both

Single GPU versus the two explicit mode Multi-GPUs. 

As you have been able to see, with DX12 managing multi-GPU rendering, micro-stuttering is back in full effect. I do not see a quick solve for that from Microsoft's side really. If the behaviour stays that way, explicit multi GPU mode might not become a popular thing for the real enthusiast. However for the average joe that wants mix some cards just for fun, it'll be exactly that, pure fun. The reality also is that micro-stutter is a damn hard thing to see if you do not know what to look for. Then scaling overall of course is rather limited. 

I've created a 30 second run recorded with FCAT (no audio recorded), this is rendered and saved RAW (13GB per 30 seconds) and as good as it gets output wise on YT. You will agree with me (I hope) that you're not looking at a bad rendering experience but there's quite a bit going on.
 

Above a GTX 980 and GTX 980 Ti rendering in explicit Multi-GPU mode.


For those of you that wonder, the left side colors flashing are FCAT color tags, each rendered frame gets one color assigned in a strict sequence. Obviously you can see screen-tearing with VSYNC off in this video, hence it looks worse then it is with VSYNC/FreeSync/Gsync enabled. 

That's it for this article, I decided to cut off the game test until the SYNC issue is solved on AMDs side. The good news is this. Last week I presented this behaviour to AMD. AMD has successfully identified the issue. Radeon Software 16.1 / 16.2 does not support the DX12 DirectFlip, which is mandatory and the solve to the specific VSYNC situation we see with radeon cards. For Nvidia it seems that ASYNC compute shaders are not working and we have to wonder as to why anno February 2016 still is the case ?

AMD intends to resolve this matter in a future driver update, after which we'll update this article. The same goes for Nvidia with ASYNC compute support, or better yet the lack of it.

Cheers you guys!

H.

Update February 26th 2016

In response to an article posted on Extremetech posted by Joel HruskaI am adding the following. Thank you for your informative post, we do hope we are wrong. Two quick things first. ET did not bother to contact us about their findings. They also failed to ask permission to republish our charts and quotes while taking some specific words and lines out of context to proof a point. Ok, whatever. But, if we are wrong we are wrong .. we're all humans right.

However our findings are not wrong. FCAT remains a very reliable tool if not one of the best measurements and analysis applications available, even AMD will back that up. True, for DX12 there will need to be some changes as the output rendered with DX12 can be different. The FCAT analysis shows behavior on the output side of AMD cards that shouldn't be happening. So a  valid question raised is this, is FCAT analyzing the data wrong ? And while they claim that to be the case, I find the answer to be more complicated as they explain. I am not a programmer hence (and gosh I do not wish to be one) I have to deal with findings and results on a more basic level. My words to AMD have been: look at the screen and see what is happening visually with your eyes, you can perceive and see what is going on.

The claim is that FCAT is analysing wrong. OK so let's take FCAT out the equation then, that is simple enough to do:

Below you can find a 30 second capture of the Radeon R9 Fury. This recording is what you see on screen, the recording is not tainted by any form of analysis, it just frames being fired off to the framegrabber. The colored bars on the right are FCAT labels that's all, not created by a 3rd party overlay but created by the Ashes game itself (Stardock implemented a color sequenced labels compatible with FCAT inside the game-engine that is activated). So no external tools are used here:
 


Above the output recording (in-between display connect or and monitor) of the Radeon R9 Fury, how would you describe it ?
Does that seem to be synced, do you see screen tearing ? The output simply differs from the results.


Have a look and see what is happening for yourself, the recording displays what's going on on your monitor, you can visually perceive the same information. Compare to the upper video with the GeForce card capture. If that isn't at the very least something we can describe as VSYNC like behavior at 60hz, then I don't know what is. Again, there's no FCAT involved here other that we color the frames with a color label to identify them.

Extremetech - Guru3D is wrong. FCAT records output data, but its analysis of that data is based on assumptions it makes about the output — assumptions that don’t reflect what users experience in this case.

In herein lies a difference of opinion, because that very same output data in this specific case is similar to to what we observe on screen, on the monitor. Thus the FCAT analysis is matches up with what you can see with your own eyes. I mean, that much we have just shown you with the recording. 

That said, we look at the both the produced results and the analysis from FCAT. So let me rephrase my wording at least a bit, there no definitive answer for either methodology used, other then we feel they complement each other. What we visually see with our eyes does match what FCAT is showing - hence to me that is more conclusive. Others might disagree and that is fine. The video above shows the behavior we note rather clear. We'll gladly leave it up-to the devs and end-users to decide what factor weighs in the most. We would not have published our results if we would not have some concerns as to what we visually can see and measure. Hence we stand behind our results. Could we be wrong? Oh sure, definitely possible, I am human and could be 180 degrees completely wrong as the level of programming involved exceeds my knowledgebase.

Time will tell. But we'll still publish what we observe, as to not publish and withhold results and findings like we ran into would be the most subjective thing any website could do. We are not pointing fingers at Stardock, we are not pointing fingers at AMD - we mereley publish our findings. With odd results we raise questions, plain and simple.

Share this content
Twitter Facebook Reddit WhatsApp Email Print