computerbaseDota 2 Vulkan benchmarks

[dogen1]

Well those results weren't what I expected.

More so the performance lost on a weaker CPU considering all the hoolah about how it's suppose to help slower CPUs.

Optimization is probably ongoing as with the talos principle.

 

[krumme]

Valve really need to update their engine. Its like 10 years old. But my guess is with vulkan the long term is arm mobiles and 8 ultra weak core support.
Looking forward to test this on a crappy acer v122p with 4 jaguar cores spinning at 1ghz. Lol.

 

[Raising]

Then limit your fps. You're going to have framerates all over the place, no matter what CPU you have, and no matter what API the game is using.

Limiting fps or vsync on/ff does nothing, gsync is flawless in that aspect, 0 stuttering compared to using opengl or vulcan.

 

[therealnickdanger]

No impact on my machine - but I wasn't really expecting one.
3570K @ 4.2GHz
GTX 970

1080p: 125fps
4K: 95fps
Ultra settings, exclusive fullscreen, no vsync.

No noticeable change in visual quality, fps, or stuttering between stock and Vulkan.

 

[MajinCry]

Limiting fps or vsync on/ff does nothing, gsync is flawless in that aspect, 0 stuttering compared to using opengl or vulcan.

No, that ain't true in the slightest.

If you're rapidly jumping from 40fps to 45fps (can just be every couple of seconds), it's going to feel like a stuttery mess. Cap it to 40fps, and it's going to feel smooth.

Chuck in VSync with Triple Buffering, and oh baby.

Bit odd that you're comparing a monitor feature, that's independent of the graphical API being used, with a graphical API, though.

 

[jabroni619]

Why is it so far behind in The Talos Principle?

Considering that historically, the slowest API is doing by far the best in that game, I'd say they've spent very little time developing for Vulkan and OGL compared to DX

 

[S.H.O.D.A.N.]

Valve really need to update their engine. Its like 10 years old.

Dota 2 is running on Source2, an engine introduced in 2015.

 

[Thala]

Limiting fps or vsync on/ff does nothing, gsync is flawless in that aspect, 0 stuttering compared to using opengl or vulcan.

Thats just wrong. gsync is just a trade-off but far from perfect. Issue is, gsync displays the frame when it is finished, however the frame is not necessarily finished when the game engine intended the frame to be displayed.
In essence the game engine makes a prediction when the next frame is to be displayed and transforms the geometry accordingly. When the prediction is wrong you see stutter, even with gsync.
In order to avoid wrong predictions you need to enable vsync and make sure each frame is computed within the time limits of the refresh rate. In this case the game engine will always predict correctly and you will see a perfectly smooth animation, which would not be possible with gsync.

 

[railven]

Optimization is probably ongoing as with the talos principle.

Hopefully Vulkan isn't coming out of the oven premature ala DX12.

Need more devs to jump on these APIs. It's getting boring.

 

[Raising]

Thats just wrong. gsync is just a trade-off but far from perfect. Issue is, gsync displays the frame when it is finished, however the frame is not necessarily finished when the game engine intended the frame to be displayed.
In essence the game engine makes a prediction when the next frame is to be displayed and transforms the geometry accordingly. When the prediction is wrong you see stutter, even with gsync.
In order to avoid wrong predictions you need to enable vsync and make sure each frame is computed within the time limits of the refresh rate. In this case the game engine will always predict correctly and you will see a perfectly smooth animation, which would not be possible with gsync.

I've never seen any stuttering in any game with gsync on and can notice it as soon as it's off.

This is on a xb270hu monitor with two 980tis.

 

[SPBHM]

the most interesting thing on this test is the 980 ti result for DirectX11 vs OpenGL...

 

[sirmo]

the most interesting thing on this test is the 980 ti result for DirectX11 vs OpenGL...

Yup, the trend of AMD's cards aging better will continue until Nvidia releases a new architecture.

 

[antihelten]

In replays the system already knows what comes next so you can channel all your resources into rendering frames,in real time gaming the card has to wait for input from all players to know what to do next.
At least that's my thinking,if someone with lots of cores could tell us CPU utilization difference between real play and replay we could make sure.

Yay,works as promised,no driver thread=the other threads get to share the freed up resources=moar FPS.
https://www.youtube.com/watch?v=-cDAWW8nkGU

That still doesn't explain why the faster CPU would see the bigger improvement.

If the replay system works as you described, then it would simply lower the CPU load on both system, which should primarily benefit the slower CPU (since this is the one being CPU bottlenecked).

One possible explanation might be that the DX12 implementation of DOTA 2 can scale to more threads than the DX11 implementation. For instance 8 threads instead of 4 threads. This would only be an advantage for the i7 CPU, since the x4 CPU is limited to running 4 threads at a time either way (only 4 cores and no SMT).

 

[digitaldurandal]

I've never seen any stuttering in any game with gsync on and can notice it as soon as it's off.

This is on a xb270hu monitor with two 980tis.

But Gsync is designed to eliminate tearing not stuttering. You could still have a quick change from 100 to 40 fps and notice it.

Why are we on about Gsync in a Vulkan thread? We should start a new thread if you want to continue to conversation I would think.

 

[Headfoot]

But Gsync is designed to eliminate tearing not stuttering. You could still have a quick change from 100 to 40 fps and notice it.

Why are we on about Gsync in a Vulkan thread? We should start a new thread if you want to continue to conversation I would think.

No, gsync and freesync are definitely for stuttering. You notice the transition between 100 to 40 but its much less jarring on a X-sync monitor, and you can't notice even 15 fps swings at high enough FPS. Between 45ish and 70ish is remarkably smooth compared to running with it off. Once you start getting closer to the 30 to 40 range though even x-sync doesn't help much since you just have so little to work with. This is from my experiences with a Nixeus VUE24 which has 30-144hz freesync on it. I hope the new APIs dont rule out continuing to use adaptive sync techs

 

[TheELF]

One possible explanation might be that the DX12 implementation of DOTA 2 can scale to more threads than the DX11 implementation. For instance 8 threads instead of 4 threads.
This would only be an advantage for the i7 CPU, since the x4 CPU is limited to running 4 threads at a time either way (only 4 cores and no SMT).

It's not just about the number of threads but also about how much work each thread gets to complete in a given time,even though the x880 and a i5 have the same amount of cores each of the i5s cores is much faster.
Because replay is basically a rendering software like cinebench it is very probable that it can use as many cores as there are available.

Anyways,like I said we need someone with a lot of cores to show us the threads of game vs replay if we are to make any sense out of this.

 

[antihelten]

It's not just about the number of threads but also about how much work each thread gets to complete in a given time,even though the x880 and a i5 have the same amount of cores each of the i5s cores is much faster.
Because replay is basically a rendering software like cinebench it is very probable that it can use as many cores as there are available.

Anyways,like I said we need someone with a lot of cores to show us the threads of game vs replay if we are to make any sense out of this.

The total amount of work that needs to be done per frame ought to be the same for both CPUs and thus if they are running the same number of threads (4 or less), then the work per thread per frame should also be the same.

Also this shouldn't have anything to do with per core performance either. Yes and i7 is obviously faster than an x880 per core, but it is faster per core in both DX11 and DX12, the per core performance shouldn't change based on the API.

So the only way that I can see the i7 (not i5) benefitting more from DX12 than the x880, is if the workload is spread across more than 4 threads (where the i7 can then benefit from SMT).

Also this has nothing to do with it being a replay, since it's obviously also a replay with DX11, so no difference there. This doesn't mean that it behaves similarly ingame of course.

 

[TheELF]

The total amount of work that needs to be done per frame ought to be the same for both CPUs and thus if they are running the same number of threads (4 or less), then the work per thread per frame should also be the same.

Yes the work that's needed to be done is the same,so if one 4core machine has twice the speed (per core) it will finish it in half the time of the other 4core machine.
(or do twice the work in the same time)

Also this shouldn't have anything to do with per core performance either. Yes and i7 is obviously faster than an x880 per core, but it is faster per core in both DX11 and DX12, the per core performance shouldn't change based on the API.

The per core performance doesn't change based on the API,but!
Dx11 has to use brute force cpu single thread power to get it's work done,with dx12,and probably vulkan as well,the same load can be split up into several threads (each one will still relay on brute force cpu single thread power but it can use more cores)

Also this has nothing to do with it being a replay, since it's obviously also a replay with DX11, so no difference there.

Yes but Dx11 is still able to use only one of the i7(or any CPU) cores while vulkan can (up to) quadruple the processing power. ( +whatever HT contributes)



The only question is if vulkan can use all available processing power even while really gaming or only if it already has all the data available,like in a replay, so it can render full speed since it doesn't have to wait for anything.

 

[antihelten]

Yes the work that's needed to be done is the same,so if one 4core machine has twice the speed (per core) it will finish it in half the time of the other 4core machine.
(or do twice the work in the same time)

I'm not sure if you understand my point here. The issue isn't how much faster an i7 is compared to an x880 per core. The issue is how much their total performance improved going from DX11 to DX12.

Looking at the Nvidia results, the x880 improves by 12.6%, whereas the i7 improves by 23.5%. So the relative gap grew by 9.7%, whereas normally we would expect it to shrink from DX12 (due shifting the bottleneck from the CPU to the GPU)

The per core performance doesn't change based on the API,but!
Dx11 has to use brute force cpu single thread power to get it's work done,with dx12,and probably vulkan as well,the same load can be split up into several threads (each one will still relay on brute force cpu single thread power but it can use more cores)

That's what I've been saying all along. The higher DX12 scaling from the i7 must be due to an increase in the number of active threads (to more than 4 threads).

Yes but Dx11 is still able to use only one of the i7(or any CPU) cores while vulkan can (up to) quadruple the processing power. ( +whatever HT contributes)

I don't see any evidence that DX11 can only make use of 1 core, nor that Vulkan can only make use of 4 cores (quadruple). In fact the test results would seem to rule this out completely. If the game went from 1 thread to 4 threads, then the i7 and the x880 should have seen a similar increase in performance (since both are quad cores). Only if the game goes above 4 threads would the i7 have a distinct advantage (due to SMT).

The only question is if vulkan can use all available processing power even while really gaming or only if it already has all the data available,like in a replay, so it can render full speed since it doesn't have to wait for anything.

Live gameplay benchmarks would be nice, but given the variable nature of the game, it might be a bit tricky to acquire.