Discussion: the ati/radeon open source drivers & radeon repository

haagch · 2015-09-15 12:54:12

Ironically the repository doesn't work correctly right now IF you have testing enabled, e.g. llvm-config.

As a temporary workaround
sudo ln -s /usr/lib/libncursesw.so.6 /usr/lib/libncursesw.so.5
works, but don't forget to delete it once llvm is updated.

To DRI3: Intel has their own acceleration method, SNA. Dri3 works mostly fine with it.

Last edited by haagch (2015-09-15 12:55:24)

Lone_Wolf · 2015-09-15 13:26:17

Thanks for clarifying intel accel method.

Sounds like the ncurses 6 rebuild has been moved from staging to testing, but LH' repo has't been rebuild to it yet.

Last edited by Lone_Wolf (2015-09-15 13:27:00)

haagch · 2015-09-16 11:37:35

So I have intel+amd hybrid graphics and when I have xf86-video-ati installed, I can't start X anymore. The graphical output just hangs there before switching the graphics mode to X and can't be killed or switched away from.

https://gist.github.com/anonymous/5067d20870657a30a01a

mesa git and xf86-video-ati-git are compiled myself, llvm from the repository. Anyone knows something about that?

Without xf86-video-ati and with dri3 offloading to the radeon gpu everything works well.

Lone_Wolf · 2015-09-16 13:06:43

which repo did you install llvm from , lordheavy' or kerberizer ?

Also did you rebuild mesa-git AFTER updating llvm ?

Last, have you checked wiki on PRIME ?

Last edited by Lone_Wolf (2015-09-16 13:06:56)

lordheavy · 2015-09-16 18:48:08

haagch wrote:

So I have intel+amd hybrid graphics and when I have xf86-video-ati installed, I can't start X anymore. The graphical output just hangs there before switching the graphics mode to X and can't be killed or switched away from.
https://gist.github.com/anonymous/5067d20870657a30a01a
mesa git and xf86-video-ati-git are compiled myself, llvm from the repository. Anyone knows something about that?
Without xf86-video-ati and with dri3 offloading to the radeon gpu everything works well.

I can reproduce this problem, i guess for a mesa regression

haagch · 2015-09-16 19:32:31

Thanks for checking. I hope someone else bisects it, so I don't have to.

@Lone_Wolf: Yes, yes, and it worked fine until today.

edit: Maybe it has to do with all the randr modesetting updates in xf86-video-intel lately.

Last edited by haagch (2015-09-16 19:40:40)

lordheavy · 2015-09-16 20:43:50

haagch wrote:

Thanks for checking. I hope someone else bisects it, so I don't have to.
@Lone_Wolf: Yes, yes, and it worked fine until today.
edit: Maybe it has to do with all the randr modesetting updates in xf86-video-intel lately.

I guess i've found the problematic commit:
http://cgit.freedesktop.org/mesa/mesa/c … 5e39604a95

Please test with at least mesa-git 72834.f5b26b4 , i've reverted the commit

agapito · 2015-09-19 12:11:52

Ambrevar wrote:

Mesa 11 it out!

Mesa 11 is in testing now. Good news. I can play Bioshock Infinite.

lordheavy · 2015-09-22 17:14:49

Middle Earth:Shadow of Mordor is now playable with setting launch option in Steam with "force_glsl_extensions_warn=true MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays %command%"

ChemBro · 2015-09-24 19:59:51

lordheavy wrote:

Middle Earth:Shadow of Mordor is now playable with setting launch option in Steam with "force_glsl_extensions_warn=true MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays %command%"

I'm now using [mesa-git], DRI3 and all that stuff. Man, the open-source driver is good. Though Shadow of Mordor is not "playable" for me. You could say "startable", but all textures are black. :-/

Edit: Oh, okay. I forgot the s3tc support. :-) And wtf?!? The open-source driver is faster in CSGO than Catalyst?

Last edited by ChemBro (2015-09-24 20:10:10)

haagch · 2015-09-24 23:00:15

I thought shadow of mordor requires compute shaders? Do really all shaders compile and work?

(To check, start with MESA_GLSL=dump and then grep -A2 "Compile status: fail" shader_* in the working directory)

ChemBro · 2015-09-25 05:59:13

No, not all shaders work. Well, I don't know about shaders, but rain is missing and it looks a little bit bright, but other than that, it is indeed playable.

EDIT: I posted the video already in the AMD Bar & Grill thread, though I still want to link it here. This is a video about games (with radeonsi driver and of course with the help of the [mesa-git] repo) and how they perform on my setup:

https://www.youtube.com/watch?v=FLesgKSatQ4

I guess, I will never have to use the Catalyst driver anymore.

Last edited by ChemBro (2015-09-26 09:41:53)

haagch · 2015-09-27 14:37:14

mesa's configure tests for

$LLVM_LIBDIR/libLLVMTarget.$IMP_LIB_EXT

which evaluates to /usr/lib/libLLVMTarget.so. In the llvm update from today there is only /usr/lib/libLLVMTarget.a. Did you chance something at the shared llvm libraries compile options?

lordheavy · 2015-09-27 15:31:32

haagch wrote:

mesa's configure tests for
$LLVM_LIBDIR/libLLVMTarget.$IMP_LIB_EXT
which evaluates to /usr/lib/libLLVMTarget.so. In the llvm update from today there is only /usr/lib/libLLVMTarget.a. Did you chance something at the shared llvm libraries compile options?

LLVM (will) is now built with cmake, dynamic library is now named libLLVM.so.3.8.0svn instead of libLLVM-3.8.0.so, so i had to change the detection script.

edit: http://pkgbuild.com/~lcarlier/mesa-git/ … /mesa-git/

Last edited by lordheavy (2015-09-27 15:35:02)

haagch · 2015-09-27 17:04:24

Thanks for the patch. Is upstream mesa going to support that too?

lordheavy · 2015-09-27 17:13:57

haagch wrote:

Thanks for the patch. Is upstream mesa going to support that too?

sent upstream, see http://lists.freedesktop.org/archives/m … 95426.html

haagch · 2015-10-24 21:50:00

Thanks, by the way.

New problem: When I try to start any map in stuntrally, it crashes with

LLVM triggered Diagnostic Handler: unsupported call to function ldexpf in main

Maybe llvm is too old?

edit: Unfortunately the llvm update today didn't help.
edit2: Made a bug report: https://bugs.freedesktop.org/show_bug.cgi?id=92709

Last edited by haagch (2015-10-28 14:29:55)

ergoschnuffel · 2015-11-14 12:03:33

Is there something amiss?

error: failed to commit transaction (conflicting files)
/usr/bin/scan-build exists in both 'clang-svn' and 'clang-analyzer-svn'
/usr/bin/scan-view exists in both 'clang-svn' and 'clang-analyzer-svn'
/usr/share/man/man1/scan-build.1.gz exists in both 'clang-svn' and 'clang-analyzer-svn'
Errors occurred, no packages were upgraded.

Lone_Wolf · 2015-11-14 13:56:32

haagch, ergoschnuffel :
check comments on AUR llvm-svn page, there have been several upstream changes in clang-svn & clang-analyzer-svn recently that broke things.
Maybe Lordheavy missed those changes ?

lordheavy · 2015-11-14 13:57:29

Lone_Wolf wrote:

haagch, ergoschnuffel :
check comments on AUR llvm-svn page, there have been several upstream changes in clang-svn & clang-analyzer-svn recently that broke things.
Maybe Lordheavy missed those changes ?

yes, i missed them

haagch · 2015-12-09 16:19:00

gcc 5.3 is in testing now and after updating I get this error when trying to build mesa:

../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o): In function `llvm::RTDyldMemoryManager::getSymbolAddress(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
lp_bld_misc.cpp:(.text._ZN4llvm19RTDyldMemoryManager16getSymbolAddressERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN4llvm19RTDyldMemoryManager16getSymbolAddressERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x4): undefined reference to `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o): In function `llvm::RTDyldMemoryManager::findSymbol(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
lp_bld_misc.cpp:(.text._ZN4llvm19RTDyldMemoryManager10findSymbolERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN4llvm19RTDyldMemoryManager10findSymbolERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x2a): undefined reference to `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
Makefile:958: die Regel für Ziel „pipe_radeonsi.la“ scheiterte
make[3]: *** [pipe_radeonsi.la] Fehler 1
make[3]: *** Es wird auf noch nicht beendete Prozesse gewartet...
../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o): In function `llvm::RTDyldMemoryManager::getSymbolAddress(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
lp_bld_misc.cpp:(.text._ZN4llvm19RTDyldMemoryManager16getSymbolAddressERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN4llvm19RTDyldMemoryManager16getSymbolAddressERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x4): undefined reference to `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o): In function `llvm::RTDyldMemoryManager::findSymbol(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
lp_bld_misc.cpp:(.text._ZN4llvm19RTDyldMemoryManager10findSymbolERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN4llvm19RTDyldMemoryManager10findSymbolERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x2a): undefined reference to `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
Makefile:955: die Regel für Ziel „pipe_r600.la“ scheiterte
make[3]: *** [pipe_r600.la] Fehler 1
../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o): In function `llvm::RTDyldMemoryManager::getSymbolAddress(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
lp_bld_misc.cpp:(.text._ZN4llvm19RTDyldMemoryManager16getSymbolAddressERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN4llvm19RTDyldMemoryManager16getSymbolAddressERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x4): undefined reference to `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
../../../../src/gallium/auxiliary/.libs/libgallium.a(lp_bld_misc.o): In function `llvm::RTDyldMemoryManager::findSymbol(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
lp_bld_misc.cpp:(.text._ZN4llvm19RTDyldMemoryManager10findSymbolERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE[_ZN4llvm19RTDyldMemoryManager10findSymbolERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x2a): undefined reference to `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

I believe this means that llvm must be built with gcc 5.3 too. Can you update it?

edit: https://www.archlinux.org/news/c-abi-change/

Last edited by haagch (2015-12-10 08:51:08)

lordheavy · 2015-12-10 14:21:08

haagch wrote:

I believe this means that llvm must be built with gcc 5.3 too. Can you update it?
edit: https://www.archlinux.org/news/c-abi-change/

It should be fixed now ^^

haagch · 2015-12-10 19:20:16

It is. Thanks.

lordheavy · 2015-12-10 19:26:20

I just pushed new mesa builds with hyperz Mareko patches, feel free to test, see http://www.phoronix.com/scan.php?page=n … Radeon-G3D
Don't hesitate to report success or failure

I also pushed a new linux-firmware in testing with updated amdgpu firmware. This should fix problems with these chipsets.

Jojonintendo · 2015-12-11 08:47:29

lordheavy wrote:

I also pushed a new linux-firmware in testing with updated amdgpu firmware. This should fix problems with these chipsets.

Many thanks for that, it also fixes bugs for Grenada users like me (R9 390). See this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=91880

With this we finally get nice performance and not a single crash (at least for me, please test it, Grenada users).

Arch Linux

#2826 2015-09-15 12:54:12

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2827 2015-09-15 13:26:17

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2828 2015-09-16 11:37:35

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2829 2015-09-16 13:06:43

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2830 2015-09-16 18:48:08

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2831 2015-09-16 19:32:31

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2832 2015-09-16 20:43:50

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2833 2015-09-19 12:11:52

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2834 2015-09-22 17:14:49

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2835 2015-09-24 19:59:51

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2836 2015-09-24 23:00:15

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2837 2015-09-25 05:59:13

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2838 2015-09-27 14:37:14

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2839 2015-09-27 15:31:32

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2840 2015-09-27 17:04:24

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2841 2015-09-27 17:13:57

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2842 2015-10-24 21:50:00

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2843 2015-11-14 12:03:33

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2844 2015-11-14 13:56:32

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2845 2015-11-14 13:57:29

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2846 2015-12-09 16:19:00

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2847 2015-12-10 14:21:08

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2848 2015-12-10 19:20:16

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2849 2015-12-10 19:26:20

Re: Discussion: the ati/radeon open source drivers & radeon repository

#2850 2015-12-11 08:47:29

Re: Discussion: the ati/radeon open source drivers & radeon repository

Board footer