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

Perry3D · 2011-01-22 12:53:05

Did you try the drivers from the testing repo? There is a new kernel and mesa 7.10 instead of 7.09.
Maybe 2.6.36 and mesa 7.09 are too old for your gpu.

punkeroso · 2011-01-22 15:23:35

Perry3D wrote:

Did you try the drivers from the testing repo? There is a new kernel and mesa 7.10 instead of 7.09.
Maybe 2.6.36 and mesa 7.09 are too old for your gpu.

With the driver in testing, if I launch compiz, I get:

compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
compiz (core) - Error: Failed to manage screen: 0
compiz (core) - Fatal: No manageable screens found on display :0.0

...but are perfect when scrolling in firefox...!!

edit: I found this in my /var/log/Xorg.0.log

[punkeroso@vaio ~]$ cat /var/log/Xorg.0.log|grep AIGLX
[   484.927] (==) AIGLX enabled
[   484.993] (II) AIGLX: Screen 0 is not DRI2 capable
[   484.993] (II) AIGLX: Screen 0 is not DRI capable
[   484.996] (II) AIGLX: Loaded and initialized /usr/lib/xorg/modules/dri/swrast_dri.so

Last edited by punkeroso (2011-01-22 15:35:36)

lgomes · 2011-01-22 17:01:00

Perry3D,

Thanks !!! Your kernel DRM is good to use all day, so kernel headers is needed.

With the latest builds, compiz performance is better.

For me, compiz log show this:

compiz (bicubic) - Fatal: GL_ARB_texture_float not supported. This can lead to visual artifacts.

This is using r600g(gallium) or r600c. I think that GL is not fully supported.

Maybe for someone the errors in log is different, because the compiz settings is different.

I have a IGP HD3200 in a motherboard ASUS M3A78-EM.

The open source driver is improving performance.

If preempt_rt patch were to kernel 2.6.37 branch, i think that performance is a bit better.

Sorry my english.

hoschi · 2011-01-24 16:20:23

hoschi wrote:

I have only artifacts within OpenGL games (IOQuake3 or glChess), maybe because I use only Metacity with compositeing.
Devno can you take a look at following bug: https://bugs.freedesktop.org/show_bug.cgi?id=33158
Can you post the output of "glxinfo | grep -i opengl" with Perry3DRepo?

Fixed with the newer GIT-Checkouts from the weekend.

glock24 · 2011-01-28 21:49:04

Hi all,

I've been having hard freezes and kernel panics lately. The hard freeze occurs mostly random, but occur more often after coming out of standby. The kernel panics occur when playing a video in smplayer using opengl output.

I'm using the latest packages from the [radeon] repo, and I update the system on a daily basis.

Maybe the update to KDE 4.6 has something to do with this? Or maybe just the latest radeon patches?

Also, 2D is very very slow.

The video card is a X1250 (RS960M) on a Gateway T-1628 running arch x64 with the drm-radeon-testing kernel.

Any ideas?

Perry3D · 2011-01-28 22:25:03

I did an update of the repo a few minutes ago. Maybe it helps.

At the moment i have no problems with my HD4850. It is working rockstable.
Are you using gallium? It should be the better choice for your card.
Or try using the arch stock kernel.

msx · 2011-01-29 02:06:18

Hi Perry, guys,

I'm using a Radeon HD5750, will the open-source module work ok? Can I use it with the stock kernel or I need a special one?
Thank you!

handy · 2011-01-29 09:14:39

msx wrote:

Hi Perry, guys,
I'm using a Radeon HD5750, will the open-source module work ok? Can I use it with the stock kernel or I need a special one?
Thank you!

It should work fine; but whether you will be satisfied or not comes down to how demanding your 3D jobs will be.

I'm very happy with the Classic or Gallium dev' driver stack & kernel with my HD2600Pro. But I don't play games with complex 3D in them.

Last edited by handy (2011-01-29 09:15:52)

agapito · 2011-01-29 10:09:10

msx wrote:

Hi Perry, guys,
I'm using a Radeon HD5750, will the open-source module work ok? Can I use it with the stock kernel or I need a special one?
Thank you!

I have HD5770 I tested 2.6.37 + mesa 7.10 from testing + ati-git from aur. First of all i had to use low profile voltage because my gpu fan was very noisy, so performance was not the best. At this moment Radeon driver is working nice and stable for my card, but only with 2D. If you don't want 3D radeon driver is OK. Kwin effects are slow, videos are fine with mplayer xv output. I tested mame and some other emus and are working acceptable, N64 emu is innacurate and slow. At this moment i prefer catalyst driver, maybe i change in the future.

msx · 2011-01-29 15:27:58

@handy, @agapito

Awesome guys, thank you very much!
I don't play any games at all but since I run KDE I will stick with privative Catalyst by now...

Cheers

vladthedog · 2011-01-29 15:46:12

msx wrote:

@handy, @agapito
Awesome guys, thank you very much!
I don't play any games at all but since I run KDE I will stick with privative Catalyst by now...
Cheers

Just wanted to give a different side to the story. I have a 5770 and just recently (after a system update to kde 4.6 my catalyst driver setup went to crap) i decided to try the xf86 driver again. I followed the instructions in the initial post of what to install from their repo (only difference is I am still running the stock kernel) and KDE with the xf86 driver has never run better for me. I don't game either, but KDE's effects work great with this setup.

My setup:
i5 750 - msi mobo
hd5770
8gb ram
kde4.6 just installed
dual monitor setup running at 1920x1080ea

I was actually popping in to thank the OP! I've never been as happy with my ATI card in linux as I am now

EDIT: Just wanted to point out. Wasn't blaming the kde update for catalyst issues. It had been a few weeks since I did an update so my catalyst driver was updated from the catalyst repo as well.

Last edited by vladthedog (2011-01-29 15:47:41)

msx · 2011-01-29 16:00:03

@vladthedog
thanks for posting, seems I have to make a backup and try it by myself after all.
Again, thank you

iFSS · 2011-01-29 19:50:53

@Perry3D

Couple of quick questions: Do you plan on changing the builds of lib32-mesa-full so that they provide the gallium dri modules too?

Also, to get 32-bit apps to use acceleration I have to launch them from a shell after changing LIBGL_DRIVERS_PATH to point to the 32-bit drivers:

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

- is there a more permanent "fix" for this?

Oh, and cheers for the repo

Demon · 2011-01-29 21:06:24

lgomes wrote:

Perry3D,
Thanks !!! Your kernel DRM is good to use all day, so kernel headers is needed.
With the latest builds, compiz performance is better.
For me, compiz log show this:
compiz (bicubic) - Fatal: GL_ARB_texture_float not supported. This can lead to visual artifacts.
This is using r600g(gallium) or r600c. I think that GL is not fully supported.
Maybe for someone the errors in log is different, because the compiz settings is different.
I have a IGP HD3200 in a motherboard ASUS M3A78-EM.
The open source driver is improving performance.
If preempt_rt patch were to kernel 2.6.37 branch, i think that performance is a bit better.
Sorry my english.

http://cgit.freedesktop.org/mesa/mesa/t … L3.txt#n18

handy · 2011-01-30 01:55:19

msx wrote:

@vladthedog
thanks for posting, seems I have to make a backup and try it by myself after all.
Again, thank you

As long as you aren't into heavy duty 3D games, you really shouldn't have any problems with the FOSS driver stack. I've been happy with it for many months now, long before I started using the Gallium stack.

2D & movies on my 1920x1200 24" screen are brilliant. I don't use 3D desktop effects, as I'm not interested in them. Actually I barely use a desktop - Openbox with the Xfce panel & Worker.

Last edited by handy (2011-01-30 02:29:08)

msx · 2011-01-31 04:59:30

I will backup and try it as soon I have a little time, thank you!

*vitali* · 2011-01-31 18:34:05

Since the last kernel upgrade (custom kernels don't work for me) the system hangs before starting kde 4.6 (using kdm) for a few seconds black screen with "_" top left corner. Also yakuake generates artifacts, on my panel (which is on the top), and when yakuake is open I can see the desktop background in a section of the desktop panel.

vladthedog · 2011-01-31 19:45:13

*vitali* wrote:

Since the last kernel upgrade (custom kernels don't work for me) the system hangs before starting kde 4.6 (using kdm) for a few seconds black screen with "_" top left corner. Also yakuake generates artifacts, on my panel (which is on the top), and when yakuake is open I can see the desktop background in a section of the desktop panel.

in yakuake try to go in to settings and disable "have window manager handle effects" (or something like that). see if it fixes it. I think this was a new "addon" to yakuake very recently so it could be coincidence that its acting up after your last update. I ended up disabling it, not because of artifact, but because I didn't like the effects it did on it.

Beelzebud · 2011-01-31 20:54:04

I know this isn't helpful to anyone, but I just had to let this out: There is a new feature in the latest driver control panel called Tear Free. It fixes every single issue I've had with vsync and playing video on this machine! No more screen tearing at all! That was one very pleasant, and welcome surprise!

glock24 · 2011-02-01 20:39:41

Perry3D wrote:

I did an update of the repo a few minutes ago. Maybe it helps.
At the moment i have no problems with my HD4850. It is working rockstable.
Are you using gallium? It should be the better choice for your card.
Or try using the arch stock kernel.

I've had no kernel panics or system freezes since the update. I also added these options in the xorg.conf:

Option "EXAVSync" "off"
Option "ScalerWidth" "2048"

EXAVSync is supposed to be off by default, but was on. Also, I read in the phoronix forums that "ScalerWidth" "2048" would help with my chip. So far 2D performance has been a lot better.

I've also noticed that 3D performance is slower, at least with SMC. It used to be very fluid, but now there's lag between input and what happens on screen.

I enabled KDE desktop effects just for testing, and it's so slow the option disables itself after a while because it says it's too slow.

The official kernel was updated recently to version 2.6.37, which seems to be newer than the one on the radeon repository (2.6.37-rc8). Which one has the most recent drm code?

And yes, I'm using gallium, as most games simply do not run or present lots of artifacts using classic mesa.

Last edited by glock24 (2011-02-01 20:51:16)

lgomes · 2011-02-01 21:11:57

@Demon

Thanks for the info !!!

Your info help me to find that some GL proprietary extensions patchs is not in master branch.

According with this post:

http://phoronix.com/forums/showthread.p … post166403

I need learn a bit GIT, to be sure how merge branchs efficiently. Or identify some patchs and aply those in Mesa Master Branch to get the GL_ARB Extensions !!

In the past, i search in GL3.txt and not have the marek patch !!!

This is used by compiz.

Thanks !!!

Perry3D · 2011-02-01 22:51:41

glock24 wrote:

The official kernel was updated recently to version 2.6.37, which seems to be newer than the one on the radeon repository (2.6.37-rc8). Which one has the most recent drm code?
And yes, I'm using gallium, as most games simply do not run or present lots of artifacts using classic mesa.

If i remember correctly rc8 is very near to the final (or IS the final version) of 2.6.37. And the latest drm code is in drm-radeon-testing. Every patch for the official kernel is tested in this branch before getting merged: http://git.kernel.org/?p=linux/kernel/g … on-testing

ijanos · 2011-02-01 23:31:12

Perry3D wrote:

And the latest drm code is in drm-radeon-testing. Every patch for the official kernel is tested in this branch before getting merged: http://git.kernel.org/?p=linux/kernel/g … on-testing

The latest .38 rc is out today and it contains fixes to the radeon/drm and I cannot find those commints int the drm-radeon-testing tree.

Perry3D · 2011-02-01 23:48:59

Ok, i'll quote the email from Dave concerning the different branches: http://article.gmane.org/gmane.comp.vid … evel/40626

Dave wrote:

So I'm going to change the layout of my git branches again, because my
current plan isn't working for me.
At the moment drm-next is considered the branch to base new work off
and to also for downstream trees to
pull from, this is changing.
I will now maintain
drm-core-next : a branch with all the core DRM/KMS changes in it,
please base all downstream sub-driver
trees from this branch in the future. This branch will not rebase, it
may pull in a downstream driver tree in
the pre-merge window time, and/or when some patch from that tree is
required for a patch to the mainline.
This will be the basis of any trees I send to Linus.
drm-radeon-next: a tree like Eric's drm-intel-next where radeon
specific changes will be queued up.
drm-next: This tree will be rebased quite regularly (2-3 days) with a
git pull of the latest, drm-core-next, drm-radeon-next
and drm-intel-next, so that the code in drm-next is tested better. You
should use this tree for testing latest drm stuff
with an eye to the next Linus kernel.
Radeon (users)
drm-radeon-testing: this will be a rebased tree containing
drm-core-next, drm-radeon-next and some changes
that we aren't fully committed to yet. For radeon KMS users this is
probably the best bleeding edge tree.
>From time to time I will also have throwaway trees for merging to
Linus, I'll probably merge these into drm-next
and drm-radeon-testing from time to time until Linus pulls them.
Hopefully this works out better for me, though I suspect I need some
sort of self discipline measures.
Dave.

I'm neither a developer nor i'm involved in any other way to the drivers developtment. I just followed Dave's proposal to use the drm-radeon-testing branch.
But if anyone is of another opinion i am ready to discuss .

I just discovered a new branch "drm-fixes-staging" but i found no explanation to this branch. Anyone does know more?

Last edited by Perry3D (2011-02-01 23:51:32)

iFSS · 2011-02-03 01:18:09

Answering my own questions:

iFSS wrote:

Also, to get 32-bit apps to use acceleration I have to launch them from a shell after changing LIBGL_DRIVERS_PATH to point to the 32-bit drivers:
export LIBGL_DRIVERS_PATH=/usr/lib32/xorg/modules/dri/
- is there a more permanent "fix" for this?

Changing /etc/profile.d/radeon.sh to:

export LIBGL_DRIVERS_PATH=/usr/lib/xorg/modules/dri_g/:/usr/lib32/xorg/modules/dri/

solved this.

However, lib32-mesa-full includes /etc/profile.d/lib32-dri.sh with the following:

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

- will radeon.sh always be evaluated after lib32-dri.sh ('r' after 'l'), so lib32-dri.sh can be overridden?

iFSS wrote:

Do you plan on changing the builds of lib32-mesa-full so that they provide the gallium dri modules too?

I looked at http://gitorious.org/radeon and have created 2 PKGBUILDs for lib32-mesa-full-gallium - one based on mesa-full-gallium that builds from source:
http://aur.pastebin.com/j1tDfF6F

And one based on lib32-mesa-full that copies the libs from the i686 package (I had no idea what to do with the depends/makedepends for this, so left them as is):
http://aur.pastebin.com/rja9d676 (requires mesa-full-gallium-20110201-1-i686.pkg.tar.xz)

For these, /etc/profile.d/radeon.sh will need changing to:

export LIBGL_DRIVERS_PATH=/usr/lib/xorg/modules/dri_g/:/usr/lib32/xorg/modules/dri_g/

I tested both with Syberia 2 (Wine) using a X1800XT, and the performance was far better than classic mesa (full speed & no glitches). Please consider packaging & including lib32-mesa-full-gallium in your repo, thanks

Last edited by iFSS (2011-02-03 01:22:45)

Arch Linux

#1876 2011-01-22 12:53:05

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

#1877 2011-01-22 15:23:35

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

#1878 2011-01-22 17:01:00

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

#1879 2011-01-24 16:20:23

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

#1880 2011-01-28 21:49:04

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

#1881 2011-01-28 22:25:03

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

#1882 2011-01-29 02:06:18

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

#1883 2011-01-29 09:14:39

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

#1884 2011-01-29 10:09:10

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

#1885 2011-01-29 15:27:58

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

#1886 2011-01-29 15:46:12

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

#1887 2011-01-29 16:00:03

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

#1888 2011-01-29 19:50:53

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

#1889 2011-01-29 21:06:24

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

#1890 2011-01-30 01:55:19

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

#1891 2011-01-31 04:59:30

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

#1892 2011-01-31 18:34:05

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

#1893 2011-01-31 19:45:13

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

#1894 2011-01-31 20:54:04

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

#1895 2011-02-01 20:39:41

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

#1896 2011-02-01 21:11:57

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

#1897 2011-02-01 22:51:41

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

#1898 2011-02-01 23:31:12

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

#1899 2011-02-01 23:48:59

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

#1900 2011-02-03 01:18:09

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

Board footer