Originally posted by nuetzel
View Post
Announcement
Collapse
No announcement yet.
Mesa Developers Discuss LTO'ing + PGO'ing Builds For Greater Performance
Collapse
X
-
Originally posted by nuetzel View Post
Yep, Dieter here.
If 'you' need my 'instructions' or more numbers go, here:
https://lists.freedesktop.org/archiv...ry/224096.html
Yes, of course I need it - I'm greedy - thank you for sharing
Comment
-
Originally posted by QwertyChouskie View PostTo work around legal issues, API traces of software like SuperTuxKart/Xonotic/0AD/open benchmarks/etc. could be used.
Comment
-
Originally posted by QwertyChouskie View PostTo work around legal issues, API traces of software like SuperTuxKart/Xonotic/0AD/open benchmarks/etc. could be used.
- Likes 1
Comment
-
Originally posted by dcbaker View Postoibaf, CochainComplex, with meson you really want to use the builtin instead of passing -flto manually, `meson builddir -Db_lto=true`. That way if the build system wants to make decisions based on lto you can, and its portable to other compilers.
Comment
-
Originally posted by nuetzel View Post
That was my idea. @Michael?
I'm under the impression that we needn't 'all' my used progs.
But I have to test with one more OpenGL (DiRT Rally) and 2 (+) Vulkan games (SotTB + F1 2017).
What we have to know next is if we could use a collection of training data for multiple CPUs. @Honza?
For GCC 10 I added -fprofile-partial-train-run which instruct GCC to not optimize for size functions never executed during the train run (it simply assumes that profile is missing). Also it possible to disable profiling for code that you can not train well. There is no_instrument attribute or simply do not use -fprofile-generate for units that contains hardware specific code that you do not intend to train.
- Likes 6
Comment
-
Originally posted by nuetzel View PostIf 'you' need my 'instructions' or more numbers go, here: https://lists.freedesktop.org/archiv...ry/224096.html
- Likes 2
Comment
Comment