The CPU forum is ^ that a way.
There's no dynamic light source for spells & weapon effects. In the demo showed where they mention async compute, there is. So from a viewer PoV, one's very static, other isn't.
Edit: The contention here is that NV drops off in performance in Ashes in the full test (but gains perf in the draw call test!) is perhaps due to poor async compute/shading performance OR poor implementation by Oxide. For the blame on Oxide to be true, you would need to show proof that Kepler/Maxwell is great at async compute/shading. As I said, I only see examples of gamedevs praising async compute/shading for GCN, not for Kepler/Maxwell.
Yeah, some alleged ps4 dev says maxwell might have to use a context switch which might have a penalty and at the same time admits that it might not even be useful to have more than one asynchronous pipeline.
Sounds like for sure nvidia is doomed. Yep...
Makes perfect good sense right?
Oh yeah, then he says they don't have a chance because of mantle.
With GCN, the ACEs I believe are controlled in hardware. So the devs probably don't have to do much, if anything to exploit them. But since NVidia does not have dedicated ACEs, tight management of the GMU and HyperQ will become critical for performance.
No, they are just hitting the load wall much earlier. All nVidia cards are losing performance when they are nearly at 100% load.This explains why the GTX 980 Ti was able to be pretty much on par with the Fury X in the benchmarks, whilst other Maxwell GPUs like the GTX 980, 970 and 960 with smaller shader arrays experienced slowdowns in DX12. That's because they need greater optimization due to having less spare cycles than the GTX 980 Ti and Titan X.
Hyper-Q isnt exposed through the DX11 API. DX11 doesnt know such a concept of different queues. In DX12 you need to write directly against every "engine".In DX11, NVidia used their drivers to manage the GMU, but in DX12, the developers will probably have to get their hands dirty when it comes to tapping into it.
Maxwell was designed for multithreaded environment. That is true. But for parallel environment its capabilities are limited with one ACE. In DirectX12 the schedules are parallel, whereas on DirectX 11 the schedules were multiple but were not happening at the same time. That is he difference between the mechanic here. And thats why Maxwell GPUs are getting worse performance. The problem lies in Asynchronous Shading, whether we like it or not.
So, why is Microsoft able to make DX12 faster on nVidia hardware? Do you really think that Oxide doesnt know DX12 and they are now trying to cover their bases with the blame game - it must be the driver or some magical mainboard setting?!We can argue abiut this. Blaming Oxide is like blaming Microsoft for giving DirectX 12. With this API you can't lock any developer from performance. It is simply not possible. You cannot make one vendor look better than the other. That is not the nature of DX12. And no, im not software engineer. But i understand what means that the application talks directly to the GPU, without the CPU intervention.
Yeah well, you see the exact same arguments here that you see in the big fx vs intel core arguments,more cores doing much more stuff in parallel vs fewer cores doing stuff much faster.
If you think about it GPUs are just very specialized CPUs,so far so that AMD is calling everything a compute core no matter if x86 or GCN.
I'm not,I was just making fun of The Programmers fail post.How are you drawing the parallel with FX CPU's failed performance though?
I'm not,I was just making fun of The Programmers fail post.
If you're supposed to ditch your nvidia cards because of a game (alpha benchmark) that is coming out in a year,than you should ditch your fx cpus for the same reason.
The thing is that 99% (if not more) of AAA games coming out are console ports and people are sitting here talking about the 1 game designed on pc for pc that is showcasing a worst case scenario for drawcalls,sure its a valid point for this kind of games, but this kind of games will be very sparse.
And it's not even finished yet so you can't draw conclusions yet.
Well the only reference to the expected performance that he has (or accepts) is this benchmark,and he is trying to push people towards amd based solely on this one bench,so it's fair to do the opposite and push people away from amd.I think he's referring to DX12 as the reason to ditch nVidia
How much faster do you think high end pc gpus are in contrast to the console apu-gpu?The consoles are GCN based and both have asynchronous shaders. This is why this is so important, game devs will (they already do in a few cases) use asynchronous shaders to get the maximum performance out of their console games and AMD will see the benefit in PC games because of that.
How much faster do you think high end pc gpus are in contrast to the console apu-gpu?
Console games will be restricted by what a console gpu can do and not what a pc gpu can do,devs doing additional stuff for the pc version is not the norm.
This is in sharp contrast to NVidia's Maxwell, which has no dedicated ACE or similar counterpart, but instead uses the GMU along with their HyperQ technology to keep the GPU as occupied as possible; an approach which seems to be very successful as Maxwell is an extremely efficient architecture and does not have the under utilization problem that GCN has.
So what's causing the DX12 path to be slower than the DX11 path in AotS for Maxwell? I think it's because Oxide's DX12 optimization for NVidia isn't up to par with the driver optimizations NVidia made for DX11.
This explains why the GTX 980 Ti was able to be pretty much on par with the Fury X in the benchmarks, whilst other Maxwell GPUs like the GTX 980, 970 and 960 with smaller shader arrays experienced slowdowns in DX12. That's because they need greater optimization due to having less spare cycles than the GTX 980 Ti and Titan X.
In DX11, NVidia used their drivers to manage the GMU, but in DX12, the developers will probably have to get their hands dirty when it comes to tapping into it.
It's not additional stuff though, that's the point. It would be additional to remove the async shaders from a console port!
Async shaders are a potential bottleneck on current gen Nvidia cards that devs will either have to remove to increase performance on Nvidia, or just leave it as it is and accept that Nvidia cards will perform less optimally. What do you think they'll do?
Okay, i have one question:
How can "Async shaders" be a a "potential bottleneck on current gen Nvidia card" when this is a new features of DX11 to improve the performance of "current gen Nvidia card".
So, where is your proof that "Async shaders" cost performance on nVidia hardware when this concept doesnt exist in DX11 and nVidia shows a massive performance improvement with Hyper-Q.
Async shaders are a DX12 thing, there is no way to use them in DX11.
The proof is in the benchmarks which show Nvidia loses perf in DX12 compared to DX11.
Where is the proof that this benchmark is using "Async shaders"?
Ashes of the Singularity Benchmark Technical Features:
3. Asynchronous Shaders: This allows the schedule of work for the GPU that will be performed. Traditionally, the GPU’s command queue would have had stalls, and DirectX 12 essentially provides more work done for free.
Read more at http://www.legitreviews.com/ashes-o...chmark-performance_170787#vHlbJSkeq2XB4r7D.99
How can "Async shaders" be a a "potential bottleneck on current gen Nvidia card" when this is a new features of DX12 to improve the performance of "current gen Nvidia card".
And then they are blaming nVidia for the problems with MSAA(!):MSAA is implemented differently on DirectX 12 than DirectX 11. Because it is so new, it has not been optimized yet by us or by the graphics vendors. During benchmarking, we recommend disabling MSAA until we (Oxide/Nidia/AMD/Microsoft) have had more time to assess best use cases.
Read more at http://www.legitreviews.com/ashes-o...chmark-performance_170787#yUildSjYlRwdgrqz.99
This company is a joke.Fundamentally, the MSAA path is essentially unchanged in DX11 and DX12. Any statement which says there is a bug in the application should be disregarded as inaccurate information.
Read more at http://www.legitreviews.com/ashes-o...mark-performance_170787/2#cQov5Yh1BSSE1sKC.99
Ah, thank you.
Where is your proof, that "Asynchronous Shaders" is the reason for the performance impact of DX12?
I like this part:
And then they are blaming nVidia for the problems with MSAA(!):
This company is a joke.
/edit: DX12 is not an vendor specific API. "Asynchronous Shaders" (aka Asynchronous Compute) is defined by Microsoft to use more compute units to process information at the same time. It doesnt cost performance on hardware which supports DX12. Worst case nothing happens because there is no difference to DX11.
Ah, thank you.
Where is your proof, that "Asynchronous Shaders" is the reason for the performance impact of DX12?
I like this part:
And then they are blaming nVidia for the problems with MSAA(!):
This company is a joke.
/edit: DX12 is not an vendor specific API. "Asynchronous Shaders" (aka Asynchronous Compute) is defined by Microsoft to use more compute units to process information at the same time. It doesnt cost performance on hardware which supports DX12. Worst case nothing happens because there is no difference to DX11.
It's not additional stuff though, that's the point. It would be additional to remove the async shaders from a console port!
Async shaders are a potential bottleneck on current gen Nvidia cards that devs will either have to remove to increase performance on Nvidia, or just leave it as it is and accept that Nvidia cards will perform less optimally. What do you think they'll do?
amd 390 is on par with a 980ti for dx12..
Not what I was saying.
Console games will have async in the amount of what the apu-gpu can handle, this will be way less than what even a middle class desktop gpu can handle.
Async shaders are a potential bottleneck on current gen Nvidia cards ONLY IF YOU DEVELOP TO PUSH THE BIGGEST OF DESKTOP CARDS,ashes is doing that (and after a year of optimizing until it comes out a lot will change) but a classic console port will not.