• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

GoW4 benchmarks.

Shintai

Shintai

Supreme [H]ardness
Joined
Jul 1, 2016
Messages
5,677
Gears of War 4 GPU Benchmark - 1080, 1440, & 4K Tested

First GoW4 benchmarks are out.
gow4-pc-bench-1080ultra_2.png

gow4-pc-bench-1440ultra_2.png


Gears of War 4 тест GPU | Action / FPS / TPS | Тест GPU
gw4_1920.png

gw4_2560.png

gw4_3840.png


Gears of War 4: Erste Performance-Eindrücke und erneute UWP-Krankheiten

Added async test too.
AsyncCompute.jpg
 
Last edited:
Does the game include a benchmark and that's what was used in one of those sets vs actual gameplay in the other? Because the GameGPU and GamersNexus AMD numbers are pretty close to each other, but the NV numbers are way off between the two, for something that was supposed to be the same settings and resolution. In fact, the only thing they agree on is that a GTX 1080 can peg the fps for 144Hz monitors at 1080p.

Edit: Ok, GN used the ingame benchmark, while I can't read the GameGPU article itself. Also noticed that the min framerates on AMD cards was significantly higher across the board in the GameGPU article. So takeaway so far is that no one has a repeatable set of findings yet.
 
Last edited:
The test CPUs (and rest of system) are all different I believe. Gamegpu is using the fastest with a i7-5960x at 4.6ghz. Gamenexus ia i7-5930k (6core) at 3.5ghz. Nvidia is a i7-5960x at stock (3ghz)?

Driver versions are also different I think. Gamegpu is using latest AMD but not Nvidia. Gamernexus latest Nvidia but not AMD.
 
I'm liking what I'm seeing! Digital Foundry did a quick analysis video on it and said that GoW 4 is the smoothest running Windows Store game they've tested so far. I was starting to wonder if it was possible for a Windows Store game to not have frame hitches.
 
And yet, as the memory footprint grows with higher resolutions, the performance gap between the two cards shrinks from 50% to 33%. Wouldn't the significantly larger footprint pose greater problems for the Fury X as resolutions increase? Or is it that since it's already in the "worst case scenario" from the beginning vs a card that should have no buffer issues, it's showing that the 1080 doesn't scale as well as resolution increases?

Edit: Scratch that. It was noted above that the NV drivers for GameGPU were out of date, so their performance numbers may be suspect.
 
Last edited:
Something is definitely odd about the charts with the 8370. The 1080 drops all the way below a Fury X? Something is off for sure. Now I'm wondering how my 3770K and 1080 will do. Hopefully they'll perform like they should.
 
Computerbase is usually quite good and thorough with their reviews, results seem all over the place. I know Pcgh tested ingame, maybe computer base are using the ingame benchmark?
 
Ieldra said:
Computerbase is usually quite good and thorough with their reviews, results seem all over the place. I know Pcgh tested ingame, maybe computer base are using the ingame benchmark?
Click to expand...
PCGH is my go-to and in my experience the most accurate. I've always liked how they use factory OC'd cards and specify the clocks.
 
where is the uproar async done by drivers, or pascal can't do hardware async, or this game doesn't represent DX12, or Unreal Engine 4 can't do proper DX12, or lets throw in the entire kitchen and sink at it?
 
razor1 said:
where is the uproar async done by drivers, or pascal can't do hardware async, or this game doesn't represent DX12, or Unreal Engine 4 can't do proper DX12, or lets throw in the entire kitchen and sink at it?
Click to expand...
Current flavor is "UE favors Nvidia". Safe bet.
I also see the CBase benchmarks getting floated more than the others since AMD does much better in those.
 
Well if done right, both vendors should end up around the same, and that shows rx480 and the 1060 are neck and neck, just the way it should be, Fury X is behind the 980ti, but gains with resolution, just like before. What ever is pushing each others strengths it shows that and equalize at the end. AMD gains more on async like they should and its not a game changer, just equalizes the playing field. Like I have always stated, just untapped potential (harder to get to for developers) of AMD's shader array is holding them back relatively speaking.

Interestingly enough though, even with "less" raw shader capabilities, nV has no issue in keeping up with most games, that means all that extra shader amounts AMD has, they are using the same amount theoretically as nV, no more, just goes to show, as much as 30% of AMD's shader array isn't being used most of the time then add in their through put problems, its probably even more under utilization more like in the neighborhood of 40% which Async helps resolve that 10%

And this game isn't a port, the engine was made from ground up for both consoles and PC, and Microsoft specially wanted the developer to make it for platforms from the start of the project. A big difference from PC "after thought" projects.
 
Last edited:
The 8370 result needs way more digging, if thats how future DX12 titles behave without $1000 cpus would love to know
 
So wait

The developer spouted off some off-hand remarks about 'insane' settings being for SLI and future GPUs... when UWP does not support SLI. Am I the only one raging out on this?
 
razor1 said:
Interestingly enough though, even with "less" raw shader capabilities, nV has no issue in keeping up with most games, that means all that extra shader amounts AMD has, they are using the same amount theoretically as nV, no more, just goes to show, as much as 30% of AMD's shader array isn't being used most of the time then add in their through put problems, its probably even more under utilization more like in the neighborhood of 40% which Async helps resolve that 10%
Click to expand...
Shader capabilities only matter if there is enough demand for them. Compute load increases with resolution, hence why Fury has the scaling that it does with limited memory. The game looks ok, but I wouldn't say it has a lot of complex lighting and physics to really stress the shaders.

razor1 said:
And this game isn't a port, the engine was made from ground up for both consoles and PC, and Microsoft specially wanted the developer to make it for platforms from the start of the project. A big difference from PC "after thought" projects.
Click to expand...
Sort of, but I'm not sure it has a fully multi-threaded resource engine. It works on both, but I wouldn't exactly call UE the most advanced in it's current state. Maybe the devs modified the engine significantly, but I'm guessing they just made it work well.

KazeoHin said:
The developer spouted off some off-hand remarks about 'insane' settings being for SLI and future GPUs... when UWP does not support SLI. Am I the only one raging out on this?
Click to expand...
SLI and Crossfire aren't really DX12 technologies. If pairing an Nvidia and AMD card, which is used? SLI or Crossfire? They will transition into linked adapter or multiple discrete implementations left up to the developer. Profiles won't be required.
 
Anarchist4000 said:
SLI and Crossfire aren't really DX12 technologies. If pairing an Nvidia and AMD card, which is used? SLI or Crossfire? They will transition into linked adapter or multiple discrete implementations left up to the developer. Profiles won't be required.
Click to expand...

I don't think you catch my drift. What I'm saying is that UWP does not support multi-adapter modes. That dev basically said there are features in this game that exist for setups this game (and this platform) does not actually support.
 
Anarchist4000 said:
Shader capabilities only matter if there is enough demand for them. Compute load increases with resolution, hence why Fury has the scaling that it does with limited memory. The game looks ok, but I wouldn't say it has a lot of complex lighting and physics to really stress the shaders.
Click to expand...

If you used the UE4 engine you would know it has some of the best per pixel lighting effects on the market. The difference between that and Cry Engine, is the aesthetics and art direction the art directors are going for and that is it.

Sort of, but I'm not sure it has a fully multi-threaded resource engine. It works on both, but I wouldn't exactly call UE the most advanced in it's current state. Maybe the devs modified the engine significantly, but I'm guessing they just made it work well.
Click to expand...

The engine is fully scaleable to the dev's need, so depending on what they are going for they can pretty much do anything they want to, there are some limitations, I have mentioned in the past, but the way UE4 is scaling in GOW4, looks like the dev's took care of that.
 
KazeoHin said:
I don't think you catch my drift. What I'm saying is that UWP does not support multi-adapter modes. That dev basically said there are features in this game that exist for setups this game (and this platform) does not actually support.
Click to expand...
My mistake then, although I've seen stuff on Microsoft exploring multi-adapter tech so if it's not enabled now it likely will be in the future.

razor1 said:
If you used the UE4 engine you would know it has some of the best per pixel lighting effects on the market.
Click to expand...
Engine aside, I wasn't seeing a whole lot of cloth simulation, particles, large number of characters, or complex animation running in the game. That goes more to the style of the game than anything else. Can't say I've seen very many demos of UE lighting that look superior to some of the CryEngine examples. Same with multiengine and async lighting effects. Last I looked they were only starting to roll out compute effects for console.
 
Poor AMD. Got their clocks cleaned pretty good. DX12, etc isn't their big savior it's made out to be. They really need to get new cards out asap.
 
Anarchist4000 said:
Engine aside, I wasn't seeing a whole lot of cloth simulation, particles, large number of characters, or complex animation running in the game. That goes more to the style of the game than anything else. Can't say I've seen very many demos of UE lighting that look superior to some of the CryEngine examples. Same with multiengine and async lighting effects. Last I looked they were only starting to roll out compute effects for console.
Click to expand...

Well cloth simulation, depending on what you are using, what libraries, Flex is way better than the traditional PhysX on CPU or anything AMD has right now, so I wouldn't even look into that.

As for the lighting, if you want the most intensive lighting and realistic looking, just look at the archviz things that each of these engines are capable of, there are demos you can dl and just play for your visual pleasure, UE4 and Cry Engine 5 are very close in terms of quality. That should give you an idea of what each engine is capable of if you want to push it more, you end up loosing frame rates, its that simple. Suprisingly, performance wise, if you want the same visual affects, you end up with similar frame rates.

Multi Engine doesn't work well at all on most modern engines, even Cry Engine, which btw is supposed to be getting MGPU later on.

Async lighting effects, there is no such thing. Async shaders aren't just relegated to lighting..... Depending on what the developer is doing, they can use Async on any type of shader and should use it when they are appropriate and when it won't be detrimental to performance. This is also the reason why the developer needs to know what is going on all of their shaders and shader resources before even going down the path of using async because they need to know and predict reasonably, what resources are being used, and what is available to them for async shaders.

Its not something that is willy nily, lets do async for shadows, and lighting, because they seem to fit well together. Nope, doesn't work that way. Different scenes in a game, will have different break outs of shader utilization, so ever single portion of the game levels have to be segmented, analyzed, play tested, and then the best approach to do async can be done. Otherwise, you end up with a great pile of dung if that isn't done. Lets throw in physics into the mix because some were saying that should be easy to add into a compute queue, nope that too, will make things much harder because that is going to be even more random then lighting and shadows........

Edit and trust me on this, cause I've been looking into it, and its not easy, its very complex to do because the amount of compute queues and shaders breaking them down, is HARD to do, looking at easily 500 different shaders and seeing how the game reacts to dynamic lighting and shadows when you have so many different things going on with light sources now, its very time consuming.

If you were to make a game with no static lighting, all dynamic *which can only be done if you have a very good level designer who knows lighting very well*, you are going to run across issues with async shaders that are very hard to resolve, might as well not use them at all. GOW4 doesn't use all dynamic lighting from what I've seen so far.
 
Last edited:
razor1 said:
Multi Engine doesn't work well at all on most modern engines, even Cry Engine, which btw is supposed to be getting MGPU later on.
Click to expand...
CryEngine is still refactoring a lot of code. If you look at their roadmap for November they have attachment refactoring, animation refactoring, resource refactoring, memory management, etc. I'm still expecting to see async reprojection pushed out for most environments. I'm guessing that's what "Introducing parallelization into the game code (for 120 FPS)" means, as I don't recall their physics being locked to 60Hz. I'd definitely agree all the engines are still figuring out DX12/Vulkan for the better. Should be plenty of interesting GDC papers in the next year or two.

razor1 said:
Its not something that is willy nily, lets do async for shadows, and lighting, because they seem to fit well together. Nope, doesn't work that way. Different scenes in a game, will have different break outs of shader utilization, so ever single portion of the game levels have to be segmented, analyzed, play tested, and then the best approach to do async can be done. Otherwise, you end up with a great pile of dung if that isn't done. Lets throw in physics into the mix because some were saying that should be easy to add into a compute queue, nope that too, will make things much harder because that is going to be even more random then lighting and shadows........
Click to expand...
This is one of those limitations we've gone back and forth on before where one architecture is likely better with the randomness. If an artist makes a complex scene it's as simple as that. Like you said there are just far too many variables. Best to just list as independent tasks and let the drivers figure it out. Pairing really only works if the tasks all occur within the same frame. Get a physics kernel that runs for several frames and there is no real pairing it off beyond segmenting the hardware.
 
Taking it with grains of salt.

It shows Fury X coming from behind a 1060 at 1080p, then matches it on 1440p, and THEN drops below it again.

Something feels off, especially given the dramatic min fps difference in 1080p that vanishes in 1440p and yet shows up again at 4k.

Still, the fact that we are comparing Fury X to a 1060 rather than 1070 at least, doesn't bode terribly well at this stage.
 
Anarchist4000 said:
CryEngine is still refactoring a lot of code. If you look at their roadmap for November they have attachment refactoring, animation refactoring, resource refactoring, memory management, etc. I'm still expecting to see async reprojection pushed out for most environments. I'm guessing that's what "Introducing parallelization into the game code (for 120 FPS)" means, as I don't recall their physics being locked to 60Hz. I'd definitely agree all the engines are still figuring out DX12/Vulkan for the better. Should be plenty of interesting GDC papers in the next year or two.
Click to expand...

Well I haven't seen much difference between Cry Engine and UE4 feature set wise,

This is one of those limitations we've gone back and forth on before where one architecture is likely better with the randomness. If an artist makes a complex scene it's as simple as that. Like you said there are just far too many variables. Best to just list as independent tasks and let the drivers figure it out. Pairing really only works if the tasks all occur within the same frame. Get a physics kernel that runs for several frames and there is no real pairing it off beyond segmenting the hardware.
Click to expand...

its not randomness, its how far you want to split up your blocks, and yeah its not good for AMD hardware either. So you need to pay attention to what you are doing.
 
chenw said:
Taking it with grains of salt.

*snip*

Still, the fact that we are comparing Fury X to a 1060 rather than 1070 at least, doesn't bode terribly well at this stage.
Click to expand...

The Fury X should be competing with the 1070 in practically every title. If it's not, there's something inherently wrong with the AMD code path.
 
You must log in or register to reply here.
Back
Top