Trine 3 [GOG version] takes 50 seconds to load on first run (empty shader cache). On subsequent runs, it takes 25 seconds (apparently since shader cache is already populated). Also, the CPU is loaded for me around 25% during game starting, so it looks like shader compilation doesn't utilize all available cores. OS: Debian testing x86-64 GPU: AMD RX480 / 4GB VRAM CPU: Intel Core i7 4770 (3.40GHz) / 16GB RAM OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.8.0 / 4.9.0-2-amd64, LLVM 3.9.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.0-devel (git-af73acca2b)
25 second compile time is not all that bad. This far from the worse example of compile times in Mesa. I'm tempted to close this bug as I'm not convinced there is anything special about Trine 3 here. Are you able to use the perf tool to see where in the compiler we are spending lots of time? Or at the very least grab an apitrace [1] of the game at startup and upload it somewhere so that I can use this to take a quick look. [1] https://github.com/apitrace/apitrace/wiki/Steam
Created attachment 131110 [details] apitrace of Trine 3 (empty mesa cache) This is a trace with empty mesa cache, Mesa 17.1.0-devel (git-af73acca2b). I interrupted it right before it hit 50 seconds, in order to prevent it from bloating up.
Just for the reference, this is GOG, not Steam version, I don't know if they differ.
Created attachment 131111 [details] apitrace of Trine 3 (empty mesa cache) A trace with already filled mesa cache, Mesa 17.1.0-devel (git-af73acca2b). I interrupted it a couple of seconds before it hit 25 seconds.
Sorry, wrong description in the second attachment. It should say: apitrace of Trine 3 (filled mesa cache).
Thanks for the trace. However taking a look, there is nothing here that is taking an abnormal amount of cpu, its well know that compile times are not as good as we would like in Mesa, but this is an ongoing process. I don't see any need to keep this bug open.
(In reply to Timothy Arceri from comment #6) > its well know that compile times are not > as good as we would like in Mesa, but this is an ongoing process. Is there a plan to make compilation more parallelized when the processor allows it?
The radeonsi backend already does this where possible. The glsl compiler front end is not currently thread safe, there have been a couple of attempts at this over the years but I don't think anyone is working on this currently.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.