https://bugs.freedesktop.org/show_bug.cgi?id=100426
Bug ID: 100426 Summary: Trine 3 takes long time to load Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: shtetldik@gmail.com QA Contact: dri-devel@lists.freedesktop.org
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)
https://bugs.freedesktop.org/show_bug.cgi?id=100426
Timothy Arceri t_arceri@yahoo.com.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |t_arceri@yahoo.com.au
--- Comment #1 from Timothy Arceri t_arceri@yahoo.com.au --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #2 from Shmerl shtetldik@gmail.com --- Created attachment 131110 --> https://bugs.freedesktop.org/attachment.cgi?id=131110&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #3 from Shmerl shtetldik@gmail.com --- Just for the reference, this is GOG, not Steam version, I don't know if they differ.
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #4 from Shmerl shtetldik@gmail.com --- Created attachment 131111 --> https://bugs.freedesktop.org/attachment.cgi?id=131111&action=edit 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.
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #5 from Shmerl shtetldik@gmail.com --- Sorry, wrong description in the second attachment. It should say: apitrace of Trine 3 (filled mesa cache).
https://bugs.freedesktop.org/show_bug.cgi?id=100426
Timothy Arceri t_arceri@yahoo.com.au changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTABUG
--- Comment #6 from Timothy Arceri t_arceri@yahoo.com.au --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #7 from Shmerl shtetldik@gmail.com --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=100426
--- Comment #8 from Timothy Arceri t_arceri@yahoo.com.au --- 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.
dri-devel@lists.freedesktop.org