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

Perry3D · 2011-06-15 13:51:07

http://git.kernel.org/?p=linux/kernel/g … on-testing is the source for the testing kernel
and
https://gitorious.org/radeon/radeon (PKGBUILDs and build script).

I already tried to include your requested module. But currently i have some compile errors with this branch.
Feel free to send me a patch for the config/PKGBUILD files.

Evanlec · 2011-06-17 23:29:07

What happened to the radeon repository? seemed down for me...?

Perry3D · 2011-06-17 23:49:00

I can not confirm. It is working fine here.

handy · 2011-06-18 00:02:51

Evanlec wrote:

What happened to the radeon repository? seemed down for me...?

The repo at spiralinear.org is OK for me.

The service provider does occasionally have a temporary outage.

If you try again you should be good to go.

Varg · 2011-06-18 13:58:03

Perry3D wrote:

http://git.kernel.org/?p=linux/kernel/g … on-testing is the source for the testing kernel
and
https://gitorious.org/radeon/radeon (PKGBUILDs and build script).
I already tried to include your requested module. But currently i have some compile errors with this branch.
Feel free to send me a patch for the config/PKGBUILD files.

Well that's a bit out of my league, so I'll wait patiently and hope that you can figure it out. I still have a lot of reading to do concerning kernels.

I just noticed something strange. The performance seems to differ according to the WM/DE. I gave Xfce another run and performance is a lot better compared to what I get in Subtle. In Xfce Hegdewars, Angry birds, Naev and even Steelstorm run fine, while in Subtle I have bad framerates and Steelstorm is completely unresponsive. I would've expected the opposite since Xfce is a DE and Subtle just a WM.

txus · 2011-06-19 10:43:47

Quick question: how does the default installation to find e.g. r600_dri.so, without LIBGL_DRIVERS_PATH being set (I checked)? With the default driver, without setting anything, i get everything to work perfectly, and the opengl version string reads 2.1 as it should.

As soon as i change to the radeon repo (and install every necessary bit), it doesn't find it automatically, and i have to set LIBGL_DRIVERS_PATH or glxinfo will give me (already with LIBGL_DEBUG=verbose):

name of display: :0.0
libGL: OpenDriver: trying /tls/r600_dri.so
libGL: OpenDriver: trying /r600_dri.so
libGL error: dlopen /r600_dri.so failed (/r600_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//r600_dri.so
libGL error: dlopen /usr/lib32/xorg/modules/dri//r600_dri.so failed (/usr/lib32/xorg/modules/dri//r600_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL: OpenDriver: trying /tls/swrast_dri.so
libGL: OpenDriver: trying /swrast_dri.so
libGL error: dlopen /swrast_dri.so failed (/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//swrast_dri.so
libGL error: dlopen /usr/lib32/xorg/modules/dri//swrast_dri.so failed (/usr/lib32/xorg/modules/dri//swrast_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: swrast_dri.so
libGL: OpenDriver: trying /tls/swrastg_dri.so
libGL: OpenDriver: trying /swrastg_dri.so
libGL error: dlopen /swrastg_dri.so failed (/swrastg_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//tls/swrastg_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//swrastg_dri.so
libGL error: dlopen /usr/lib32/xorg/modules/dri//swrastg_dri.so failed (/usr/lib32/xorg/modules/dri//swrastg_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: swrastg_dri.so
libGL error: reverting to indirect rendering
display: :0  screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
....
....
OpenGL renderer string: Gallium 0.4 on AMD RV710
OpenGL version string: 1.4 (2.1 Mesa 7.11-devel (git-7d488ad))
....
....

Ignoring the ELFCLASS32 stuff, because that comes from the conveniently located /etc/profile.d/lib32-dri.sh (which a default multilib install doesn't use either), how is it possible that the standard arch package finds it just fine, and the packages in radeon repo don't? HOW are those drivers searched for in a standard install?

Thank you!

P.S.: Please, don't get me wrong! It is just a question, out of frustration over a little detail. I LOVE this repo and am VERY grateful to Perry3D and every other contributor!

Lone_Wolf · 2011-06-19 14:04:41

The standard package puts the modules in usr/lib/xorg/modules/dri/ , check where the package you use puts them.

txus · 2011-06-19 14:28:57

Lone_Wolf wrote:

The standard package puts the modules in usr/lib/xorg/modules/dri/ , check where the package you use puts them.

Same, that's why I'm asking. How does the standard Arch package detect the drivers there, without setting LIBGL_DRIVERS_PATH, and what changes in the packages from Perry3D's "radeon" repo with respect to that.

Lone_Wolf · 2011-06-19 14:45:13

EDIT :

I looked to the compile settings i use for my pkgbuild and realised there is one that has to do with search path :

--with-dri-driverdir=/usr/lib/xorg/modules/dri

(copied from my PKGBUILD, mesa-r600-git )

That path is compiled into Mesa and is also used to search for drivers at runtime.

dependencies and mesa compile options were the reason i made my own package.

Last edited by Lone_Wolf (2011-06-19 15:00:44)

txus · 2011-06-19 15:30:24

Thank you so much, Lone_Wolf! Although...

I honestly don't understand what's going on xD. According to Perry3D's PKGBUILD for mesa-full in the git repo a few posts back, everything is set correctly:

--with-dri-driverdir=/usr/lib/xorg/modules/dri

Unless there is something I didn't notice, now the question is... huh? Seems as if it completely ignores this compile time setting, and defaults to blank? o_O I know this is not a big deal, just setting LIBGL_DRIVERS_PATH in some file in /etc/profile.d/ does the trick, but I like things working as they should, so if anyone can give another hint, it would be greatly appreciated

Viper_Scull · 2011-06-22 17:54:16

Lone i've installed mesa-r600g-git. Thanks for your PKGBUILD again.

One small question.

do i still need to type export R600_ENABLE_S3TC=1 or is it not needed anymore?

handy · 2011-06-23 00:41:23

My understanding is that we have to continue to do that due to intellectual property rights issues.

Lone_Wolf · 2011-06-24 00:02:16

Viper_Scull wrote:

do i still need to type export R600_ENABLE_S3TC=1 or is it not needed anymore?

handy wrote:

My understanding is that we have to continue to do that due to intellectual property rights issues.

I agree with that, it's also the reason why libtxc_dxtn is an external library.

I had to use the export R600_ENABLE_S3TC=1 to get these extensions apear in glxinfo :

GL_S3_s3tc
GL_EXT_texture_compression_s3tc

Viper_Scull · 2011-06-24 18:54:29

I dont get the point of that. I mean i understand due to property rights it has to be an external library, but once one has recompiled mesa with it (those who dont live in patent-based countries..) i think this should be not necessary.

Well apart from that, i got a couple of questions:

I have installed lib32-mesa since Enemy territory (RTCW) is a 32-bit application, but in order to take advantage of s3tc do i need to recompile the 32 bit mesa too enabling s3tc?

Do i have to run the game from console (the export line is in my .bashrc) to get s3tc?

Cheers.

Last edited by Viper_Scull (2011-06-24 18:58:51)

Cdh · 2011-06-24 19:15:41

I still have a problem with the $LIBGL_DRIVERS_PATH in this package.

lib32-mesa-full provides /etc/profile.d/lib32-dri.sh with

export LIBGL_DRIVERS_PATH=$LIBGL_DRIVERS_PATH:/usr/lib32/xorg/modules/dri

The problem is that mesa-full doesn't set the LIBGL_DRIVERS_PATH. mesa-full alone works with no LIBGL_DRIVERS_PATH set because /usr/lib/xorg/modules/dri is a default search path.

But if you install lib32-mesa-full the LIBGL_DRIVERS_PATH gets set to

:/usr/lib32/xorg/modules/dri

and since the variable isn't empty anymore the default search path isn't searched anymore.

I think the best solution would be to make mesa-full provide a /etc/profile.d/dri.sh with

export LIBGL_DRIVERS_PATH=$LIBGL_DRIVERS_PATH:/usr/lib/xorg/modules/dri

Lone_Wolf · 2011-06-25 12:51:44

@Viper_Scull :

according to mesa documentation is enabled in all builds on linux for s3tc support, so for that you don't need to recompile mesa-32.
Running from console is not necessary., but you will need lib32-libtxc_dxtn 1.0.1-1 installed.

to get the texture float support , you will need to rebuild mesa-32 .
(i don't have multilib packages installed, so didn't make a 32 bit version).

@Cdh :
the official mesa provides /ust/lib/pkgconfig/dri.pc , mesa32 provides /usr/lib32/pkconfig/dri.pc and those files also lists a driver dir.
my mesa-r600g-git installs those files, check if mesa-full has them.

Cdh · 2011-06-25 17:21:31

Yes it exists and contains the right path (dridriverdir=/usr/lib/xorg/modules/dri), but with the erronous LIBGL_DRIVERS_PATH it doesn't search there:
(is "dridriverdir" correct? Looks strange)

chris@chris ~ % LIBGL_DRIVERS_PATH=:/usr/lib32/xorg/modules/dri/ LIBGL_DEBUG=verbose glxinfo | grep render
libGL: OpenDriver: trying /tls/r600_dri.so
libGL: OpenDriver: trying /r600_dri.so
libGL error: dlopen /r600_dri.so failed (/r600_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//r600_dri.so
libGL error: dlopen /usr/lib32/xorg/modules/dri//r600_dri.so failed (/usr/lib32/xorg/modules/dri//r600_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL: OpenDriver: trying /tls/swrast_dri.so
libGL: OpenDriver: trying /swrast_dri.so
libGL error: dlopen /swrast_dri.so failed (/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//swrast_dri.so
libGL error: dlopen /usr/lib32/xorg/modules/dri//swrast_dri.so failed (/usr/lib32/xorg/modules/dri//swrast_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: swrast_dri.so
libGL: OpenDriver: trying /tls/swrastg_dri.so
libGL: OpenDriver: trying /swrastg_dri.so
libGL error: dlopen /swrastg_dri.so failed (/swrastg_dri.so: cannot open shared object file: No such file or directory)
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//tls/swrastg_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri//swrastg_dri.so
libGL error: dlopen /usr/lib32/xorg/modules/dri//swrastg_dri.so failed (/usr/lib32/xorg/modules/dri//swrastg_dri.so: wrong ELF class: ELFCLASS32)
libGL error: unable to load driver: swrastg_dri.so
libGL error: reverting to indirect rendering
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
OpenGL renderer string: Gallium 0.4 on AMD RV730
chris@chris ~ %

txus · 2011-06-27 11:50:57

@Cdh
Well, you´re not the only one! (look a few posts up)

Perry3D · 2011-06-28 07:40:39

I changed mesa-full with the last update. It now creates a new file in /etc/profilde.d/ called mesa-dri.sh.
The content is

export LIBGL_DRIVERS_PATH=$LIBGL_DRIVERS_PATH:/usr/lib/xorg/modules/driexport LIBGL_DRIVERS_PATH=$LIBGL_DRIVERS_PATH:/usr/lib/xorg/modules/dri

I hope that solves your problem.

Cdh · 2011-06-28 10:11:11

It should. Thank you.

splashy · 2011-06-29 13:00:17

One question: do we need to install mesa-full-gallium for having gallium support or is gallium now integrate in mesa-full as the official one?
I ask you this question because mesa-full and mesa-full-gallium are in conflict and mesa-full-gallium doesn't ask about the deleting of libgl and so on as mesa-full. I'm now running testing package and want to be sure of what I'm doing before breaking my system^^.

handy · 2011-06-29 13:40:14

Perry3D wrote:

Radioactiveman wrote:
If it's already dead you could try to bake it in the oven -> click (I know you are German )
Lol, that's one of the weirdest things i've ever read about hardware. Maybe i'll give it a try .
Does someone know why 100°C can repair a gpu-chip?

The only thing that makes sense to me is that if you make the solder on the circuit board hot enough it could melt enough to fix dry joints. As such that wouldn't really be having any effect on the GPU itself.

The only problem is that 100 degrees C, is not hot enough to melt the solder...

Therefore it makes no sense to me.

cheer · 2011-06-29 14:50:25

It seems that KMS doesn't work on HD6850/HD6870 ([1], [2]) and the fix is already submitted. Do you plan to release a new kernel in the perry3d repo? It seems that the fix is not included into the kernel26-drm-radeon-testing-20110605 package, right?

Thanks for your work!

Last edited by cheer (2011-06-29 16:04:57)

Perry3D · 2011-06-29 15:21:01

Hey, you found my bug . If you have the same problem, pls vote for this bug or give some more information.
And yes, the fix is not included in the 20110605 package.

I tried to compile the radeon-testing branch a few days ago. But i got a compile error.
I am wondering why the fix is not included in this branch? I will try the kernel26-git package. And if it works, i will add the patches manually.

/edit: @splashy: Mesa is using gallium by default. So mesa-full-gallium is obsolete. You can remove mesa-full-gallium.

Last edited by Perry3D (2011-06-29 15:22:43)

cheer · 2011-06-29 16:03:23

Yes, I've some logs and I'll try to add them later today. Actually, I was able to log into the TTY1-6 and run some commands, but I wasn't able to see what I was doing So may be my issue is a little bit different (you wrote that you got a
complete system freeze).

Arch Linux

#2076 2011-06-15 13:51:07

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

#2077 2011-06-17 23:29:07

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

#2078 2011-06-17 23:49:00

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

#2079 2011-06-18 00:02:51

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

#2080 2011-06-18 13:58:03

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

#2081 2011-06-19 10:43:47

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

#2082 2011-06-19 14:04:41

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

#2083 2011-06-19 14:28:57

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

#2084 2011-06-19 14:45:13

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

#2085 2011-06-19 15:30:24

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

#2086 2011-06-22 17:54:16

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

#2087 2011-06-23 00:41:23

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

#2088 2011-06-24 00:02:16

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

#2089 2011-06-24 18:54:29

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

#2090 2011-06-24 19:15:41

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

#2091 2011-06-25 12:51:44

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

#2092 2011-06-25 17:21:31

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

#2093 2011-06-27 11:50:57

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

#2094 2011-06-28 07:40:39

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

#2095 2011-06-28 10:11:11

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

#2096 2011-06-29 13:00:17

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

#2097 2011-06-29 13:40:14

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

#2098 2011-06-29 14:50:25

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

#2099 2011-06-29 15:21:01

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

#2100 2011-06-29 16:03:23

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

Board footer