NVIDIA vs. AMD OpenGL & Vulkan Benchmarks With Valve's Dota 2

[liamdawe]

Sure, there are two timedemos I have been using for my testing. The first is from a match from the Global eSports Cup Finals: https://app.box.com/s/cb630qqnftmxuv3twbpf9celqe8l673s

I use the command-line:

dota2 [-vulkan | -gl] +timedemo 1971360796 +timedemo_start 50000 +timedemo_end 51000 +cl_showfps 2 +fps_max 0 -novconsole -noassert -nosound

The other timedemo which is a very heavy battle scene from the Frankfurt Majors and tends to be quite CPU limited: https://app.box.com/s/pd01jt9nlqc8dmjhyctl4rlmlt6jb0p1

For this one I use the command-line:

dota2 [-vulkan | -gl] +timedemo OctPerf +timedemo_start 46800 +timedemo_end 47000 +cl_showfps 2 +fps_max 0 -novconsole -noassert -nosound

Got it to work, wrote a small guide for anyone not using PTS:
https://www.gamingonlinux.com/articl...-to-do-it.7435

[F1esDgSdUTYpm0iy]

And why do you think is the VRAM usage increased that it does not even start with some cards?

Poor optimization?

[Kano]

And why do you think is the VRAM usage increased that it does not even start with some cards?

[F1esDgSdUTYpm0iy]

Vulkan does not magically increase speed

Well, obviously not but it does provide the game's developers with a sophisticated toolbox to accomplish exactly that -- improving performance. Pre-DX12 DX versions as well as OpenGL are severely hampered by very hard limitations on what can be accomplished in the area of clever and well executed code design. I'm a firm believer Vulkan will in fact prove to be the way forward for gaming, particularly given the fact that CPU and GPU design are starting to run into physical limitations as well.

More and more, the future of computing in general and gaming in particular will have to come from extreme multithreading. Which is why the recent paper on Linux's need for better scheduling is so important as well. All these cogs will have to come together to form a single, well-oiled machine to really give us that evolutionary leap in computing that's almost within reach.

[Kano]

Vulkan does not magically increase speed, it needs clever game engines that handle multithreading on their own. A "simple" D3D to GL wrapper however is limited by 1 CPU core. This is why many Linux benchmarks are CPU limited especially at lower res - the results are too similar in that case. I think Vulkan support needs too much VRAM right now, especially Dota 2 with Nvidia cards. This can not be the final optimization point - but shows the way. I would not interpret too much in this beta, maybe after some updates - as soon as the devs use not only highend GFX cards to compare.

[F1esDgSdUTYpm0iy]

I will in fact answer you question, since you clearly don't have a grasp of it, and hopefully you'll appreciate my answer.

You're the one clearly not having a grasp of something; of my point. And, if my point somehow escapes you, be a man about it instead of hiding behind contempt. Thank you very much.

My point was simple and I'm going to go ELI5 here for you, just for you -- There is literally no reason NOT to switch to Vulkan. For any game. CPUs do not have an infinite number of cores, do not have an infinite ipc per core. Anything that frees up CPU cycles is a good thing. Be it directly or indirectly, any task you perform on a system will benefit from a CPU that is not completely tied up doing other stuff.

Quit being stuck on my singular example, tunnel vision is never a good thing. In any situation in life.

[RussianNeuroMancer]

I think what we need here is Vulkan vs. GL tests on integrated and low/middle GPUs in pair with low/middle CPUs.

[efikkan]

Regardless, even if it wouldn't help the title itself, it would at least improve the responsiveness of the OS and the OS' subsystems; again, by freeing up CPU time. This alone should improve the gameplay experience; a responsive, low latency OS does make for a more competitive toolbox.

Improving efficiency is always good, especially these days as CPUs are not really progressing that much and software is becoming increasingly bloated.

Then why, I wonder, not one but 2 multithreaded graphics APIs (DX12 and Vulkan) that aim to reduce CPU load? No, no need to answer. It's mostly meant in a rhetorical fashion. Seriously, don't answer the question.

I will in fact answer you question, since you clearly don't have a grasp of it, and hopefully you'll appreciate my answer.

You were describing a game where the simulation slowed down but the rendering was unaffected, this would mean that one thread has the GPU context and another one is doing the simulations independently. Assuming that you run this game on a CPU with at least two cores, improving one of them is not going to affect the other. So even if you rewrote the rendering to use an API with a lower overhead, or just optimized the rendering in general, as long as the simulation is your bottleneck any improvement in the other thread wouldn't help this problem.

"Multithreading" in Direct3D 12 and Vulkan is about two things:
1) Multithreading within the driver
2) Multiple threads with GPU context
Again, since your bottleneck is not in the thread with GPU context, neither will help here. (2) is in fact primarily intended for cases where you want two independent workloads on the GPU (let's say particle simulation and rendering in two different queues). Having many cores interfacing with one queue doesn't improve performance, and definitely would do nothing to improve the scenario you described. Freeing up resources in one CPU cores doesn't add more performance to the other, that's not how multithreading works at all.

The reason why I spend my time explaining this to you is because I see all of you guys having misconceptions and high expectations about the new APIs suddenly is going to "solve everything" in games. This is not the first time, in fact I see this with every Direct3D release. The changes in the APIs are deeply technical and only a programmer would understand, and will nearly always require major overhaul/redesign in game engines to give significant gains.

To get back on topic about optimizing in general. Overhead and bloat is a major problem in most games today, in fact even in most AAA titles. The reason for this is mostly bad engine design, and of course in some cases some limitations to the APIs. Improvements in Direct3D 12 and Vulkan does of course address some of the issues on the API side, but it does nothing for all the shortcomings in the game engine design. When a typical engine abstracts the APIs to a generic rendering API, and then creates a big hierarchy of objects which handle their own rendering and then on top a function which iterates all these objects and invoking their rendering functions, then the overhead becomes massive. The engine overhead itself can easily be ten times the overhead of the API. The abstractions also prevents developers from utilizing the new features of an API efficiently (compared to an optimized rendering pipeline with efficient batching), so it kind of defeats the purpose with a "low-level" API when you shove layers and layers of high-level abstractions on top the poor thing.

[F1esDgSdUTYpm0iy]

If a game's frame rate is unaffected by simulation but the simulation somehow is slowing down, then it's already in separate threads and any new API wouldn't do anything to improve the simulation.

Then why, I wonder, not one but 2 multithreaded graphics APIs (DX12 and Vulkan) that aim to reduce CPU load? No, no need to answer. It's mostly meant in a rhetorical fashion. Seriously, don't answer the question.

Regardless, even if it wouldn't help the title itself, it would at least improve the responsiveness of the OS and the OS' subsystems; again, by freeing up CPU time. This alone should improve the gameplay experience; a responsive, low latency OS does make for a more competitive toolbox.

[efikkan]

And my point was -- You actually do. For me, Prison Architect will never stop rendering at its normal pace but the simulation will slow down to a crawl beyond a certain point. Same with other sandbox titles and the same applies to literally thousands upon thousands of people playing said titles; the graphics subsystem of the game will still be performing as expected but the simulation subsystem will start bogging down at a certain point.

If a game's frame rate is unaffected by simulation but the simulation somehow is slowing down, then it's already in separate threads and any new API wouldn't do anything to improve the simulation.

On the other hand if a game's simulation is tied to the frame rate and vice versa, then the game engine is an inferior design. Then the solution is moving the simulation into a separate thread freeing up the render thread to do just rendering.

Either way, Vulkan wouldn't do much of a difference here.