Mesa Developers Discuss LTO'ing + PGO'ing Builds For Greater Performance

[pal666]

I do not think this is right.
We optimize the (CPU) setup code.

cpu code does different things for different card models and different games

[CochainComplex]

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

[soulsource]

To work around legal issues, API traces of software like SuperTuxKart/Xonotic/0AD/open benchmarks/etc. could be used.

The free games probably only use parts of the code. I have my doubts that very new or lesser known OpenGL extensions would ever get profiling data from them.

[CochainComplex]

To work around legal issues, API traces of software like SuperTuxKart/Xonotic/0AD/open benchmarks/etc. could be used.

Do you really expect legal issues? following this logic game mods should be illegal too. same with shared shadercaches.

[oibaf]

oibaf, 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.

Nice catch, will do, thanks.

[hubicka]

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?

There is nothing CPU specific in the profile feedback, so it does not optimize for specific CPU. However if you train on CPU with one ISA extension (say non-AVX CPU), mesa contains AVX specific code and you will run at AVX enabled CPU performance will not be great because you will end up with AVX path optimized for size not speed.

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.

[CochainComplex]

might be a bit OT but did one of you get PGO working for DXVK compilation?

[FireBurn]

might be a bit OT but did one of you get PGO working for DXVK compilation?

I can't even get -march=native to work for DXVK, I had to strip it from my ebuilds

[CochainComplex]

I can't even get -march=native to work for DXVK, I had to strip it from my ebuilds

it uses a cross compiler (I think march=native does not work here). I was able to compile it with march=bdver2 and march=skylake and flto.

[kcrudup]

If 'you' need my 'instructions' or more numbers go, here: https://lists.freedesktop.org/archiv...ry/224096.html

I just wanted to tell you thanks for those- I'm now running an LTO-PGO Mesa on my IceLake machine!