Le mardi 05 octobre 2010 20:35:24, Sven-Hendrik Haase a écrit :

On 05.10.2010 20:27, Adam Chidlow wrote:

...

Hey Stefano,

What instructions did you follow? I'm interested on testing this (HD 4850 here).

Cheers, Adam ------Original Message------ From: Stefano Avallone Sender: arch-general-bounces@archlinux.org To: General Discusson about Arch Linux ReplyTo: stavallo@unina.it ReplyTo: General Discussion about Arch Linux Subject: [arch-general] some notes on the radeon gallium driver Sent: Oct 6, 2010 2:24 AM

Hi,

just if anyone is interested... I compiled mesa 7.9 and tried the radeon gallium driver on a X300 ati card. It works pretty good. For instance, now I can use the blur effect of kwin 4.5, while I couldn't with classic mesa 7.9 driver. I don't play games, so I cannot tell what is different with games...

Maybe we might have an ati-dri package in [testing] that ships r300g instead of r300c...

Stefano

You can use my -gallium AUR packages. I use them on my r500 and it works very well for games and the like.

With the move to python2/python3 you need to add these lines to properly built if testing is enabled: sed -i -e 's#/bin/env python#/bin/env python2#g' \ src/gallium/auxiliary/indices/*.py src/mesa/main/*.py sed -i -e 's#PYTHON2 = python#PYTHON2 = python2#g' \ configs/current sed -i -e 's#python#python2#g' \ src/gallium/auxiliary/Makefile Works for me with r600g ++

My understanding is that r300g is the new default in Mesa 7.9. See http://www.mail-archive.com/mesa-commit@lists.freedesktop.org/msg23390.html . Does this mean that Arch will automatically switch to it on release of Mesa or will extra steps be required?

On 06.10.2010 15:05, Stephen E. Baker wrote:

...

My understanding is that r300g is the new default in Mesa 7.9. See http://www.mail-archive.com/mesa-commit@lists.freedesktop.org/msg23390.html . Does this mean that Arch will automatically switch to it on release of Mesa or will extra steps be required? As I understand it the PKGBUILD will also have to be altered. The driver will be built by default but not installed to "/usr/lib/xorg/modules/dri/" as mentioned by Stafano. The purpose of having both drivers built is so that one could experiment with the gallium driver with export LIBGL_DRIVERS_PATH = ... before executing particular opengl programs without switching outright.

I've been doing this for a couple weeks now with the git version of just the r300g driver running with Arch's packaged mesa 7.8 and have found that it has fixed all the bugs I was having in Neverwinter Nights and eduke32 with no new problems besides the occasional stuttering when fps drops too low. I would vote for making it the default in Arch with mesa 7.9.

I'm seconding this. r300g is working exceptionally well compared to r300 and it is very stable even with lots of 3D stuff and wine games. I'd definitely want this to be the default in Arch. Perhaps we should file a bug report. In fact, I will file one if we can get a few more opinions on this. I think it would be a very beneficial idea for Arch users. -- Sven-Hendrik

On Wed, Oct 6, 2010 at 9:41 AM, Tom wrote:

...

I'm seconding this. r300g is working exceptionally well compared to r300 and it is very stable even with lots of 3D stuff and wine games. I'd definitely want this to be the default in Arch. Perhaps we should file a bug report. In fact, I will file one if we  can get a few more opinions on this.

I think it would be a very beneficial idea for Arch users.

-- Sven-Hendrik

Well is there any reason this should NOT be made default once Arch updates to Mesa 7.9 if it IS the default in new mesa?? Why would/should arch differ?

i wouldn't think so.

Sidenote: been running r300g for ages, no worries...

that's great news, along with other positive feedback. this whole message is rather devoid of new content, but it's really wonderful to see Gallium reaching fruition; it's been a long wait and it seems to really be living up to it's promises. haven't tried the Gallium driver for my 4850 (if one is ready-ish?), but this thread is very encouraging. especially interesting is the recent port of the Direct3D API to a native state tracker (i think that's the right terms)... Linux gaming may just force it's way into existence, vs. the perpetual wait for vendor support :-) C Anthony

On Wed, Oct 6, 2010 at 2:06 PM, Sven-Hendrik Haase wrote:

 On 06.10.2010 19:39, C Anthony Risinger wrote:

...

On Wed, Oct 6, 2010 at 9:41 AM, Tom wrote:

...

...

I'm seconding this. r300g is working exceptionally well compared to r300 and it is very stable even with lots of 3D stuff and wine games. I'd definitely want this to be the default in Arch. Perhaps we should file a bug report. In fact, I will file one if we  can get a few more opinions on this.

I think it would be a very beneficial idea for Arch users.

-- Sven-Hendrik Well is there any reason this should NOT be made default once Arch updates to Mesa 7.9 if it IS the default in new mesa?? Why would/should arch differ? i wouldn't think so.

...

Sidenote: been running r300g for ages, no worries... that's great news, along with other positive feedback.  this whole message is rather devoid of new content, but it's really wonderful to see Gallium reaching fruition; it's been a long wait and it seems to really be living up to it's promises.

haven't tried the Gallium driver for my 4850 (if one is ready-ish?), but this thread is very encouraging.  especially interesting is the recent port of the Direct3D API to a native state tracker (i think that's the right terms)... Linux gaming may just force it's way into existence, vs. the perpetual wait for vendor support :-)

C Anthony

Careful, r600g (for your mighty fine 4850) does not currently do what you think. In fact, upstream currently and openly discourages its usage for anything but shy testing. It might eat your babies if used for production.

luckily he's almost a toddler and can probably fight it off :-) well that sucks; i'll just keep waiting i suppose, thanks.

Double careful with the hopes for D3D used in Linux gaming. It is effectively useless for Wine since their current implementation integrates better with the other needs of a Windows game (Windows API != Direct3D). Even if a perfect, full-blown D3D 13 implementation went into Mesa, you couldn't run a single Windows game because of that. D3D on Linux is primarily meant for close-to-metal 3D virtualization (which in return would enable you gaming, though, but in a VM). Wine isn't going to switch to Mesa's implementation anytime soon.

i dont want to stray too off-topic; i know there is much more to a game than D3D, but in the brief research i did, it seemed much closer than you've hinted. the guy even threw up a patch for wine to use the tracker shortly after IIRC. all in all, wine was still required of course; i didn't see any indication of a VM/etc. but i see how it could be used for that as well. will have to look into it further i suppose; i just know several people who do not bother with Linux for this exact reason, so it appeared a solid move. C Anthony