Hitman (2016) PC performance thread

dr_rus said:
PCGamesHw benches are updated again and now we can have a more or less complete picture between vendors in DX12 in this game:

YsKb.png


Questions:
A) WTH is happening to Pitcairn/270X in 1080p/DX12?
B) Why is 960 loosing 6% of performance in 1080p?
C) Why is 770 loosing 14,9% of performance in DX12 in 1080p?
None of this should be happening.
Click to expand...

b and c are because its not cpu limited and nvidia architecture is poorly suited to dx12 multi engine gpu rendering(kepler is even worse). a is probably a driver issue
 
dr_rus said:
PCGamesHw benches are updated again and now we can have a more or less complete picture between vendors in DX12 in this game:

YsKb.png


Questions:
A) WTH is happening to Pitcairn/270X in 1080p/DX12?
B) Why is 960 loosing 6% of performance in 1080p?
C) Why is 770 loosing 14,9% of performance in DX12 in 1080p?
None of this should be happening.
Click to expand...

I hope those results are just because it is a AMD sponsored game, cause Nvidia cards are really performing badly in DirectX 12 compared to AMD ones...i mean i'm almost regretting for changing my r9 290 with the GTX 980 about a year ago
 
dr_rus said:
PCGamesHw benches are updated again and now we can have a more or less complete picture between vendors in DX12 in this game:

http://i.picpar.com/YsKb.png

Questions:
A) WTH is happening to Pitcairn/270X in 1080p/DX12?
B) Why is 960 loosing 6% of performance in 1080p?
C) Why is 770 loosing 14,9% of performance in DX12 in 1080p?
None of this should be happening.[/QUOTE]
D) Why are they testing the 960 and not the 970?
Click to expand...
 
Genio88 said:
I hope those results are just because it is a AMD sponsored game, cause Nvidia cards are really performing badly in DirectX 12 compared to AMD ones...i mean i'm almost regretting for changing my r9 290 with the GTX 980 about a year ago
Click to expand...

Performing badly by loosing only 4% to AMD? Give it a time.
I wonder where is GTX 970 in benchmarks though :-/
 
Hitman Benchmarks : DirectX 12 hebt das CPU-Limit massiv an
Computerbase.de benchmarks, even more favoring for AMD's cards. 970 is there.

icecold1983 said:
b and c are because its not cpu limited and nvidia architecture is poorly suited to dx12 multi engine gpu rendering(kepler is even worse). a is probably a driver issue
Click to expand...

Multiengine rendering should give no benefit on a serial execution but it shouldn't give a performance hit compared to DX11 either as serial execution is the exact same way it is running in DX11. This is especially apparent if you compare the hit 960 takes in 1080p and 3440 - 1080p one is a lot bigger which shouldn't happen at all. This is probably a driver problem.

Genio88 said:
I hope those results are just because it is a AMD sponsored game, cause Nvidia cards are really performing badly in DirectX 12 compared to AMD ones...i mean i'm almost regretting for changing my r9 290 with the GTX 980 about a year ago
Click to expand...

Don't see how they're performing badly with 770 exception really. CB.de's results are worse however.
And yeah, 390X is beating 980Ti in DX11 in this game - what do you think that means for the game's engine optimization?
 
KainXVIII said:
Performing badly by loosing only 4% to AMD? Give it a time.
I wonder where is GTX 970 in benchmarks though :-/
Click to expand...

I compare my actual GTX 980 with the R9 390(which is actually even cheaper than mine)
GTX 980 gains 1.6% with directx 12, instead the 390 gains 11,2%, that's a huge deal.
Though again i hope it's cause this game is sponsored by AMD and perhaps future drivers will fix this

PS: oh right i actually should compare my 980 with the Fury which gains even more than the 390
 
dr_rus said:
Hitman Benchmarks : DirectX 12 hebt das CPU-Limit massiv an
Computerbase.de benchmarks, even more favoring for AMD's cards. 970 is there.



Multiengine rendering should give no benefit on a serial execution but it shouldn't give a performance hit compared to DX11 either as serial execution is the exact same way it is running in DX11. This is especially apparent if you compare the hit 960 takes in 1080p and 3440 - 1080p one is a lot bigger which shouldn't happen at all. This is probably a driver problem.



Don't see how they're performing badly with 770 exception really. CB.de's results are worse however.
And yeah, 390X is beating 980Ti in DX11 in this game - what do you think that means for the game's engine optimization?
Click to expand...

did you read the link i gave you in the other thread? it explains why dx12 is hurting nvidia performance. basically developers have to do a lot of work arounds to get code running decently on nvidias aging architecture. most arent going to bother unless nvidia comes and does it for them with gameworks, probably why almost all recent games perform better on AMD

Genio88 said:
I compare my actual GTX 980 with the R9 390(which is actually even cheaper than mine)
GTX 980 gains 1.6% with directx 12, instead the 390 gains 11,2%, that's a huge deal.
Though again i hope it's cause this game is sponsored by AMD and perhaps future drivers will fix this

PS: oh right i actually should compare my 980 with the Fury which gains even more than the 390
Click to expand...

a 390 is almost 200$ cheaper than a 980. the closest comparison to a 980 is the fury. at 1440p the fury is over 35% faster.
 
icecold1983 said:
did you read the link i gave you in the other thread? it explains why dx12 is hurting nvidia performance. basically developers have to do a lot of work arounds to get code running decently on nvidias aging architecture. most arent going to bother unless nvidia comes and does it for them with gameworks, probably why almost all recent games perform better on AMD
Click to expand...

DX11 and DX12 are running the same code basically with the exception of command queues and memory management obviously. There are no reasons why a serial execution of multiengine queues in DX12 would give a performance drop compared to the same serial execution of the same queues in DX11. NV's "aging" architecture don't have anything to do with it as these queues are handled by the drivers and APIs.

If you're talking about DX11 GCN wins of late then yeah, there are lots of ways to kill NV's performance in the exact same way as tessellation is killing GCN's performance. This doesn't mean that the architecture is "aging", all that means is that the game's code wasn't optimized for NV's architectures. And since this is actually an additional effort compared to GCN's optimizations which are done by default for consoles, more and more devs are simply omitting them from their games. Again, nothing to do with NV's architectures "aging" compared to GCN, everything to do with devs time and budget. This however have no relation to DX12 performance drops on GFs.
 
dr_rus said:
DX11 and DX12 are running the same code basically with the exception of command queues and memory management obviously. There are no reasons why a serial execution of multiengine queues in DX12 would give a performance drop compared to the same serial execution of the same queues in DX11. NV's "aging" architecture don't have anything to do with it as these queues are handled by the drivers and APIs.

If you're talking about DX11 GCN wins of late then yeah, there are lots of ways to kill NV's performance in the exact same way as tessellation is killing GCN's performance. This doesn't mean that the architecture is "aging", all that means is that the game's code wasn't optimized for NV's architectures. And since this is actually an additional effort compared to GCN's optimizations which are done by default for consoles, more and more devs are simply omitting them from their games. Again, nothing to do with NV's architectures "aging" compared to GCN, everything to do with devs time and budget. This however have no relation to DX12 performance drops on GFs.
Click to expand...

maybe gears of war is running the same code, because its basically a port of dx11 code to dx12, which is a complete waste of time. games that make good use of dx12 will be completely different than dx11. the code will not be the same. from the link i gave you in the other thread

"Due to the possible performance penalties from using compute commands concurrently with draw calls, compute queues should mostly be used to offload and execute compute commands in batch.

There are multiple points to consider when doing this:

The workload on a single queue should always be sufficient to fully utilize the GPU.
There is no parallelism between the 3D and the compute engine so you should not try to split workload between regular draw calls and compute commands arbitrarily. Make sure to always properly batch both draw calls and compute commands.
Pay close attention not to stall the GPU with solitary compute jobs limited by texture sample rate, memory latency or anything alike. Other queues can't become active as long as such a command is running.
Compute commands should not be scheduled on the 3D queue.
Doing so will hurt the performance measurably. The 3D engine does not only enforce sequential execution, but the reconfiguration of the SMM units will impair performance even further.
Consider the use of a draw call with a proxy geometry instead when batching and offloading is not an option for you. This will still save you a few microseconds as opposed to interleaving a compute command.
Make 3D and compute sections long enough.
Switching between compute and 3D queues results in a full flush of all pipelines. The GPU should have spent enough time in one mode to justify the penalty for switching.
Beware that there is no active preemption, a long running shader in either engine will stall the transition."

none of that has to be worried about on amd hardware/consoles. at least not to nearly the same degree
 
icecold1983 said:
maybe gears of war is running the same code, because its basically a port of dx11 code to dx12, which is a complete waste of time. games that make good use of dx12 will be completely different than dx11. the code will not be the same.
Click to expand...
This is completely wrong. A proper DX12 game will use the same shaders and have the exact same GPU load as a DX11(.3) game. The difference in renderers will be huge because a D3D12 renderer must run a lot more things than DX11 one but the ending result for a GPU which doesn't support concurrent async should be mostly the same. This means that there should not be any performance losses or gains in GPU limited scenarios. If a game is using a different rendering in DX12 then any comparison to DX11 becomes meaningless as you're comparing apples to oranges and not DX11 to DX12 (this is btw what happens in AotS at the moment which is partially the reason why it's performing so differently in DX12 on most h/w).

icecold1983 said:
from the link i gave you in the other thread

"Due to the possible performance penalties from using compute commands concurrently with draw calls, compute queues should mostly be used to offload and execute compute commands in batch.

There are multiple points to consider when doing this:

The workload on a single queue should always be sufficient to fully utilize the GPU.
There is no parallelism between the 3D and the compute engine so you should not try to split workload between regular draw calls and compute commands arbitrarily. Make sure to always properly batch both draw calls and compute commands.
Pay close attention not to stall the GPU with solitary compute jobs limited by texture sample rate, memory latency or anything alike. Other queues can't become active as long as such a command is running.
Compute commands should not be scheduled on the 3D queue.
Doing so will hurt the performance measurably. The 3D engine does not only enforce sequential execution, but the reconfiguration of the SMM units will impair performance even further.
Consider the use of a draw call with a proxy geometry instead when batching and offloading is not an option for you. This will still save you a few microseconds as opposed to interleaving a compute command.
Make 3D and compute sections long enough.
Switching between compute and 3D queues results in a full flush of all pipelines. The GPU should have spent enough time in one mode to justify the penalty for switching.
Beware that there is no active preemption, a long running shader in either engine will stall the transition."

none of that has to be worried about on amd hardware/consoles. at least not to nearly the same degree
Click to expand...

This is again something you're getting too much conclusions from, it is known for some time really and it doesn't apply solely to Maxwell here as there are a lot of FL11_0 h/w which can also run under D3D12 but do not support concurrent async at all.
DX12 driver should be able to batch compute queues jobs from the async compute queues. There are quite a lot an IHV can do with DX12 driver, and I'm not even that sure that the claim of less importance of DX12 driver compared to DX11 is true.
Maxwell should be able to perform compute concurrently with graphics when it's of benefit to it.
GCN's queue interleaving is an architectural decision made to fix issues arisen after another architectural decision, it's not necessarily a "proper" decision as fixing the issues in the first place would probably be a better one and there isn't much indications that other h/w will ever follow it for the same reasons as GCN does now.
This recommendations are true not only for NV's h/w but for Intel's IGPs as well and that's >90% of the PC GPU market in total. So is it really wise for a dev to ignore such optimizations only because consoles and 10% of PC GPUs don't benefit from them (which they actually do in DX11) and there are no indications that this situation will change anytime soon? What do you think?
 
dr_rus said:
This is completely wrong. A proper DX12 game will use the same shaders and have the exact same GPU load as a DX11(.3) game. The difference in renderers will be huge because a D3D12 renderer must run a lot more things than DX11 one but the ending result for a GPU which doesn't support concurrent async should be mostly the same. This means that there should not be any performance losses or gains in GPU limited scenarios. If a game is using a different rendering in DX12 then any comparison to DX11 becomes meaningless as you're comparing apples to oranges and not DX11 to DX12 (this is btw what happens in AotS at the moment which is partially the reason why it's performing so differently in DX12 on most h/w).
Click to expand...

this would maybe be the case if the code was written specifically for nvidia. this will be a very rare occurrence due to amd being in both consoles.

dr_rus said:
This is again something you're getting too much conclusions from, it is known for some time really and it doesn't apply solely to Maxwell here as there are a lot of FL11_0 h/w which can also run under D3D12 but do not support concurrent async at all.
DX12 driver should be able to batch compute queues jobs from the async compute queues. There are quite a lot an IHV can do with DX12 driver, and I'm not even that sure that the claim of less importance of DX12 driver compared to DX11 is true.
Maxwell should be able to perform compute concurrently with graphics when it's of benefit to it.
GCN's queue interleaving is an architectural decision made to fix issues arisen after another architectural decision, it's not necessarily a "proper" decision as fixing the issues in the first place would probably be a better one and there isn't much indications that other h/w will ever follow it for the same reasons as GCN does now.
This recommendations are true not only for NV's h/w but for Intel's IGPs as well and that's >90% of the PC GPU market in total. So is it really wise for a dev to ignore such optimizations only because consoles and 10% of PC GPUs don't benefit from them (which they actually do in DX11) and there are no indications that this situation will change anytime soon? What do you think?
Click to expand...

all amd gcn gpus support async compute. maxwell can not perform graphics and compute concurrently under dx12. switching from 1 to the other requires a flush of the entire gpu. performance dictates which hardware decisions are better.
 
GCN just keep getting better and better. They might just rebrand them into 490 and still beating GTX 1080. I guess when they gave the code name "Graphics Core Next" they were not kidding....lol
 
Ugh, benchmark isn't good. Averaging 52fps in it on a 970 despite GPU and CPU usage often being nowhere near max. DX12 is stutter city and even worse.
 
Think I'm going to sideline this until there's a few patches out. Getting terrible stuttering and frequent crashes on both DX11 and DX12.

Disappointing.
 
I think DX12 is straight up broken for me. Tutorial level and the benchmark won't load unless I have DX11, even though I'm on Windows 10. Task manager shows that the game process just stops doing anything after a while.
 
Dinjoralo said:
I think DX12 is straight up broken for me. Tutorial level and the benchmark won't load unless I have DX11, even though I'm on Windows 10. Task manager shows that the game process just stops doing anything after a while.
Click to expand...

Benchmark won't load even on DX11 for me. So screwy.
 
Game keep on crashing during the boat level for me with DirectX 12 and everything maxed out, anyone is having this problem? GTX 980 here...Now all of a sudden it's downloading another 2gb update
 
pahamrick said:
Benchmark won't load even on DX11 for me. So screwy.
Click to expand...
You sure? I thought the same thing but there was just a black screen for like 15 seconds then it started.

But yes, performance seems messy as hell. Hope optimisation is something they'll be working on as they release new content.
 
Oof this game is running so poorly. Also found a consistent crash bug in the first level. Basically poison the drink in the 1st Floor bar area (which gets you noticed) and go into the kitchen and switch clothes. Instant crash.


As a huge Hitman fan this makes me very sad. I can deal with the 60 ish FPS but the crashing is too much.
 
Looks like NVIDIA gamble on not bothering with proper Async Compute blew up in their faces.

Way to go NVIDIA. Next card for me might be AMD.
 
Huh, I would have expected better numbers for the Fury based on the 390X results.

It looks like DX12 is primarily benefiting the R9 390 cards.
 
Arkanius said:
Its where they got their Perf/Watt gains.
Click to expand...

But it puts them at a significant disadvantage for future DX12 titles on Maxwell and Kepler.

100% depends on how Polaris and Pascal are priced for their performance, but some of the bullshit NVIDIA has been pulling recently has been annoying me.
 
I wanted to play with high textures but the launcher didn't let me. You can overwrite this locks with the registry editor. Here you go:

Example: http://i.imgur.com/DGUzYJH.png

HKEY_CURRENT_USER\Software\IO Interactive\Hitman

Some setting keys explained:

AntiAliasing - 0: OFF, 1: ON
SuperSampling - Recommended range between 1000 and 2000
LevelOfDetail - 0: LOW, 1: MED, 2: HIGH, 3: ULTRA
TextureResolution - 0: LOW, 1: NORMAL, 2: HIGH
TextureFilter - 0: TRILINEAR, 1: ANISOTROPIC_2X, 2: ANISOTROPIC_4X, 3: ANISOTROPIC_8X, 4: ANISOTROPIC_16X
ShadowQuality - 0: LOW(4), 1: MED(8), 2: HIGH(16), 3: ULTRA(32)
ShadowResolution - 0: LOW(512), 1: MED(1024), 2: HIGH(2048)
Fullscreen - 0: WINDOWED, 1: FULLSCREEN

Feel free to add more keys, majority will be 0 for off or 1 for on.
 
It's kinda sad that they couldn't finish one, just one episode before the release. Another unfinished product/bad port... why am i not surprised?
 
knerl said:
DX12? DX11 on Ultra with a EVGA GTX 970 SSC ACX 2.0+ you get 41-65fps according to Sweclockers.com
Click to expand...

DX12 does not work for me, it somehow prevents the game from loading anything from my hard drive according to Task Manager. The game process gets zero disk usage when it should be loading a level and eventually locks up.
 
Game is broken for me, on DirectX 12 runs fine but it freeze with just sound remaining every time, after not even one minute of gameplay, on DirectX 11 instead it looks like it wouldn't crash though it runs awfully if i put vsync for 30fps it just drops every time under 20, if instead i put it to 60fps it drops from 60 to 40 with lot of stuttering, it makes no sense. I'm on GTX 980 and latest drivers, anyone having same issues?
Thankfully i bought pretty cheap, i hope they'll patch it as soon as possible
 
Garrett Hawke said:
You sure? I thought the same thing but there was just a black screen for like 15 seconds then it started.

But yes, performance seems messy as hell. Hope optimisation is something they'll be working on as they release new content.
Click to expand...

I'll give it another shot, maybe I didn't let it sit long enough.
 
Cyborgmatt said:
I wanted to play with high textures but the launcher didn't let me. You can overwrite this locks with the registry editor. Here you go:

Example: http://i.imgur.com/DGUzYJH.png

HKEY_USERS\S-1-5-21-2445478570-1775773540-1949376999-1001\Software\IO Interactive\Hitman

Some setting keys explained:

AntiAliasing - 0: OFF, 1: ON
SuperSampling - Recommended range between 1000 and 2000
LevelOfDetail - 0: LOW, 1: MED, 2: HIGH, 3: ULTRA
TextureResolution - 0: LOW, 1: NORMAL, 2: HIGH
TextureFilter - 0: TRILINEAR, 1: ANISOTROPIC_2X, 2: ANISOTROPIC_4X, 3: ANISOTROPIC_8X, 4: ANISOTROPIC_16X
ShadowQuality - 0: LOW(4), 1: MED(8), 2: HIGH(16), 3: ULTRA(32)
ShadowResolution - 0: LOW(512), 1: MED(1024), 2: HIGH(2048)
Fullscreen - 0: WINDOWED, 1: FULLSCREEN

Feel free to add more keys, majority will be 0 for off or 1 for on.
Click to expand...

Don't use HKEY_USERS, as it's tied to your account's SID and isn't user friendly for most people to find. Use HKCU instead.
 
You must log in or register to reply here.

Similar threads

Final Fantasy XVI PC Performance Thread
2 3
138
14K
Rush2112 replied
Capcom responds to Monster Hunter wilds PC performance issues
2 3 4
158
11K
polybius80 replied
Kevin Mcallister in Hitman 3
2
537
RoadHazard replied
Dragon's Dogma 2 PC Performance Thread
2 3 4
183
21K
JRW replied
[DSOGaming] Indiana Jones and the Great Circle Benchmarks & PC Performance Analysis
Analysis Platform 
26
4K
twilo99 replied
Top Bottom