meson has buildtins for both of these, -Db_lto=true turns on lto, for pgo you
would run:
meson build -Db_pgo=generate
ninja -C build
meson configure build -Db_pgo=use
ninja -C build
Quoting Marek Olšák (2020-02-12 10:46:12)
> How do you enable LTO+PGO? Is it something we could enable by default
On 2020-02-12 7:46 p.m., Marek Olšák wrote:
> How do you enable LTO+PGO? Is it something we could enable by default for
> release builds?
Enabling LTO for Mesa, I get a lot of warnings about issues affecting it
specifically, making me doubt that it's currently safe in general, in
particular for
Hi,
On 13.2.2020 10.38, Timur Kristóf wrote:
I think the question about PGO is this: are the profiles of the users'
applications gonna be the same as the profile that is collected from
the benchmarks?
Eg. if the test benchmark uses different draw calls or triggers
different shader compiler
I think the question about PGO is this: are the profiles of the users'
applications gonna be the same as the profile that is collected from
the benchmarks?
Eg. if the test benchmark uses different draw calls or triggers
different shader compiler code paths than a your favourite game, in
theory
Can we automate this?
Let's say we implement noop ioctls for radeonsi and iris, and then we run
the drivers to collect pgo data on any hw.
Can meson execute this build sequence:
build with pgo=generate
run tests
clean
build with pgo=use
automated as buildtype=release-pgo.
Marek
On Wed., Feb.
Hello Marek,
I hoped you would ask this...
...but first sorry for the delay of my announced numbers.
Our family is/was sick, my wife more than me and our children are fine,
again.
So be lenient with me somewhat.
Am 12.02.2020 19:46, schrieb Marek Olšák:
How do you enable LTO+PGO? Is it
On 2/12/20 10:46 AM, Marek Olšák wrote:
> How do you enable LTO+PGO? Is it something we could enable by default
> for release builds?
I'm assuming PGO is "profile guided optimization." That requires a
cycle of build, run workloads to collect data, rebuild with collected
data. It would be
How do you enable LTO+PGO? Is it something we could enable by default for
release builds?
Marek
On Wed, Feb 12, 2020 at 1:56 AM Dieter Nützel wrote:
> Hello Gert,
>
> your merge 'broke' LTO and then later on PGO compilation/linking.
>
> I do generally compiling with
Hello Dieter,
Am Mittwoch, den 12.02.2020, 10:53 +0100 schrieb Gert Wollny:
>
> When I enable radeonsi linking libgallium_dri.so seems to take
> forever, that is so far it is not finished and it is running for
> quite some time (>15 min). I'll get back to you when I get some
> result.
For me
Hello Dieter,
thanks for the report.
Am Mittwoch, den 12.02.2020, 07:56 +0100 schrieb Dieter Nützel:
>
> After your merge I get several warnings in 'addrlib' with LTO
As far as I can see the offending structs are contained in a union
GB_ADDR_CONFIG which is only define within radeonsi, so
Hello Gert,
your merge 'broke' LTO and then later on PGO compilation/linking.
I do generally compiling with '-Dgallium-drivers=r600,radeonsi,swrast'
for testing radeonsi and (your) r600 work. ;-)
After your merge I get several warnings in 'addrlib' with LTO and even a
compiler error (gcc
Am Donnerstag, den 23.01.2020, 20:31 +0100 schrieb Gert Wollny:
> has anybody any objections if I merge the r600/NIR code?
> Without explicitely setting the debug flag it doesn't change a
> thing, but it would be better to continue developing in-tree.
Okay, if nobody objects, I'll merge it
12 matches
Mail list logo
