Ashes of the Singularity Day 1 Benchmark Preview @ [H]

I don't remember dismissing anything, it was a single comment about your opinion on overclocking - that you might be on the wrong website with that opinion. You realize the name HardOCP stands for Hardware Overclocker's Perspective, right? So you're free to hold that opinion on overclocking, but it's going to be in the minority on a site like this (a site dedicated to and formed on and around overclocking). Hell, I tend to avoid the whole NV vs AMD/ATI debates that pop up, you guys can have at it as far as that's concerned. I'm only here to figure out what's the best bang for my buck. Your comment just struck me as extremely odd to dismiss overclocking so readily.

I actually thought Hardocp stood for 'Hard over-current protection"! lol
 
I completely forgot to mention, until you just reminded me, I saw texture flickering in the benchmark on the side of mountains under DX12 on NVIDIA GPUs, but did not see it in DX11 or on AMD GPUs.



Brent, my 7970 exhibited those artifacts under DX12 but not DX11. The R9 Nano however, did not exhibit any flickering.
 
Brent, my 7970 exhibited those artifacts under DX12 but not DX11. The R9 Nano however, did not exhibit any flickering.

I noticed flickering on the mountains too, particularly noticeable on edges or protrusions. I think they're actually reflections from the lasers
 
Rvenger,
would you mind posting your results with your 7970 and nano? Im just curious if your setup scores any different with that cpu
avg 56fps DX12 1440p lows setting, avg 23fps DX12 1440p crazy 4x
 
Ok so you completely ignore the fact that the SOURCE/ENGINE code was visible to both AMD and NVIDIA and each was able to make specific changes, likely path specific, with those changes being implemented weekly. NVIDIA either squandered every opportunity to make a better showing (not very likely), doesn't have quite the grasp on DX12/lowlevel API (not feeling this either with all their resources), or this is what it is.

Async is a resource that before DX12 wasn't available. This game is good in it shows the promise that it brings even if only for AMD. Conservative rasterization is cool as well and though missing on AMD we will have to wait to see it used and what we can see using it.

No one has ignored that fact, but the developer specifically stated they are not doing vendor specific optimizations (which in DX12 and Async is a must, its not something you can avoid unless we see what we got), they have to be picking one of the vendors automatically by the results we have seen, there is no way in DX11, AMD will outperform on similar tier cards from nV, I would expect to see the same results as we have seen in the past in DX11 as all other games, win some loss some based on resolution, and definitely be behind at lower than 4k resolutions, that DID NOT happen. I think that has a lot to do with them making their engine or porting there engine and working on their engine on Mantle, where at that time they would not have been using a single nV card to develop and make their code, it would been impossible.
 
No one has ignored that fact, but the developer specifically stated they are not doing vendor specific optimizations (which in DX12 and Async is a must, its not something you can avoid unless we see what we got), they have to be picking one of the vendors automatically by the results we have seen, there is no way in DX11, AMD will outperform on similar tier cards from nV, I would expect to see the same results as we have seen in the past in DX11 as all other games, win some loss some based on resolution, and definitely be behind at lower than 4k resolutions, that DID NOT happen. I think that has a lot to do with them making their engine or porting there engine and working on their engine on Mantle, where at that time they would not have been using a single nV card to develop and make their code, it would been impossible.

11vbp3.jpg

Really would love to see DX12 memes
I0SY5MN.jpg
 
Last edited:
Take this next post link and scroll down a little ;)





All tests were run on Core i7-6700K and that is a very fast processor. The tests we did with the AMD FX 8370 which is considerably slower which led us to the conclusion that DX12 Hitman has a major impact on performance ....

The numbers are quite good :) you don't need a translation for that :)
Interesting. So the FX makes insanely large gains but still doesn't catch Intel, even with more cores and trailing by 11% using a 980ti or by as much as 20% while using a Fury X.
Unfortunately, although they mention the 6700k was at stock speed earlier in the test, they not once mention if it was using turbo nor did they ever mention what speed the FX-8350 was. For all we know that FX was running at a blistering 5ghz. Maybe they were at stock speeds, but since they don't say we will never know and this article you linked thus becomes fanboy fodder to fight about.

Results from this site are thus flawed. This is why I want [H] or other well known site to do the test. The test I really want to see is an i5-6600k versus an FX-8350, both at a fixed speed like 4.5ghz while both running the same GPU (preferably a Fury X). This will give some serious data to extrapolate from. It will also eliminate hyperthreading as an x-factor.
 
Interesting. So the FX makes insanely large gains but still doesn't catch Intel, even with more cores and trailing by 11% using a 980ti or by as much as 20% while using a Fury X.
Unfortunately, although they mention the 6700k was at stock speed earlier in the test, they not once mention if it was using turbo nor did they ever mention what speed the FX-8350 was. For all we know that FX was running at a blistering 5ghz. Maybe they were at stock speeds, but since they don't say we will never know and this article you linked thus becomes fanboy fodder to fight about.
Results from this site are thus flawed. This is why I want [H] or other well known site to do the test. The test I really want to see is an i5-6600k versus an FX-8350, both at a fixed speed like 4.5ghz while both running the same GPU (preferably a Fury X). This will give some serious data to extrapolate from. It will also eliminate hyperthreading as an x-factor.

Wow you even have problems with reading simple stuff like numbers it is mentioned that it is a FX 8370 how could you get this wrong ? What you write I can be dismissive of it as you are of the website , you write nonsense thus your conclusion about everything you write here is wrong.

You are not that interested in things because you dismiss the massive gains from DX12 and say AMD still loses, how can you lose while you gained so much? it does have really little impact if the scenarios are gpu bound what speed the cpu is at it could be 10000 ghz and the scores would still be the same ...

Code:
https://youtu.be/QIWyf8Hyjbg?t=2341
 
Found it hard to understand your post quite frankly, but here goes; I am not saying 'async' caters to AMD. I'm not saying DX12 is AMD biased, I'm not saying any of that.

I'm saying, if your code, specifically the part involving asynchronous concurrent execution of commands from multiple queues, runs well on AMD hardware, it will more than likely run badly on NVIDIA hardware.

I'm saying 'async' should be used much more carefully on NVIDIA hardware, and for different use cases. This isn't something I'm pulling out of my ass, this a natural consequence of the low-level nature of d3d12.

The counter argument you are referring to is my mention of overclocking I'm assuming. Okay. 'async shaders' increase gpu utilization on AMD hardware because it hides latency, latency that is inherently more pronounced in GCN than in Kepler/Maxwell BY DESIGN.

Now let's assume that AMD hw (with async in software) is 100% utilized, and NVIDIA hw (with no async software) is 100% utilized. Let's assume they are performing equally. Is one better than the other ? No.

Now let's assume the hardware in question is a Fury X and a 980Ti. A Fury X can overclock by about 10% on average, a 980Ti can do 20%. The 980Ti will be faster. That's all I'm saying. Async isn't magic, you're treating it as such.

You can overcome a lack of 'async', you cannot overcome the lack of conservative rasterization.

http://32ipi028l5q82yhj72224m8j.wpe...ogramming_Model_and_Hardware_Capabilities.pdf

So you don't understand things yet you feel obliged to just type all of this stuff. "Hey dude shot in the dark maybe I typed some things that might actually mean something to you"
Can you honest to god explain to me in English why you would respond to people you don't understand then type all of this stuff ?

Async supposedly is a key DX12 feature and Nvidia the master of the universe when it comes to drivers are still trying to write one after a year or so after seeing the Ashes of the Singularity source code for this.
Supposedly DX12 validation requires Async to be available in hardware and not in software, this sounds like S3 virge Z buffer all over again ...
 
Wow you even have problems with reading simple stuff like numbers it is mentioned that it is a FX 8370 how could you get this wrong ? What you write I can be dismissive of it as you are of the website , you write nonsense thus your conclusion about everything you write here is wrong.

You are not that interested in things because you dismiss the massive gains from DX12 and say AMD still loses, how can you lose while you gained so much? it does have really little impact if the scenarios are gpu bound what speed the cpu is at it could be 10000 ghz and the scores would still be the same ...

Code:
https://youtu.be/QIWyf8Hyjbg?t=2341
Let's all focus on my typo and completely ignore everything else I said about an invalid comparison. My points are completely invalid because someone caught a typo! Oh noes! Let's also ignore the fact that an 8370 is simply a revised 8350 in the first place and nearly the same chip (8 cores, 4ghz, same amount of cache, Piledriver cores). That typo sure made all the difference in these scores.

I mistyped 8370 as 8350, and yet you still ignored the fact that they didn't mention the speeds or settings of either processor in their test. I read that review, and even translated it. You said I have problems with reading yet you glossed over your own article with very poor testing methodology. Please point out in that very article you linked where they stated the processor settings and speeds when they did the CPU comparisons. Without that data, the comparison is flawed and could have been biased towards EITHER side. What if they gave the Intel a boost during that comparison? I guess we will never know because they didn't actually state it.

FWIW, that review mentioned clock speed ONCE. It stated the 6700k at the beginning of the review was running at stock speeds. It made no mention if they did or did not change those speeds in the 6700k vs 8370 test. There was also zero mention of what speed the 8370 was at. All it would have taken was one line saying "both cpu's tested at stock settings", and I would have had zero problem with it. Without that info, I have to go dig up another shit review and cross reference this bullshit test to see if anything if their results are even in the right ballpark.

You tell me that if the game is GPU bound the CPU's speed doesn't make a difference. How can you state that as fact when there is no mention of the speed of the CPU's to prove you right? I'm not saying you are wrong, I'm saying you can't prove you are right in this specific case without every variable documented and isolated.

This is why I want reviews from reputable sites. Crap like this can easily hide bias so fanboy's only see what they want to see. Feel free to link a different website with a proper review. I will be more than happy to accept the results then, even if they aren't results I expected.

computerbase.de translated to English said:
Graphics Card Comparison
The test system is Intel Core i7-6700K the Skylake generation is used, which is operated with the default clock rates....

DirectX 12 on an AMD FX-8370
All previous tests were carried out with the Core i7-6700K and thus a very fast processor.The following testing set with the AMD FX-8370, however, a significantly slower CPU a.And it shows: DirectX 12 has in Hitman quite a large effect.

NOTICE HOW THERE WAS ZERO MENTION OF EITHER CPU'S CLOCK SPEED IN THIS SECTION, OR EVEN IF THE 6700K'S SPEED WAS THE SAME AS BEFORE. IT ALSO IS NOT MENTIONED IN THE GRAPH'S BELOW.

Hitman - CPU scaling to GTX 980 Ti
Information in frames per second (FPS)
  • 1920 × 1080, Max Details:
    • GTX 980 Ti @ i7-6700K @ DX11
      72.5
    • GTX 980 Ti @ i7-6700K @ DX12
      68.3
    • GTX 980 Ti @ FX-8370 @ DX12
      65.2
    • GTX 980 Ti @ FX-8370 @ DX11
      41.5
The FX-8370 is benefiting even the GeForce GTX 980 Ti massive DirectX 12. Hitman runs with DirectX 12 in this configuration to 57 percent faster than with DirectX 11 and nearly reaches the performance of a Core i7-6700K. As in Ashes of the Singularityshows up in the event that with slow processors and Nvidia can significantly benefit from DirectX 12th

Hitman - CPU scaling to R9 Fury X
Information in frames per second (FPS)
  • 1920 × 1080, Max Details:
    • R9 Fury X @ i7-6700K @ DX12
      78.2
    • R9 Fury X @ i7-6700K @ DX11
      74.2
    • R9 Fury X @ FX-8370 @ DX12
      64.9
    • R9 Fury X @ FX-8370 @ DX11
      37.0
Since AMD's DirectX 11 driver in the CPU limit has more problems than the Nvidia puts the Radeon R9 Fury X on the FX-8370, 75 percent even more to. And a disturbing stuttering as under DirectX 11, there is no longer with DirectX 12th

Technical impression
On systems with faster CPU to DirectX 12 worth in Hitman considering the problems currently only on graphics cards with Hawaiian or older architecture from AMD. DirectX 11 running on speedy CPUs with different architectures also fast and trouble-free.

However, the benchmarks show on the FX-8370, how large the potential of DirectX 12 in Hitman is very large. Graphics cards from Nvidia place then too massive and the power of a Core i7-6700K is almost reached. The CPU limit increases significantly, the graphics card decides.

Anyone wishing to use DirectX 12, this can easily adjust the launcher before starting the game.
 
Last edited:
So you don't understand things yet you feel obliged to just type all of this stuff. "Hey dude shot in the dark maybe I typed some things that might actually mean something to you"
Can you honest to god explain to me in English why you would respond to people you don't understand then type all of this stuff ?

I guess I erred on the side of caution, I didn't want to be rude, this is some unintelligible bullshit:
You just made this sound like it was catering to AMD while it is a DX12 feature that Nvidia wants to claim what you are writing here is just something as one of the previous poster said disabled in driver. Now why do we need to believe this ?

You counter the argument by saying were just have to peddle faster to make up for "Async" . Good god man get with the program "were" not asking Nvidia to walk on water ..

DX12 features:
multi-engine support
asynchronous execution

not dx12 features or requirements:
asynchronous concurrent execution of graphics + compute kernels "async shaders"

Is it a useful feature? YES! Will it make or break the DX12 generation? NO!

AMD's asynchronous shaders =/ asynchronous compute

I most certainly can honest to god explain why I would respond to people I have trouble understanding; because I mistakenly assume there is substance behind their unintelligible posts
In the future, instead of replying in the most irritating way imaginable, at the very least take the time to read what was posted in the thread since you last saw it.

I couldn't care less if nvidia is unable to deliver on their driver promises, they could do it through hyper-q, we don't know.

I based my argument on the assumption that it is never fixed, and I can't believe you have the gall to accuse someone of being unable to read
 
and the poster who claimed async doesn't enable the use of otherwise inactive CUs is uninformed.
If you are replying to me, I never said that. Of course it allows shaders/CU's to be used that would otherwise be waiting for other functions to be completed. Just like nVidia does now. Do you actually want people to believe that all of Maxwell's (or any GPU) CU's are in 100% use?
 
If you are replying to me, I never said that. Of course it allows shaders/CU's to be used that would otherwise be waiting for other functions to be completed. Just like nVidia does now. Do you actually want people to believe that all of Maxwell's (or any GPU) CU's are in 100% use?
I can't remember who I was replying to, that's why I didn't quote or specify a name. Someone said something to the tune of 'async shaders provide performance benefits not just from better utilization of the hw", implying the performance benefits come from the ether.

I never said Maxwell's CUs are in 100% use, I said they're better utilized than on AMD hw, as is evidenced by the chasm between dx11 and dx12 performance; nvidia has hyperq working under dx11 at driver level, and even without hyperq (dx12 scenario) it's performance matches that of a Fury X when overclocked to match Fiji's fp32 throughput (2816x2x1500=~ 8.45Tflops), so unless that is a spectacular coincidence that's some pretty solid util/occupancy with no reliance on async.

The Fury X gains 10% with async on vs off.

80321.png
 
I can't remember who I was replying to, that's why I didn't quote or specify a name. Someone said something to the tune of 'async shaders provide performance benefits not just from better utilization of the hw", implying the performance benefits come from the ether.

I never said Maxwell's CUs are in 100% use, I said they're better utilized than on AMD hw, as is evidenced by the chasm between dx11 and dx12 performance; nvidia has hyperq working under dx11 at driver level, and even without hyperq (dx12 scenario) it's performance matches that of a Fury X when overclocked to match Fiji's fp32 throughput (2816x2x1500=~ 8.45Tflops), so unless that is a spectacular coincidence that's some pretty solid util/occupancy with no reliance on async.

The Fury X gains 10% with async on vs off.

80321.png
Sorry. I'm missing your point?
 
Sorry. I'm missing your point?
In short, if we take Fury X performance at 1440p with Async enabled to be representative of best case scenario for amd, and a 980Ti can match this performance at exactly those core clocks that enable it's fp32 throughput to match that of Fiji then utilization of maxwell CUs should be at least on par with that of Fiji, with no async involved

This game is compute limited, order of GPUs in performance charts is basically list in descending order of Fp32 throughput

actually my point is I never said maxwell was 100% utilized and I don't remember who said async shaders perf gain came from something other than better hw util
 
Maybe when we get a vendor agnostic DX12 title to test (looking at you unreal engine) we'll find some peace of mind eh?
Unreal isn't vendor agnostic. Unreal has NVAPI embedded into it. Unity as well. Vendor agnostic would be something like CryEngine V.
 
  • Like
Reactions: Yakk
like this
No one has ignored that fact, but the developer specifically stated they are not doing vendor specific optimizations (which in DX12 and Async is a must, its not something you can avoid unless we see what we got), they have to be picking one of the vendors automatically by the results we have seen, there is no way in DX11, AMD will outperform on similar tier cards from nV, I would expect to see the same results as we have seen in the past in DX11 as all other games, win some loss some based on resolution, and definitely be behind at lower than 4k resolutions, that DID NOT happen. I think that has a lot to do with them making their engine or porting there engine and working on their engine on Mantle, where at that time they would not have been using a single nV card to develop and make their code, it would been impossible.
It's the opposite. The developer Dan Baker (Kollock) stated that they're doing vendor specific optimizations. Both AMD GCN and NV Maxwell run on separate paths. There's a vendorID specific path for NVIDIA.

Kollock also mentioned that they would disable Async by default for NV hardware of it performed more poorly by launch time. I'm not sure if this was done or not.
 
It's the opposite. The developer Dan Baker (Kollock) stated that they're doing vendor specific optimizations. Both AMD GCN and NV Maxwell run on separate paths. There's a vendorID specific path for NVIDIA.

Kollock also mentioned that they would disable Async by default for NV hardware of it performed more poorly by launch time. I'm not sure if this was done or not.

Seems like it, Async shaders disabled by default for me.

My understanding is that ue4 has an entirely separate branch with nvapi embedded, and gameworks too

I quoted Dan baker earlier, pretty sure he said there's no ihv-specific code, did he change his statement?
 
As for DX12, it ain't for Indie games. DX12 requires separate Vendor paths because of the fact that it is a closer to metal API. That means that it requires a large investment in time and effort to properly optimize the code so that it can run as well as possible across a wide selection of PC configurations.

I'd ask that it would serve us well to set these fanboi differences aside and read up on this JOINT AMD and NVIDIA talk on the matter: http://32ipi028l5q82yhj72224m8j.wpe...ogramming_Model_and_Hardware_Capabilities.pdf


As for Asynchronous compute, the term simply means the execution of tasks without an explicit order. Both NV and AMD support this.

What AMD call Asynchronous Shading is what Microsoft call Asynchronous Compute + Graphics. This means that you're doing Asynchronous Compute but also throwing in the concurrent and parallel execution of tasks into the mix. Synchronization points, between differing parallel executing context tasks, are maintained by fences. These fences introduce tiny pauses, idle time, into the frame. This idle time affects both NV and AMD GPUs. For AMD, this idle time is more than made up for by the decreased frame time latency brought on by the parallel (and concurrent) executions of tasks. For NV, this idle time causes a slight loss of FPS when Async is enabled.

Vulkan, won't have this caveat. You see fences were introduced as a means to retain some sort of generalized compliance between both NV and AMD hardware in DX12. AMD hardware doesn't actually require API enforced synch points, whereas NV hardware does. With Vulkan, Asynchronous compute + graphics gains should be even higher for AMD GCN (once the API matures and drivers mature of course).

All this to say that Asynchronous compute + graphics will likely be used for ALL DX12 games when running on AMD hardware whereas different tweaks will be used for the NV paths (tweaks Oxide have already implemented for NV in their code).

This joint talk from AMD and NVIDIA was joined by Dan Baker afterwards because Ashes of the Singularity currently stands as the best example of a successfully implemented DX12 engine.

Now, onto Polaris vs. Pascal.
 
Seems like it, Async shaders disabled by default for me.

My understanding is that ue4 has an entirely separate branch with nvapi embedded, and gameworks too

I quoted Dan baker earlier, pretty sure he said there's no ihv-specific code, did he change his statement?

Wow, there are lots of posts here, so I’ll only respond to the last one. The interest in this subject is higher then we thought. The primary evolution of the benchmark is for our own internal testing, so it’s pretty important that it be representative of the gameplay. To keep things clean, I’m not going to make very many comments on the concept of bias and fairness, as it can completely go down a rat hole.

Certainly I could see how one might see that we are working closer with one hardware vendor then the other, but the numbers don’t really bare that out. Since we’ve started, I think we’ve had about 3 site visits from NVidia, 3 from AMD, and 2 from Intel ( and 0 from Microsoft, but they never come visit anyone ;(). Nvidia was actually a far more active collaborator over the summer then AMD was, If you judged from email traffic and code-checkins, you’d draw the conclusion we were working closer with Nvidia rather than AMD wink.gif As you’ve pointed out, there does exist a marketing agreement between Stardock (our publisher) for Ashes with AMD. But this is typical of almost every major PC game I’ve ever worked on (Civ 5 had a marketing agreement with NVidia, for example). Without getting into the specifics, I believe the primary goal of AMD is to promote D3D12 titles as they have also lined up a few other D3D12 games.

If you use this metric, however, given Nvidia’s promotions with Unreal (and integration with Gameworks) you’d have to say that every Unreal game is biased, not to mention virtually every game that’s commonly used as a benchmark since most of them have a promotion agreement with someone. Certainly, one might argue that Unreal being an engine with many titles should give it particular weight, and I wouldn’t disagree. However, Ashes is not the only game being developed with Nitrous. It is also being used in several additional titles right now, the only announced one being the Star Control reboot. (Which I am super excited about! But that’s a completely other topic wink.gif).

Personally, I think one could just as easily make the claim that we were biased toward Nvidia as the only ‘vendor’ specific code is for Nvidia where we had to shutdownasync compute. By vendor specific, I mean a case where we look at the Vendor ID and make changes to our rendering path. Curiously, their driver reported this feature was functional but attempting to use it was an unmitigated disaster in terms of performance and conformance so we shut it down on their hardware. As far as I know, Maxwell doesn’t really have Async Compute so I don’t know why their driver was trying to expose that. The only other thing that is different between them is that Nvidia does fall into Tier 2 class binding hardware instead of Tier 3 like AMD which requires a little bit more CPU overhead in D3D12, but I don’t think it ended up being very significant. This isn’t a vendor specific path, as it’s responding to capabilities the driver reports.

From our perspective, one of the surprising things about the results is just how good Nvidia’s DX11 perf is. But that’s a very recent development, with huge CPU perf improvements over the last month. Still, DX12 CPU overhead is still far far better on Nvidia, and we haven’t even tuned it as much as DX11. The other surprise is that of the min frame times having the 290X beat out the 980 Ti (as reported on Ars Techinica). Unlike DX11, minimum frame times are mostly an application controlled feature so I was expecting it to be close to identical. This would appear to be GPU side variance, rather then software variance. We’ll have to dig into this one.

I suspect that one thing that is helping AMD on GPU performance is D3D12 exposes Async Compute, which D3D11 did not. Ashes uses a modest amount of it, which gave us a noticeable perf improvement. It was mostly opportunistic where we just took a few compute tasks we were already doing and made them asynchronous, Ashes really isn’t a poster-child for advanced GCN features.

So what AotS does is that both AMD and NV run a general path but vendor ID specific optimizations are thrown into the mix.

Both NV and AMD had access to the source and could submit vendor specific optimizations. So on the whole, AotS is an example of a very well optimized DX12 Real Time Strategy Game. Total War: Warhammer will likely exhibit similar results. FPS shooters, however, should prove to be quite different.
 
  • Like
Reactions: Yakk
like this
Is that REALLY typical for nvidia day in day out OVERCLOCK performance increase? Shit i was under the impression from Internet articles that 3-5 was typical and 10%fps increase on the top side. Of course you add 30% to 100fps its bound to add up quick right?
What are you getting on the 1440p crazy 4x again? Course the gains will be lower since its lower fps to begin with.....Still i see no reason why any nvida user would be upset about this game...NOT with your numbers LOL

That was before Maxwell cards - now you get 10-20% increase on factory overclocked cards and you can throw your own oc on top of it so the total is in 15-30% over reference clocks.
 
That was before Maxwell cards - now you get 10-20% increase on factory overclocked cards and you can throw your own oc on top of it so the total is in 15-30% over reference clocks.

I get up to 41% OC on my Titan X since it's default boost is 1075.

My Fury X gets 5% which I don't even bother with.

Gotta factor all that in...
 
So what AotS does is that both AMD and NV run a general path but vendor ID specific optimizations are thrown into the mix.

Both NV and AMD had access to the source and could submit vendor specific optimizations. So on the whole, AotS is an example of a very well optimized DX12 Real Time Strategy Game. Total War: Warhammer will likely exhibit similar results. FPS shooters, however, should prove to be quite different.


You will not see differences based on type of game genra, that makes no sense. Graphics work load is greater in FPS's, as you tend to use much higher poly models, and higher textures resolutions etc, etc. If anything it should favor AMD not the opposite.

To this fact, DX11 path nV is either running very poor in AOTS, or AMD is just optimized, either way, it shows.
 
It's the opposite. The developer Dan Baker (Kollock) stated that they're doing vendor specific optimizations. Both AMD GCN and NV Maxwell run on separate paths. There's a vendorID specific path for NVIDIA.

Kollock also mentioned that they would disable Async by default for NV hardware of it performed more poorly by launch time. I'm not sure if this was done or not.


The nvapi, is't part of UE4, its part of nvidia's branches.
 
[System]
FullScreen=1
Resolution=2560,1440
VSync=0
HotLoadEnabled=0
UIScale=1.0
CameraPanSpeed=1.0
BindCursor=Always
AFRGPU=0
AsymetricGPU=0
SkipMovie=0
AutoSave=1
HealthBarsAlways=0
SteamAvatars=1
CameraPanAlt=0
ForceStop=0
EmulateFullscreen=0
AsyncComputeOff=0
AllowHooks=0

Did yours default to a 1?

In any case your setup is running a good 30 fps higher than the [H ] article had...117 vs 85..I wonder why?

Don't forget to set buckets to 11.
 
Now, are the folks here that have Ashes enjoying it? Looks like it is just as playable on either IHV solution for a given hardware level. A few FPS, particularly in this game (this is no FPS shooter, twitch type game) looks to be meaningless. For me I can seeing playing at 30fps without issue.

Does this game represent all the future DX12 title performance spread - :woot: - I don't think so. Will be interesting through to get some data points comparing CPU usage and performance between DX11 and DX12. AMD cpu testing would be interesting to a certain exent.
 
Now, are the folks here that have Ashes enjoying it? Looks like it is just as playable on either IHV solution for a given hardware level. A few FPS, particularly in this game (this is no FPS shooter, twitch type game) looks to be meaningless. For me I can seeing playing at 30fps without issue.

Does this game represent all the future DX12 title performance spread - :woot: - I don't think so.

Waiting on Hitmen review.
As far as I can tell The game is NOT done yet. For fucks sake an I use an AMD card and in DX12 the texture corruption is pretty bad (imagine checker board patterns) on the ships flying around. Maybe its only effecting us with older cards? Doesnt matter I would have to play it in DX11 which is BS. Something else i have noticed is with my cpu the absolute highest frame rate i have managed is 64.(Someone with an nvidia card had almost 120 fps lol) Thats with everything turned to lowest settings including resolution. I feel like the game is somehow Gimped on my cpu, Or my video card is limiting my ability to get higher avg frame rates. Know ones really buying it cause the game still isn't done yet.

Edit: That and any AA in the game is totally foobar...Doesn't matter what level i pick it doesnt change the fps one bit nor does it do anything aside from add a bunch of corruption in the lower right hand side of the screen. DX11 might be ok i guess....but whos buying this to play DX11? Know one...And sure enough know one is really buying it. This is more of a half working tech demo IMO

Edit2. DX11 seems to work great..No artifacts and AA looks good. DX12 is visually broken for my card.
 
Last edited:
If AC is disabled then it's because the hardware is faulty. Probably due to a bug. The problem with this is that usually you can get around this by using the CPU, but that would be against the point of having Async Compute.

Ashes of Singularity developers have been dealing with Nvidia for a while on fixing this issue, and have even debated disabling Async Compute. They aren't ever going to be able to close the performance gap. Not without Gameworks, and even then it might not be enough.


If DX12 is a performance loss for both AMD and Nvidia, then yes it wasn't done properly. The people behind the Talos Principle said it themselves with Vulkan. If the game wasn't specifically built to utilize the API, then it won't see any benefits.

As for AMD's involvement, I'm sure Nvidia can tweak the drivers just like how AMD had to tweak there's after a Gameworks game was released. Except that I don't think it's possible for Nvidia to do that with DX12.


I think Nvidia will get Async Compute working for Pascal. They have the engineers to do it.


You aren't getting it. This has nothing to do with the quality or quantity of NVidia's engineers. This has to do with BUSINESS. If they have pascal all designed and components of that are already in production, do you have any idea as to the BUSINESS COST of having scrap those pieces already in production, go back and re-engineer the pascal plans, make sure it works, and then start the whole process over again? It would set them back MILLIONS, both in time cost, the people they paid, what they already did, and the sales they still will have gotten from Pascal even without async. It would be business SUICIDE.

Adding async isn't like sticking a stick or ram into a motherboard - there are complicated engineering feats that need to be handled, tested, verified, etc. The integration isn't plug and play dude.

Even if they added it to pascal, that would mean delaying pascal for 2-3 years, and likely scrapping Volta. And that just can't happen. No, they got caught with their pants down. And to correct it, from a business standpoint, they are better off selling Pascal (and likely Volta) as is, and given the R&D time, working on a hardware async solution for the next card past Volta, so that they can play catch up.
 
You aren't getting it. This has nothing to do with the quality or quantity of NVidia's engineers. This has to do with BUSINESS. If they have pascal all designed and components of that are already in production, do you have any idea as to the BUSINESS COST of having scrap those pieces already in production, go back and re-engineer the pascal plans, make sure it works, and then start the whole process over again? It would set them back MILLIONS, both in time cost, the people they paid, what they already did, and the sales they still will have gotten from Pascal even without async. It would be business SUICIDE.

Adding async isn't like sticking a stick or ram into a motherboard - there are complicated engineering feats that need to be handled, tested, verified, etc. The integration isn't plug and play dude.

Even if they added it to pascal, that would mean delaying pascal for 2-3 years, and likely scrapping Volta. And that just can't happen. No, they got caught with their pants down. And to correct it, from a business standpoint, they are better off selling Pascal (and likely Volta) as is, and given the R&D time, working on a hardware async solution for the next card past Volta, so that they can play catch up.


When was PS4 design, Xbox one designs and DX12 start in development?

Best of my knowledge, PS4, Xbox one were ready in end of 2012 early 2013, for their end of 2013 launch. Now lets see concurrent shader execution is part of Xbox one and dx11.x. That time line is 3 years to get Pascal ready with concurrent execution? Is that enough time for you? What did you say 2 to 3 years?

See what I'm saying, don't try to fit your story with a narrative which you have created, it will fit every time.

And yes concurrent execution of compute and graphics queues work fine when using cuda for compute and Dx for graphics, it is not activated with direct compute with and dx, which is the problem.
 
I would have been interested in seeing some benchmarks for the 380/x vs 960 vs 970, and the 360 vs 370 vs 950.

Im thinking async on the 360 and 380 could close the gaps on their higher counter-parts like the 370/950 and 970...
 
You aren't getting it. This has nothing to do with the quality or quantity of NVidia's engineers. This has to do with BUSINESS. If they have pascal all designed and components of that are already in production, do you have any idea as to the BUSINESS COST of having scrap those pieces already in production, go back and re-engineer the pascal plans, make sure it works, and then start the whole process over again? It would set them back MILLIONS, both in time cost, the people they paid, what they already did, and the sales they still will have gotten from Pascal even without async. It would be business SUICIDE.

Adding async isn't like sticking a stick or ram into a motherboard - there are complicated engineering feats that need to be handled, tested, verified, etc. The integration isn't plug and play dude.

Even if they added it to pascal, that would mean delaying pascal for 2-3 years, and likely scrapping Volta. And that just can't happen. No, they got caught with their pants down. And to correct it, from a business standpoint, they are better off selling Pascal (and likely Volta) as is, and given the R&D time, working on a hardware async solution for the next card past Volta, so that they can play catch up.

Yeah I'd imagine they'd still be ok even with the slight async hit. Redesigning vs running with what they have (whatever they have...) is probably the easiest decision I could imagine. Even if they don't have async it's not like they are missing out on much performance and no image quality difference.
 
AMD's state of the art DX12 Graphics


IMG_20160403_160324300_zpsmo53y1qj.jpg


IMG_20160403_160338128_zpsdlbd8ido.jpg


IMG_20160403_160553211_zpsf5ixxzdm.jpg


IMG_20160403_160610255_zpsnkswwuch.jpg


To bad Nvidia cant do DX12 graphics like this!:) This is with latest driver before anyone asks
 
I've read a lot about Async compute, but not that the visual quality is different between GPUs. Can you post comparative pictures from Nvidia GPUs?
It was a Joke TBH...not sure about all of them but the first one you can see checkerboard flashing artifacts (Its NOT supposed to look that way)..IF i get time, I will show how it supposed to look using DX11 mode
 
It's enabled on all gcn gpus, but like I said, needs to be tuned for every single one :p

Hence IO interactive saying it's hard to tune and not worth the effort

You both forget that DX12 is not supported by 79xx or 280 cards which are essentially the same. Its very clear though in BF4 on my old core I7 980X and crossfire 7970's .Mantle is smoother and faster than DX11 especially at 120 Hz.
 
You both forget that DX12 is not supported by 79xx or 280 cards which are essentially the same. Its very clear though in BF4 on my old core I7 980X and crossfire 7970's .Mantle is smoother and faster than DX11 especially at 120 Hz.
The fuck its not! It most certainly IS supported
 
Back
Top