monstercameron
Newcomer
I had to log in just to agree with this point!
No DX12 Software is Suitable for Benchmarking *spawn*
- Thread starter trinibwoy
- Start date
PlanarChaos
Newcomer
Pineapple and anchovies!
The horror... the horror...AotS supports both DX11 and DX12. You obviously don't wanna use DX11 with AMD hardware.
It's obvious they don't wanna tell us how much under 150W it is. If they said it's just over 100W, well.
There are also 4 and 8GB versions. I think I've seen some power consumption numbers for the 4 and 8GB GPUs and the difference was around 40W. If thats the case a 4GB version could well be under 100W.
Can't find those power consumption charts unfortunately, but here's the quote from AT:
"The current GDDR5 power consumption situation is such that by AMD’s estimate 15-20% of Radeon R9 290X’s (250W TDP) power consumption is for memory."
Last edited:
Well, after reading the last pages of this topic, I'm not very happy to see my last year prediction coming true: DX12 Giving too much control on the hands of devs brings a lot of mess, much more than with DX11 and AMD/Nvidia in charge of a larger part of the pipeline ! Devs are too much under schedule pressure by publishers and it's been ages that we haven't seen a game released (relatively) bug free. DX12 will amplify the problem and this is exactly what we see...
and regarding AOTS controversy, one interesting comment on reddit by Kontis:
and regarding AOTS controversy, one interesting comment on reddit by Kontis:
Silent_Buddha
Legend
That comment is only relevant if developers don't bother to take advantage of DX12. Which may or may not happen, but considering how closely Dx12 resembles the programming done on consoles, I would imagine there's more likelihood of developers adapting to Dx12 than continuing to have PC ports of games being radically different from their console counterparts.
Some developers will transition more quickly than other developers.
Regards,
SB
Some developers will transition more quickly than other developers.
Regards,
SB
It was obvious right after GDC. AOTS's engine does shading in texture space via compute shaders(no place for delta compression
), it does it for two 4096x4096 texture atlases(16.7 millions of pixels for terrain, 16.7 millions of pixels for units = tons of overshading) and it uses quite simple shaders for lighting(hence mediocre look). Such render will always be bandwidth (especially with MSAA) and texture bound + there are no heavy vertex shaders(you don't need skinning and other stuff for simple units), so geometry pass should be quite light too = good use case for async, all in one -- it's very very very different from modern deferred shading engines and it's a perfect fit for Fury with its massive raw bandwidth, texturing speed and asyncI wonder whether by "FP16 pipe" developer simply meant FP16 render target for HDR since the latest version I've seen looked just like LDR
why not use chapter 1.5
Work too good on Intel IGP, so Nvidia discard it and find chapters 2 more relevant..
Aiee, the problem is reviewers think there's one, it use MLAA for AA, and not FXAA from Nvidia, ( but they have not give numbers without AA ( or MLAA ).
DavidGraham
Veteran
It's quite obvious really. AMD's vigorous push to represent their cards in light of the ashes benchmark will do nothing to improve their position, it wil give their products false image or expectation which will only serve to hurt their products when it's fully dissected and it falls short on those expectations.
Double standards, Gears Of wars was discarded because it's broken on AMD hardware. rise of Tomb raider also got discarded for being broken on both vebdors.
Note that the DirectX 12 patch for Warhammer is not out yet. Any current benchmarks are done with a press beta.
gamervivek
Regular
Was? They do include GoW in their "performance leadership" in dx12 slide, though a dx9 game rendered in dx12 doesn't look any good.
kontis sez:
It's all very really simple indeed!
The thread needs more leaks.
Silent_Buddha
Legend
Then that would be on Nvidia to bring it back. Why should dev's have to make their life more difficult if they don't have to. They have to maintain multiple versions of games anyway. If a Dx12 version that very closely matches the console version works, then why wouldn't they use it? Just because Nvidia don't want them to because it makes them look bad?
People didn't have a problem when developers took advantage of things on Nvidia hardware that made AMD look bad. So they certainly shouldn't have a problem if it's the other way around.
Regards,
SB
hoom
Veteran
D
Deleted member 2197
Guest
Your really being pendantic on this, did you raise this many arguments regarding Chapter 1 being used? No.
My context is performance even if I do not keep re-iterating that in every response I am doing.
While the DX12 memory protection affects both, performance with Nvidia has relatively improved a lot compared to AMD.
Also shown is a performance boost with DX11 for Nvidia over AMD, where this issue does not exist.
Now you cannot do a straight compare between chapters because the benchmarks has one is inside a large room while the other is more open outside (Chapter 2).
So some may put the case forward Chapter 2 can be used as performance is good for Nvidia (both DX12 and DX11), however to be fair I said that the game may be broken in Chapter 2 for AMD and so should not be used.
I mention may because we do not know how AMD's performance is affected if at all by the memory protection or something else, like we do not know what is tanking Nvidia performance in Chapter 1.
Do we really need so many posts discussing this?
Because it is obvious Ch1 AMD has a performance benefit where results below trend for Nvidia, Ch2 Nvidia has a performance benefit that changes the performance a fair bit for AMD.
Conclusion: maybe we should all accept that using this game as a factual point regarding comparing DX12 between AMD and Nvidia is not a good idea because one could present different results and conclusions depending upon chapter used.
Cheers
Last edited:
Any chance PCGamesHardware could revisit Chapter 1 then (both DX12 and DX11)?
Would be great to see if that has also has updated performance.
Problem is nearly all reviews of Chapter 1 was quite awhile ago, while only a rare few benchmarked Chapter 2.
Although even PCGamesHardware states 60% performance boost for Ch2, but did they retest Ch1 and is that % boost applicable to both chapters since update or just latest chapter.
Thanks
Last edited:
PlanarChaos
Newcomer
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.Was? They do include GoW in their "performance leadership" in dx12 slide, though a dx9 game rendered in dx12 doesn't look any good.
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.
