Bug 100426 - Trine 3 takes long time to load
Summary: Trine 3 takes long time to load
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-28 03:47 UTC by Shmerl
Modified: 2017-04-28 05:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
apitrace of Trine 3 (empty mesa cache) (8.66 MB, application/x-7z-compressed)
2017-04-28 03:14 UTC, Shmerl
Details
apitrace of Trine 3 (empty mesa cache) (10.15 MB, application/x-7z-compressed)
2017-04-28 03:23 UTC, Shmerl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shmerl 2017-03-28 03:47:49 UTC
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)
Comment 1 Timothy Arceri 2017-04-28 02:25:40 UTC
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
Comment 2 Shmerl 2017-04-28 03:14:19 UTC
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.
Comment 3 Shmerl 2017-04-28 03:15:03 UTC
Just for the reference, this is GOG, not Steam version, I don't know if they differ.
Comment 4 Shmerl 2017-04-28 03:23:11 UTC
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.
Comment 5 Shmerl 2017-04-28 03:24:37 UTC
Sorry, wrong description in the second attachment. It should say: apitrace of Trine 3 (filled mesa cache).
Comment 6 Timothy Arceri 2017-04-28 05:01:40 UTC
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.
Comment 7 Shmerl 2017-04-28 05:08:46 UTC
(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?
Comment 8 Timothy Arceri 2017-04-28 05:33:20 UTC
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.