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!
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
- Steam Controller 2 is apparently a thing and being 'tooled for a mass production' plus a new VR controller
- Dungeon Clawler will grab hold of your free time now it's in Early Access, plus keys to give away
- Monster catcher Cassette Beasts adds Steam Workshop support and a new battle mode
- Steam getting proper Season Pass support with clearer guidelines and refunds for cancellations
- FromSoftware owner Kadokawa confirms Sony sent an 'initial letter of intent' to acquire them
- > See more over 30 days here
-
Action-platformer metroidvania Janosik 2 will be a 'big…
- Pikolo -
2K Launcher is finally no more - that's at least one pu…
- Marlock -
2K Launcher is finally no more - that's at least one pu…
- Kuduzkehpan -
GOG's Black Friday Sale is live now with some big disco…
- Liam Dawe -
GOG's Black Friday Sale is live now with some big disco…
- hummer010 - > See more comments
- More updates - social media related
- Klaas - What have you been listening to?
- Liam Dawe - What do you want to see on GamingOnLinux?
- Linux_Rocks - Our own anti-cheat list
- Liam Dawe - Weekend Players' Club 11/22/2024
- Liam Dawe - See more posts
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 LTSKernel: 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.10Kernel: 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
With regards to your crash, you could try setting several CPU cores to offline by doing
echo 0 > /sys/devices/system/cpu/cpuX/onlinewhere 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.
That's a good hint. I'll try it later.
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
It worked! Thank you so much for your support.
Cheers,
Dave
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