Confused on Steam Play and Proton? Be sure to check out our guide.
Quantum Break on Wine
LordDaveTheKind Oct 29, 2018
hello,
few months ago I went across a videogame with an interesting storyline: Quantum Break. I decided to give it a try, and installed it on my gaming laptop, an ASUS ROG with the following specs:

Distro: Ubuntu 18.04.1 LTS
Kernel: 4.15.0-38-generic
RAM: 16 GB
GPU Driver: NVIDIA 396.54
GPU: NVIDIA GeForce GTX 960M
CPU: Intel Core i7-6700HQ @ 2.60GHz


The game was actually running, but very slowly, as you could expect from that GPU. After few weeks, I decided to upgrade my domestic setup with a proper gaming computer, with the following specs:

Distro: Ubuntu 18.10
Kernel: 4.18.0-10-generic
RAM: 64 GB
GPU Driver: NVIDIA 396.54
GPU: NVIDIA GeForce GTX 1080 Ti
CPU: AMD Ryzen Threadripper 2990WX 32-Core


Definitely more than an adequate computing power for gaming purposes. All the games I tried so far run amazingly in this new architecture (with relieving and sometimes arousing 1080p at 60fps with ultra graphics settings), but surprisingly Quantum Break instead is the only one that doesn't start at all.
In particular, the game crashes immediately at startup, and I get the following unhandled exception from the game main executable:

R_ASSERT( Havok Error (id 0xf03454fe)
Memory\System\FreeList\hkFreeListMemorySystem.cpp (100): Too many threads )
File: Memory\System\FreeList\hkFreeListMemorySystem.cpp
Line: 100

Reason: Too many threads


Has anyone of you experienced this kind of issue before? I tried with several versions of Wine (Proton/SteamPlay or a vanilla Wine + DXVK), but all of them seem to get the same error.

Imho, it looks to me more a CPU issue than a GPU one (is the only main difference I can spot between the two architectures above), and it has been reported also by some players running the game in Windows. What workarounds could be available on this kind of issues?

Cheers,
Dave
YoRHa-2B Oct 29, 2018
The issue is quite simple: Quantum Break is retarded.

With regards to your crash, you could try setting several CPU cores to offline by doing
echo 0 > /sys/devices/system/cpu/cpuX/online
where X is the number of the logical CPU core you want to disable. On your Threadripper, keeping 0-15 online and disabling 16-63 should be fine, you'd effectively end up with a Ryzen 2700-like CPU configuration.


As for performance, here's how a normal game creates a texture:
1. Create the texture and pass in the image data using the pInitialData parameter.

Here's how Quantum Break creates a texture:
1. Create the texture, but don't initialize it with data.
2. For each mip level,
- a) Create a temporary image with the size of the mip level. Again, don't initialize it with data.
- b) Map the temporary image to host memory and explicitly write the image data to it.
- c) Issue a GPU command to copy the temporary image to the actual texture.
- d) Delete the temporary image.

Every time we reach b), DXVK has to do a CPU<>GPU synchronization because it has to wait for the temporary image to be initialized on the GPU. And Quantum Break does that several dozen times per frame. There's no way I can optimize that mess in DXVK, and I'm amazed that native D3D11 drivers can make sense of it.

This looks a lot like something that would happen when back-porting a D3D12 renderer to D3D11, but even then, the implementation is terrible.
LordDaveTheKind Oct 30, 2018
Quoting: YoRHa-2BThe issue is quite simple: Quantum Break is retarded.
I had this impression when I played it the first times.

Quoting: YoRHa-2BWith regards to your crash, you could try setting several CPU cores to offline by doing
echo 0 > /sys/devices/system/cpu/cpuX/online
where X is the number of the logical CPU core you want to disable. On your Threadripper, keeping 0-15 online and disabling 16-63 should be fine, you'd effectively end up with a Ryzen 2700-like CPU configuration.
That's a good hint. I'll try it later.

Quoting: YoRHa-2BAs for performance, here's how a normal game creates a texture:
1. Create the texture and pass in the image data using the pInitialData parameter.

Here's how Quantum Break creates a texture:
1. Create the texture, but don't initialize it with data.
2. For each mip level,
- a) Create a temporary image with the size of the mip level. Again, don't initialize it with data.
- b) Map the temporary image to host memory and explicitly write the image data to it.
- c) Issue a GPU command to copy the temporary image to the actual texture.
- d) Delete the temporary image.

Every time we reach b), DXVK has to do a CPU<>GPU synchronization because it has to wait for the temporary image to be initialized on the GPU. And Quantum Break does that several dozen times per frame. There's no way I can optimize that mess in DXVK, and I'm amazed that native D3D11 drivers can make sense of it.

This looks a lot like something that would happen when back-porting a D3D12 renderer to D3D11, but even then, the implementation is terrible.
I can totally understand it: I work in IT as well, and few times it has occurred to me to inspect or review some code written with no knowledge of the best practices for that specific framework/platform.

Anyway, thank you so much for your support, for this clarification and more generally for DXVK. I'll keep you posted for your suggestion above.

Cheers,
Dave
LordDaveTheKind Oct 30, 2018
Quoting: YoRHa-2BWith regards to your crash, you could try setting several CPU cores to offline by doing
echo 0 > /sys/devices/system/cpu/cpuX/online
where X is the number of the logical CPU core you want to disable. On your Threadripper, keeping 0-15 online and disabling 16-63 should be fine, you'd effectively end up with a Ryzen 2700-like CPU configuration.

It worked! Thank you so much for your support.

Cheers,
Dave
LordDaveTheKind Dec 17, 2018
Quoting: YoRHa-2BWith regards to your crash, you could try setting several CPU cores to offline by doing
echo 0 > /sys/devices/system/cpu/cpuX/online
where X is the number of the logical CPU core you want to disable. On your Threadripper, keeping 0-15 online and disabling 16-63 should be fine, you'd effectively end up with a Ryzen 2700-like CPU configuration.

Hi YoRHa-2B,
as the issue seems to be actually common on several games, I tried to set up the limit of CPU usages directly on Steam.
I've just setup the following Steam Launch Option for the specific game:
{any relevant Proton parameter here} taskset --cpu-list 0-3 %command%
and it works surprisingly well.

Thank you so much for the hint.

Cheers,
Dave
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.