I don't recall the issue being answered satisfactorily by Futuremark let alone been invalidated. In fact, 3dmark tarnished itself by using the lowest common denominator in order not to show up Pascal's shortcoming in async compute after their tessellation nonsense..
So let's say that your the vendor whose hardware doesn't fully support asynchronous hardware (and equally as importantly not in the same was as the ACEs in GCN work in the consoles). But instead you are able to do some fancy scheduling work which you off-load to the CPU.
So what happens to CPU utilization between Async-On and Async-Off with both vendors?
As I said before, futuremark can't even publish a benchmark without it being ok'd by AMD and Nvidia, etc. Well, they could I guess, but don't think everyone would continue to endorse it.
The point is exactly to estimate the middle of the road dx12 game.
.......
That is a load of nonsense.
Mahigan did a very good job explaining how it all works under the hood.
And his post were very informative and verifiable.
I kind of miss posts like that.
bonobos said:AMD isn't in a good position to be pulling out like they did with Bapco. Its unfortunate that they got the short end of the stick again. It will be interesting to see how 3dmark behaves wrt async compute once Nvidia's Volta comes out.
AMD isn't in a good position to be pulling out like they did with Bapco. Its unfortunate that they got the short end of the stick again. It will be interesting to see how 3dmark behaves wrt async compute once Nvidia's Volta comes out.
Mahigan posted a broad mix of informative info together with rubish stuff. It's impossible to say whether he didn't know better or he was trying to drive his agenda. Seeing in how many forums he posted, where people don't have a lot of knowleadge and absense in forum like b3d with a lot of developers, it seems to me more like an agenda too.
AMD would be able to criticise if something about futuremarks implementation would be bad. So Timespy is evil, because AMD gains 10% but Nvidia also gains 5%, but what about other implementations like Hitman where AMD said it's a very good implementation, but the devs said they only got 5-10% more speed with async. Seems Hitman devs also got payed by Nvidia?
Ancually, Mahigan was the first who pointed out Maxwell(and Pascall) can't do Async, and guess what, he was correct. This was at least half year before DX12 was even released. At this time Nvidia had slides with Async Compute listed as fully supported on Maxwell and everybody believed it. Nobody else knew or posted anything, so for me this guy looks like one of the most non-biased guys who at least knows what he is talking about.
I never noticed he had an agenda. That is something some people look for because he has detailed information. And please give some explanation about rubbish ?
And even then in the hypothetical situation that he made a mistake, everybody once in while makes mistakes.
But it is a tendency here and on other forums that brand based hooligans will do anything to discredit someone.
I should note, that making predictions are not facts.
It is what they are. Predictions.
I don't really play GOW4...I appreciate it on a technical level, but the gameplay never really drew me in. Unlike Doom, where I both appreciated the technology and enjoyed the heck out of the gameplay. Anyways. I'll probably just benchmark it at both the high and the ultra preset.
That is a load of nonsense.
Mahigan did a very good job explaining how it all works under the hood.
And his post were very informative and verifiable.
I kind of miss posts like that.
Besides, asynchronous compute on the pc came to be after mantle which is co designed by AMD.
And the interesting part is that the gcn architecture from AMD actually had that asynchronous compute capability before the consoles, yes since the first version of gcn.
That is around the time of 2011,2012.
Pascal uses a hybrid driver software/hardware model to do async compute.It was plainly obvious to me that Mahigan had an agenda. This guy was literally all over the internet on loads of tech forums preaching the same thing. As someone stated though, he made a point to stay away from the heavy tech forums like B3D which have lots of developers and industry professionals that will call him out on his crap. That's not to say that everything he said was wrong however. He was on point quite a bit as well.
But in hindsight, some of the things he said are now known to be wrong; the biggest being that Pascal doesn't have asynchronous compute.
I can remember that he did like to go to the Beyond3D forums.
Mantle, DX12 and Vulkan all expose this capability inherent in modern GPUs. Nobody designed it, and in fact, it has no standardized specification like I already mentioned.
Exactly, asynchronous compute is a feature that has lain dormant in modern GPUs for years, and only now that we have low level APIs that target several IHVs has it become finally exposed.
Meanwhile on the compute side, AMD’s new Asynchronous Compute Engines serve as the command processors for compute operations on GCN. The principal purpose of ACEs will be to accept work and to dispatch it off to the CUs for processing. As GCN is designed to concurrently work on several tasks, there can be multiple ACEs on a GPU, with the ACEs deciding on resource allocation, context switching, and task priority. AMD has not established an immediate relationship between ACEs and the number of tasks that can be worked on concurrently, so we’re not sure whether there’s a fixed 1:X relationship or whether it’s simply more efficient for the purposes of working on many tasks in parallel to have more ACEs.
One effect of having the ACEs is that GCN has a limited ability to execute tasks out of order. As we mentioned previously GCN is an in-order architecture, and the instruction stream on a wavefront cannot be reodered. However the ACEs can prioritize and reprioritize tasks, allowing tasks to be completed in a different order than they’re received. This allows GCN to free up the resources those tasks were using as early as possible rather than having the task consuming resources for an extended period of time in a nearly-finished state. This is not significantly different from how modern in-order CPUs (Atom, ARM A8, etc) handle multi-tasking.
Pascal uses a hybrid driver software/hardware model to do async compute.
GCN does it all in gpu hardware, there is the difference. I am not saying pascal is bad. It works differently. And Mahigan was right about this too.
Before GCN, there was no gpu with async compute capabilities. It was either compute or graphics but not concurrently. You have it wrong.
But you are free to come up with gpu designs that can do it before gcn came out.
And before mantle, there was no async compute API.
Wrong again.
It has not been laying dorment. AMD knows how the simd vector processor model works. A simd vector architecture has the inherent flaw that if you cannot use all simd execution units, you have a lot of hardware doing nothing. AMD recognized that and came up with the idea of the ACE in gcn.
7.9% increase in average frame rate, 3.8% increase in bottom 5% framerate.
And bear in mind that even though it reports my CPU running at 3.3 GHz, I do have it overclocked to 4.2. The 290X is at stock settings. Running AMD's 17.4.4 driver release, Windows 10 Creator Update, Game Mode Off.
I think there's a fairly significant margin of error to GOW4's benchmark. It's not entirely canned - the AI seems to be free to do as it pleases to an extent, and characters may unpredictably throw grenades, chainsaw an enemy, or move off camera. It makes for more practical benchmark than, say, Deus Ex Mankind Divided, since it better simulates actual gameplay, but it does mean no two benchmarks will be exactly the same.Very interesting. It seems your GPU bound score is actually lower with AC on than without. But it's probably within the margin of error. You could also be hitting a CPU wall as well. What does your CPU usage look like during the test with AC on? Does it go up?
I also find it interesting that your CPU render practically had no change, but mine increased by 16% with AC on compared to with it off. But it could just be that since it's all done in hardware on GCN, without relying on the CPU.
Very interesting Now I really want to see a Fiji GPU do this benchmark.
There are pros and cons to each approach. AMD's implementation likely comes with a die space and power usage penalty, plus it's probably not as flexible as Pascal's due to being hardware only. But it can handle much heavier asynchronous compute workloads and thus gain more performance from it.
That doesn't mean the implementation itself is superior however. This implementation probably works best for GCN, which has much greater problems with shader utilization than NVidia's architectures. For NVidia, something resembling ACEs would probably be near useless.
That is true sort of with hyper-q , because everything is prepared and scheduled by software running on the cpu. For physics simulations the software prepares everything and for gpgpu stuff like cuda it would be good. There it is perfectly fine.There are pros and cons to each approach. AMD's implementation likely comes with a die space and power usage penalty, plus it's probably not as flexible as Pascal's due to being hardware only. But it can handle much heavier asynchronous compute workloads and thus gain more performance from it.
That doesn't mean the implementation itself is superior however. This implementation probably works best for GCN, which has much greater problems with shader utilization than NVidia's architectures. For NVidia, something resembling ACEs would probably be near useless.
Big Kepler was capable of processing concurrent asynchronous streams. You're probably right that GCN was the first architecture to process graphics and compute workloads concurrently, but asynchronous compute was also NVidia GPUs, starting with Kepler via Hyper-Q. It was just only used for CUDA HPC stuff, and not for graphics workloads. Then when NVidia finally implemented concurrent compute+graphics in Maxwell, it had severe restrictions because it couldn't process these queues dynamically. Basically the GPU had to know before hand what to expect, so as to properly allocate the resources. Only now with Pascal do NVidia GPUs have the capability to fully process graphics and compute concurrently, and dynamically.
And yet it took how many years before the ACEs even became useful? Seems counterproductive to design an architecture with ACES to increase shader usage, but then not use them for years and years while they just sit there and take up die space and use power.
AMD talked about both approaches years ago:
They talk about Premption @ 1:35
Also, quoting Mahigan is very suspicious to me because that guy definitely has an agenda.
Sounds like nVidia. Pay off the software benchmark company then fake it til you make it.
That is true sort of with hyper-q , because everything is prepared and scheduled by software running on the cpu. For physics simulations the software prepares everything and for gpgpu stuff like cuda it would be good. There it is perfectly fine.
But it does not offload the cpu in any way. No, instead more queues means more cpu overhead. That is the difference.
Actually, GCN came to be in 2011. But the ACE in the GCN chips was utilized in 2013 already when the xbox one and ps4 appeared with the emphasis on ps4.
So, it took just less than 2 years when keeping console development kit hardware in mind as well.
Lol. Something about pots and kettles.
Yep, like I said there are trade offs. With NVidia you get more CPU usage and less potential performance (possibly more flexibility), in exchange for less die space and power usage. Personally I think NVidia made the right decision. But AMD also made the right decision for their architecture as well.
I get what you're saying, but we're talking about PC stuff here and in that context, AMD was unable to make use of the ACEs until 3 years later when Mantle came out in 2014 with BF4. Three years is a long ass time in technology.
Do you mean more CPU use than AMD? Or more CPU use than no async compute? Cause your gears of war test showed a 16% reduction in cpu render time iirc..
Technically the driver can make use of them (multi engine concurrency) in D3D11