More AMD RadeonSI Improvements Land In Mesa Git

[dungeon]

Yeah, this is my actual situation. I'm using those packages, but, you know, building yourself is more satisfying.

Well it is, but building llvm can be also time consumpator that is why i used that repo most of the time I will lose 1 hour daily just to build llvm two times on Athlon 5350 .

[lorenzoz]

Well it is, but building llvm can be also time consumpator that is why i used that repo most of the time I will lose 1 hour daily just to build llvm two times on Athlon 5350 .

O_O wow.

I've compiled LLVM maybe 4-5 times today, to find out what's going on and take me 10min on a [email protected].

#!/bin/bash
cd /build/llvm &&
git reset --hard &&
git clean -xdf &&
git pull &&
./configure --build=i686-linux-gnu \
--prefix=/usr \
--disable-assertions \
--enable-shared \
--enable-optimized \
--with-optimize-option=' -g -O2' \
--enable-libffi \
--enable-shared \
--disable-bindings \
--enable-targets=r600 \
--libdir=/usr/lib/i386-linux-gnu &&
pkgversion=$(git log -n 1 | grep git-svn-id | cut -c 62-68) &&
make -j8 &&
fakeroot checkinstall --install=yes --pkgname=llvm32 --pkgversion=$"{pkgversion}" --pkgarch=i386 --backup=no --nodoc --default &&
mv -- ./*.deb /build/completed || exit $?
exit 0

Well, I'll try to dig more.
Thank you.

[dungeon]

O_O wow.

I've compiled LLVM maybe 4-5 times today, to find out what's going on and take me 10min on a [email protected].

Just do 'make -j2' on your CPU and you will feel my pain

[Marc Driftmeyer]

I'm running debian sid.

But I prefer to have my own build so I can bisect and file bugs.

Then why run chroot when you can install locally or /opt or wherever you want the path to be referenced.

[Marc Driftmeyer]

O_O wow.

I've compiled LLVM maybe 4-5 times today, to find out what's going on and take me 10min on a [email protected].

#!/bin/bash
cd /build/llvm &&
git reset --hard &&
git clean -xdf &&
git pull &&
[B]./configure --build=i686-linux-gnu \[/B]
--prefix=/usr \
--disable-assertions \
--enable-shared \
--enable-optimized \
--with-optimize-option=' -g -O2' \
--enable-libffi \
--enable-shared \
--disable-bindings \
--enable-targets=r600 \
--libdir=/usr/lib/i386-linux-gnu &&
pkgversion=$(git log -n 1 | grep git-svn-id | cut -c 62-68) &&
make -j8 &&
fakeroot checkinstall --install=yes --pkgname=llvm32 --pkgversion=$"{pkgversion}" --pkgarch=i386 --backup=no --nodoc --default &&
mv -- ./*.deb /build/completed || exit $?
exit 0

Well, I'll try to dig more.
Thank you.

Seriously? What reason do you have not to tune your arch and tune to -march=bdver2 -mtune=bdver2?

[Nobu]

Seriously? What reason do you have not to tune your arch and tune to -march=bdver2 -mtune=bdver2?

Not sure what debian's default build flags are, but regardless, it's easier to say something is a bug in the program rather than your build tools if you use the same configuration when building. Otherwise? Some things actually perform better with less aggressive compiler options. Don't know about llvm, specifically, though.

[duby229]

Not sure what debian's default build flags are, but regardless, it's easier to say something is a bug in the program rather than your build tools if you use the same configuration when building. Otherwise? Some things actually perform better with less aggressive compiler options. Don't know about llvm, specifically, though.

I tend to agree with you. If the software is only going to be running on the same machine that built the software, then it's ok to use -march=native. If you're expecting to distribute a binary then what you're doing is fine.

Otherwise ricing gcc is a whole different matter from tuning for the architecture. Ricing gcc is a term used to describe using excessive compiler to flags to "optimize" the code. There are plenty of benchmarks that show little difference in actual performance between a riced built and a stock build.

[dungeon]

Some things actually perform better with less aggressive compiler options. Don't know about llvm, specifically, though.

It has default -O3 for linux while -O2 perform a little bit faster when mesa driver use it (might be faster with -O3 for clang i dunno), so yeah it is true for llvm too

From my experience those compiler optimizations does not bring anything good when it comes to drivers. For mesa a like to recommend even -O1 if someone wants most of stability together with performance.

And i recommends -Ofast if someone wants most of performance and broken driver Joking a little , do NOT use that for mesa nor llvm !!!

While i recommend using -march=native -mtune=native (this one in particular) for 3bit mesa radeon build because of bugs likely in toolchain.

[geearf]

While i recommend using -march=native -mtune=native (this one in particular) for 3bit mesa radeon build because of bugs likely in toolchain.

Isn't mtune redundant once you have set march to native anyway?

[lorenzoz]

Then why run chroot when you can install locally or /opt or wherever you want the path to be referenced.

I want to keep my main system clean (without compiling stuff) so I decided to use 2 chroot (64bit and 32bit).

Seriously? What reason do you have not to tune your arch and tune to -march=bdver2 -mtune=bdver2?

I've just found these compiling options in oibaf repository, not tuned yet. (except for --enable-targets=r600)