Comment by magicalhippo
2 months ago
Very interesting that the Cyberpunk 2077 results showed 28% performance improvements as well as a 25% increase in battery life.
Often better performance is due to more efficient use of hardware, which comes at an energy cost. Other times it allows the hardware to work more efficiently, like avoiding spinning on locks.
When seeing numbers like that I always wonder about the probability of the engines truly running the same feature set: not because I doubt that an alternative implementation can be faster (I don't) and certainly not because I'd want to accuse anyone of trickery, but because those software stacks are just so very, very complex and adaptive and minor (but, perhaps, costly in fps) adaptions of the engine parametrization to the runtime environment can be very difficult to spot by looking at the output. I'd imagine the relationship between the code and what's actually happening must be almost as wild and unpredictable as what we see in epigenetics.
How would the engines be running differently? It’s quite literally the same Windows build of the game running on Wine/Proton.
The simpler explanation is that Windows is poorly optimized, and runs a ton of inefficient crap in the background that’s taking cycles away from the CPU and maybe even GPU.
I can imagine the feature set the native Windows driver advertises is different from the feature set DXVK reports. If DXVK doesn't support or implement certain features that the engine then doesn't request of it (or if the API call translates to a noop), you could quite easily end up in a scenario where graphic fidelity is lowered, accidentally boosting battery life and performance. There were bugs where certain games wouldn't render certain shadows, for instance, which might not get noticed but still offers an accidental performance uplift.
1 reply →
My understanding is there are two performance differences here, one is vulkan outperforming DirectX, and one is reduced overhead on linux vs windows.
The Vulkan difference can actually be achieved on windows as well, by using DXVK on windows.
The overhead difference is most seen on the lighter games, like Dead Cells and Hades. It's why we see such massive increases in battery life for those games.
I think one of the answers here may be nVidia related. CP2077 is one of those games with a ton of "optimized for/by nVidia" magic with the nVidia driver injecting a lot of its own GPU/CPU code adjustments into the game. Given the Linux nVidia driver is a fraction of the size of the Windows driver I've long assumed there's a lot less "optimized" code being sent to the Linux side than the Windows side. It's interesting to wonder if it is because Linux needs it less or if Windows is still the flagship for "most features"/"best graphics" for nVidia so DirectX gets all the attention.
1 reply →
Even on same builds, I could see some calls being performed, and the translation while functionally equivalent, not quite computationally equivalent
It doesn't even have to be worse, just different
1 reply →
That would be plausible if the effect was only seen in one game, or a small handful. Instead it's happening across the board, with almost all games tested showing at least some gain, and many showing gains comparable to CP2077.
At that point it has to be a platform/stack difference.
The CP2077 framerate is 59, so it's probably effectively running at 60FPS, or is CPU-limited instead of GPU-limited. If the graphics side of things has spare headroom it's going to draw less power.
On the flip side, the CPU may be doing less work due to things like more efficient drivers / less OS nonsense tying up CPU, which would also reduce power draw.
> better performance is due to more efficient use of hardware, which comes at an energy cost
It's a matter of balance.
More efficiency means less power for the same computations. If you increase the computations more than your gain in performance, you use more power. If your efficiency gains are not fully utilised by increased computations, you use less power.
What I was getting at was that if you have a CPU bottleneck, reducing or removing that bottleneck can make your GPU work harder, which results in more frames per second but also more energy because GPU isn't idle as much.
This would be in contrast to say wasting a lot of cycles in a spin lock due to thread contention, where reducing or removing the contention might gain you both performance and lower energy cost due to less waste.