AMD Releases Catalyst 9.6 For Linux

[MostAwesomeDude]

Okay, let's try this one more time.

nvidia (the blob from nVidia) is superior in terms of features and stability. It still crashes all the time, is buggy, doesn't support esoteric X features correctly, etc.

XvBA is dead in the water, as far as desktop support is concerned. AMD crafted it for enterprise clients, not desktop clients. You all will have to wait until somebody introduces VDPAU for Radeons in the open-source driver, which brings me to...

...Contribution. The open-source driver is completely fueled by contributions. We have the documentation, we have the expertise. We only lack manpower. If you want drivers so damn bad, why not contribute? I learned how to write graphics drivers out of pure hatred for fglrx; if I can do it, surely you all can too.

Finally, fglrx is for FireGLs first, Radeons second. It's an enterprise driver, for enterprise Linux. The big targets here are SUSE, RHEL, and Ubuntu LTS; not Gentoo, Arch, or name-your-distro-here.

tl;dr: Read the post and stop relying on tl;dr.

~ C.

[mendieta]

Sure he isn't. Linus didn't sign that for whatever the reason he had for not doing so. Maybe he was pragmatic or wanted to remain neutral in a way.

though see this earlier post for Linus opinion about blobs:
http://www.phoronix.com/forums/showpost.php?p=78838&postcount=78

And the source before anyone gets paranoid:
http://lwn.net/1999/0211/a/lt-binary.html

[E.Dulen]

Okay, let's try this one more time.

nvidia (the blob from nVidia) is superior in terms of features and stability. It still crashes all the time, is buggy, doesn't support esoteric X features correctly, etc.

XvBA is dead in the water, as far as desktop support is concerned. AMD crafted it for enterprise clients, not desktop clients. You all will have to wait until somebody introduces VDPAU for Radeons in the open-source driver, which brings me to...

...Contribution. The open-source driver is completely fueled by contributions. We have the documentation, we have the expertise. We only lack manpower. If you want drivers so damn bad, why not contribute? I learned how to write graphics drivers out of pure hatred for fglrx; if I can do it, surely you all can too.

Finally, fglrx is for FireGLs first, Radeons second. It's an enterprise driver, for enterprise Linux. The big targets here are SUSE, RHEL, and Ubuntu LTS; not Gentoo, Arch, or name-your-distro-here.

tl;dr: Read the post and stop relying on tl;dr.

~ C.

I have a feeling that I will not play HL2 any time soon on F11 with my new HD4850 *time to re-install winXP :-(*

[cutterjohn]

I second that. My laptop keeps making the screen a mess when it is on battery...Yep wishing that I went for the 9800M GS right now instead of the 4850 mobility.

Video playback via mplayer froze the machine again requiring alt+prtscr boot. (RSEINUB)

Seems to happen most often after awaking from sleep, Ubuntu 9.04 64b, compiz/beryl disabled(always freezes from sleep if it's on, and Im not even going to bother testing it w/9.6... oh for at least lush green quality drivers instead of the bloody mess that we have...)

wine is still hosed by the wonderful drivers as well... I really wish that AMD would get their ---- together instead of moaning about opensource as I'd MUCH rather just have decent quality drivers and don't give a rats --- about their being open or not. Its much more like AMD is hoping/expecting OSS to save their bacon rather than actually doing the heavy lifting themselves.

[RealNC]

...Contribution. The open-source driver is completely fueled by contributions. We have the documentation, we have the expertise. We only lack manpower. If you want drivers so damn bad, why not contribute? I learned how to write graphics drivers out of pure hatred for fglrx; if I can do it, surely you all can too.

Some people have a life. Also, not everyone works as a developer. Some people work at the bank, others at the postal office. Some are teachers... You can hardly ask the dude who works at Pizza Hut to go learn Unix systems programming in C if he can't even understand a Hello World program in Visual Basic.

[blindfrog]

I have a feeling that I will not play HL2 any time soon on F11 with my new HD4850 *time to re-install winXP :-(*

Downgrade to Fedora 10, compile wine-git and HL2 with catalyst 9.6 works great with radeon 4850 here all the DX9 effects on! :)

[NSLW]

Downgrade to Fedora 10, compile wine-git and HL2 with catalyst 9.6 works great with radeon 4850 here all the DX9 effects on! :)

I've got better solution. Throw out Radeon and buy Geforce. You'll save your time downgrading to Fedora 10 :)

[mdias]

Some people have a life. Also, not everyone works as a developer. Some people work at the bank, others at the postal office. Some are teachers... You can hardly ask the dude who works at Pizza Hut to go learn Unix systems programming in C if he can't even understand a Hello World program in Visual Basic.

Still, they complain, which is understandable, but some even say that they'd pay AMD from their wallets for better drivers. Why don't they pay the developers that work on the FOSS drivers?

It's true that not everyone can contribute to the driver (hell, I'm an experienced programmer and still can't say I could help with the FOSS drivers), but it's also true that AMD never said their cards would work wonders on linux.

Remember, people; AMD never made you buy their product.
Not happy? Help with FOSS.
Can't? Pay someone who can.
Can't pay? Wait.
Can't wait? Your bad, you should've bought a well supported card on linux.

[RealNC]

Can't wait? Your bad, you should've bought a well supported card on linux.

The first sane thing you've written here.

[E.Dulen]

I've got better solution. Throw out Radeon and buy Geforce. You'll save your time downgrading to Fedora 10 :)

But I bought my card just 4 days ago :( and now I must spend more cash on nVidia card :(, the cheapest solution for me would be to install winXP

[rsingh]

This is sad, have Fedora 11 installed and was waiting for 9.6 to bring support to 2.6.29 kernel.

Well i think waiting game is still on.... :(

[kensai]

Stop complaining and go contribute to open source ATI drivers. You have all required information to write good drivers.

Makes me wonder, if that is the case, then why is that driver still so incomplete on features, and doesn't work right most of the times with r6xx and up. Why are the developers of such drivers still saying they can't implement x and y feature because there is no documentation for that. Yeah, is good AMD has released some documentation, but there are hordes of docs left to be released for the oss driver to be any good, for todays standards.

[val-gaav]

... because good nvidia blobs for years stopped the development of X. Not just, because there is no specs for nvidia cards, not just because they are not using much of X framework, but because other companies were like "Hmm nvidia does blobs and they work fine, let's go this path too"

However so far nvidia is the only company that produces good closed source graphic drivers for linux.

Yes I really do think nvidia is at least partially to blame for the X.org state. Look what happens now after intel and amd/ati started supporting X ... So many cool new technologies are in the works :)

[MostAwesomeDude]

Some people have a life. Also, not everyone works as a developer. Some people work at the bank, others at the postal office. Some are teachers... You can hardly ask the dude who works at Pizza Hut to go learn Unix systems programming in C if he can't even understand a Hello World program in Visual Basic.

I have a life too. I'm a professional musician. I write drivers out of boredom.

My point was that there's no such thing as a free lunch, and this is no exception. If you want a certain feature implemented, pay somebody. Or be patient. We're working at a rather ridiculous pace already, and features are being implemented at a fairly fast pace.

Makes me wonder, if that is the case, then why is that driver still so incomplete on features, and doesn't work right most of the times with r6xx and up. Why are the developers of such drivers still saying they can't implement x and y feature because there is no documentation for that. Yeah, is good AMD has released some documentation, but there are hordes of docs left to be released for the oss driver to be any good, for todays standards.

Things we don't have documentation for:

- r128, r100, r200. Don't really need it, as we understand these really well, and the code for them is rather self-documenting.
- Power management. We have most of the AtomBIOS stuff for power management, and it's being tested out, but we don't actually have docs for it. We still know how to do it, though.
- UVD/UVD2. We will never see full UVD2 docs. Get used to it. UVD is another story, though; docs for that will show up at some point. Doesn't really matter, though, since we can use a shaderful state tracker (from Gallium) to do most of what these chips do.
- Context management. This ability just doesn't exist, so of course there's no docs on it.
- AES chip. Ditto.

Features that people bitch and moan about:

- 3D. We have all the docs for this.
- Power management. No docs, but we know how to do it anyway.
- Video. Done with Xv.

Oh, look at that, most of the missing features have nothing to do with documentation.

[mendieta]

Some people have a life. Also, not everyone works as a developer. Some people work at the bank, others at the postal office. Some are teachers... You can hardly ask the dude who works at Pizza Hut to go learn Unix systems programming in C if he can't even understand a Hello World program in Visual Basic.

Ok, that does it. Not only you are derogatory to the guy volunteering his time to give the community a decent driver ("some people have a life"), but you also have to take to with the folks working in the food service field (apparently they have no brains in your opinion).

Of course _you_ have a life and you spend it in this forum, insulting people!

[BlackStar]

Ok, that does it. Not only you are derogatory to the guy volunteering his time to give the community a decent driver ("some people have a life"), but you also have to take to with the folks working in the food service field (apparently they have no brains in your opinion).

Of course _you_ have a life and you spend it in this forum, insulting people!

User CP -> Edit ignore list -> "RealNC" -> Done ;)

[keithlm]

=========================================
Anyway: Catalyst 9.6 for Linux is GREAT.
=========================================

My 3x4850's "trifire" is working much much better.

The 9.6 universe-cli results are massively better than the 9.5 results; in most cases double the performance. I've not posted the results yet because I'm working on tweaking. (I don't believe in posting 18 different sets of the same data... I run my tests and post the best set of results. And I'm also thinking about updating to the newest beta Phoronix.)

User CP -> Edit ignore list -> "RealNC" -> Done ;)

If it were only that simple. The problem is that you have to see the responses to that person's posts also.

There will always be people on any particular forum posting their contrary opinions. (I think that in their minds they honestly believe that there is a relationship between how rude they are and how smart they appear.)

[mendieta]

User CP -> Edit ignore list -> "RealNC" -> Done ;)

Thanks for the Tip! (I really didn't know about that)

[NSLW]

But I bought my card just 4 days ago :( and now I must spend more cash on nVidia card :(, the cheapest solution for me would be to install winXP

Yes it seems it's the cheapest solution. I think it should be a lesson to everyone: Don't buy ATI's stuff, it isn't worth the price.

[mirv]

Yes it seems it's the cheapest solution. I think it should be a lesson to everyone: Don't buy ATI's stuff, it isn't worth the price.

And neither is nvidia's - so everybody go buy intel.

[Tares]

Have you tried the 10 bit enable?


aticonfig --set-pcs-val=DDX,OGLFMTA2R10G10B10Enable,1


From here:
http://forum.compiz-fusion.org/showthread.php?t=6794

HTH!

I tried, but doesn't help. Well, I didn't had quite a lot of those xorg options, but as I thought, none of them helped. Still got choppy cube with playback on one of desktops, not to mention fullscreen kills it all :D but I can turn it off if I'm fast enough :D

Moving this aside... drivers are great :D

[NeoBrain]

I think you can create SUSE RPMS from their installer, if they don't work you uninstall them and revert back. You can certainly do that for Ubuntu. Try passing --help to the installer.

I nearly forgot about that option, thanks for reminding me of that :D

Works fine so far, using glxgears with Compiz looks great ;)
Only problem seems to be a major slowdown in Wine.. I just tested a very simple app I programmed recently and it's about 10 times slower than before.. I'll look into that, perhaps I was just doing something wrong :rolleyes:

[cruiseoveride]

nVidia fanboy :)

troll FAIL

i have a Radeon 9700 Pro and a HD4870


9.6 is worse than 9.5.

How come when fglrx loads it shows 20 May 2009? So it was built a month ago but the fuktards only decided to release it now?

[RealNC]

No, it's just that they decided to honor my birthday.

[mirv]

troll FAIL

i have a Radeon 9700 Pro and a HD4870


9.6 is worse than 9.5.

How come when fglrx loads it shows 20 May 2009? So it was built a month ago but the fuktards only decided to release it now?

There's a phoronix article about the amd linux driver development cycle. Yes, they built it a month ago, and let it "bake" for a month. It is also explained why they do that. So read up a little before insulting them.

[Kano]

I still consider 12 bad driver release too much. Release when needed, if needed 20 if not 1 or 2, but those have to work 100%.

[keithlm]

There's a phoronix article about the amd linux driver development cycle. Yes, they built it a month ago, and let it "bake" for a month. It is also explained why they do that. So read up a little before insulting them.

Actually I had created a similar response but didn't post it.

I realized that these guys don't need any help to look bad.

Kano::: Personally I love knowing I'll get a new driver every month. Especially when they are as good as these new drivers. 9.6 >>>> 9.5

[kensai]

Actually I had created a similar response but didn't post it.

I realized that these guys don't need any help to look bad.

Kano::: Personally I love knowing I'll get a new driver every month. Especially when they are as good as these new drivers. 9.6 >>>> 9.5
Fine for you, if you can live with 12 bad drivers a year, I agree with kano.

[Darksurf]

These drivers are great. you just need patches is all.
If you use a gentoo based distro, i've got an ebuild and fix
that will work to get them going. sorry, its a crappy ebuild
but it gets the job done.

http://www.megaupload.com/?d=8EPKR4FM

cd and extract this to /usr/portage/x11-drivers/ati-drivers/
ebuild ati-drivers-8.62.ebuild digest
emerge =ati-drivers-8.62
(after you finish emerging the ebuild doesn't work well so you need to do this)
cd /usr/portage/distfiles
chmod +x ati-driver-installer-9-6-x86.x86_64.run
./ati-driver-installer-9-6-x86.x86_64.run

and go through the install, it will fail to build fglrx.ko but
this is fine as the ebuild did that for us, its just the other prebuilt .so files we need.

make sure that your xorg.conf is set to fglrx and viola you can use the 9.6 catalyst drivers for .29 or .30 kernel. I'm using it on a .29 right now with 2300fps using glxgears on a mobility hd2600 and it rocks!

so quit your crying and do something. You gotta problem and whine yet I don't see you doing anything to fix it or help.

Quit complaining, they could just quit fixing issues all together and not release any code for opensource devs! AMD/ATI has been good to use and is at least trying unlike some of you flamers.

[he_the_great]

Sure he isn't. Linus didn't sign that for whatever the reason he had for not doing so. Maybe he was pragmatic or wanted to remain neutral in a way.

though see this earlier post for Linus opinion about blobs:
http://www.phoronix.com/forums/showpost.php?p=78838&postcount=78

Ah yes, I wanted to comment on Linus' stance, but didn't recall what it was, and he does a good job of explaining it.

Linus doesn't give a damn about FOSS, actually he doesn't give a damn about anything except making his life easier.

I just don't like it when people portray going against Opensource philosophy as going against Linux (unless used in the GNU/Linux form). If you want to say binary-blobs go against Linux it is only because of the assumption of a constant ABI, which is a Windows thing.

[mendieta]

I just don't like it when people portray going against Opensource philosophy as going against Linux (unless used in the GNU/Linux form). If you want to say binary-blobs go against Linux it is only because of the assumption of a constant ABI, which is a Windows thing.

I think very, very, very few people refer to the kernel when they say "Linux", but rather the whole operating system. The OS as a whole, I dare to say, is mostly developed by people who do care about freedom of choice, and therefore, the right to have access to the source code of what they use.

[MostAwesomeDude]

Ah yes, I wanted to comment on Linus' stance, but didn't recall what it was, and he does a good job of explaining it.

Linus doesn't give a damn about FOSS, actually he doesn't give a damn about anything except making his life easier.

I just don't like it when people portray going against Opensource philosophy as going against Linux (unless used in the GNU/Linux form). If you want to say binary-blobs go against Linux it is only because of the assumption of a constant ABI, which is a Windows thing.

Protip: nvidia and fglrx both consist partially of userspace blobs that act as DDX. nvidia also replaces the GLX module.

While Linus may be the pragmatic engineer, many X.Org members are of the opinion that it is impossible to maintain drivers that are out-of-tree (now out-of-fdo) and/or do not have source available. nvidia, fglrx, psb, and other drivers have demonstrated this problem amply through their inability to be usable over more than one or two revisions of the Xorg server despite only minor changes in the video DDX API.

[mendieta]

MostAwesomeDude: thanks for the insight. Question: is AMD/ATI sponsoring the open source drivers at all, besides opening the docs which is of course very nice? Do they have in-house people contributing code to the radeon and/or radeonHD repositories? Or are they at least in touch with you? If not, have they communicated whether they plan to do this in the future? (whenever the basic functionality is supported in the open source driver so they can just drop fglrx)?

If this is a FAQ documented somewhere I'll gladly read from there, please someone post the link :D

Thank you!

[Pfanne]

MostAwesomeDude: thanks for the insight. Question: is AMD/ATI sponsoring the open source drivers at all, besides opening the docs which is of course very nice? Do they have in-house people contributing code to the radeon and/or radeonHD repositories? Or are they at least in touch with you? If not, have they communicated whether they plan to do this in the future? (whenever the basic functionality is supported in the open source driver so they can just drop fglrx)?

If this is a FAQ documented somewhere I'll gladly read from there, please someone post the link :D

Thank you!

afaik they do have a few developers who work on the open source driver...
but you shouldnt forget the people who did the documentation for the cards, because that too seemed to be a shitload of work and is one of the most important parts for the development of this driver!

[mendieta]

Thanks!


but you shouldnt forget the people who did the documentation for the cards, because that too seemed to be a shitload of work and is one of the most important parts for the development of this driver!

I agree, I thought I actually mentioned that :)

[he_the_great]

I think very, very, very few people refer to the kernel when they say "Linux", but rather the whole operating system. The OS as a whole, I dare to say, is mostly developed by people who do care about freedom of choice, and therefore, the right to have access to the source code of what they use.

And most of those that do care about freedom of choice are the ones pushing that it is GNU/Linux not Linux. In any-case, drivers is one of the very few things where 'Linux' is used in reference to the kernel, whether intentional or not.

[energyman]

These drivers are great. you just need patches is all.
If you use a gentoo based distro, i've got an ebuild and fix
that will work to get them going. sorry, its a crappy ebuild
but it gets the job done.

http://www.megaupload.com/?d=8EPKR4FM

cd and extract this to /usr/portage/x11-drivers/ati-drivers/
ebuild ati-drivers-8.62.ebuild digest
emerge =ati-drivers-8.62
(after you finish emerging the ebuild doesn't work well so you need to do this)
cd /usr/portage/distfiles
chmod +x ati-driver-installer-9-6-x86.x86_64.run
./ati-driver-installer-9-6-x86.x86_64.run


what? why do you post crap like this?
a) ebuild ... digest is wrong. FOR A LONG TIME
it is ebuild ... manifest

b) what the bullshit about running the installer? NEVER RUN THE INSTALLER ON A GENTOO SYSTEM!

Where did you come up with this?

[energyman]

I hope nobody fucked up his system with Darksurf's instructions.

Here:
http://rapidshare.com/files/245611112/ati-drivers.tbz
download that
extract in /usr/local/portage/x11-drivers/
make sure you have ~arch set for ati-drivers
emerge ati-drivers
eselect opengl set ati.

AND DON'T FOLLOW THE INSTRUCTIONS FROM Darksurf!

[nanonyme]

Do they have in-house people contributing code to the radeon and/or radeonHD repositories?Yes, they do. Also afaik most of the people who have been dedicating a bigger part of their attention span on r6xx/r7xx 3D last Spring and so have been AMD/ATi paid developers (including the ones they pay Novell to provide). If it wasn't for them, we wouldn't probably have nearly as much of the r6xx/r7xx specific code done in Mesa. (community attention seems to have been focusing more on r1xx-r5xx) And yes, they keep in touch with the community developers, both directly and through bridgman. And yeah, writing a documentation books is no small feat either. :)

[mirv]

Cheers energyman.
I was going to make my own ebuild tonight, but you've saved me the trouble!

[PuckPoltergeist]

Things we don't have documentation for:

- r128, r100, r200. Don't really need it, as we understand these really well, and the code for them is rather self-documenting.
- Power management. We have most of the AtomBIOS stuff for power management, and it's being tested out, but we don't actually have docs for it. We still know how to do it, though.
- UVD/UVD2. We will never see full UVD2 docs. Get used to it. UVD is another story, though; docs for that will show up at some point. Doesn't really matter, though, since we can use a shaderful state tracker (from Gallium) to do most of what these chips do.
- Context management. This ability just doesn't exist, so of course there's no docs on it.
- AES chip. Ditto.


What about the Rialto AGP-PCIE-bridge? AGP cards still aren't really supported. :(

[nanonyme]

constant ABI, which is a Windows thing.I'm not sure if a constant ABI is that important. It doesn't even have a constant API. (and yes, I know there are reasons for this)

[mendieta]

Yes, they do. Also afaik most of the people who have been dedicating a bigger part of their attention span on r6xx/r7xx 3D last Spring and so have been AMD/ATi paid developers (including the ones they pay Novell to provide). If it wasn't for them, we wouldn't probably have nearly as much of the r6xx/r7xx specific code done in Mesa. (community attention seems to have been focusing more on r1xx-r5xx) And yes, they keep in touch with the community developers, both directly and through bridgman. And yeah, writing a documentation books is no small feat either. :)


Yes, I am sure they did have internal docs, but you need to work on them a lot before rel.easing them to the public.

Thanks, now I feel happier I bought an AMD/ATI system, and looking forward to buy a dedicated ATI PCIe card some time later this year.

Oh, and the trolls, how sad.:rolleyes:

Cheers!
:D

[djdoo]

Wow guys I am really happy about this release!!:)

At LAST Hybrid Crossfire worked for me!!! Hurray!!

And I see no garbage at my screen when the PC shuts down!!

I recommend all of you to upgrade to this driver 9.6!

[nanonyme]

Yes, I am sure they did have internal docs, but you need to work on them a lot before rel.easing them to the public.That's not at all what I said. :p I said the paid AMD/ATi developers had to write the internal docs. They published them close to last new year after which community has had the chance to participate in the coding effort. (but as I said, haven't apparently been very interested)
This conversation belongs to the opensource side, neeh?

[kensai]

Hey, guys, I'm here to help, as alway, we at Arch Linux try our best to contribute to the Linux environment. catalyst 9.6 and kernel 2.6.30 can work together it requires patching the kernel and the 9.6 catalyst, instructions:
http://www.kissuki.com/2009/06/2630-fglrx-96-arch-linux.html

Enjoy guys! I hope it works for you.

[bridgman]

Thanks, kensai. There were reports of a stream of kernel error messages when using one of these patches (but that might have been a KCL patch rather than kernel patch). Did you see anything like that ?

[kensai]

Thanks, kensai. There were reports of a stream of kernel error messages when using one of these patches (but that might have been a KCL patch rather than kernel patch). Did you see anything like that ?

In fact, I didn't see anything like that.

We still get the very awesome:
[fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7f8d6f439000,handle:0xd2400000

from dmesg ;) All in all performance is way better now at least on my laptop, and I feel happy again. :D Maybe 9.7 will make me angry again, but oh, well, that is life.

[RealNC]

I suppose AMD doesn't intent to give us a "hotfix" with new kernel support like they do with Windows.

[hpestilence]

In current wine-git + catalyst 9.6 eve-online is working perfectly without patches, probably a lot of other shader model 3 games too. :D

[kensai]

I suppose AMD doesn't intent to give us a "hotfix" with new kernel support like they do with Windows.

Why not, for Arch Linux, since we are a rolling release, you get the latest fixes, so we can slip it in in an update. For Ubuntu and the others the hotfix can be provided by SP1. LOL

[mendieta]

Wow guys I am really happy about this release!!:)

At LAST Hybrid Crossfire worked for me!!! Hurray!!

And I see no garbage at my screen when the PC shuts down!!

I recommend all of you to upgrade to this driver 9.6!

Wow! (BTW, are you the same djdoo from the compiz-fusion forums?)

This is awesome, how did you get the hybrid Crossfire set up? From the amdcccle GUI? If you posted a mini-howto or blog somewhere I'd love to take a look. I have an HD 3200 IGP, and I am planning to buy a dedicated ATI card to work in hybrid mode later this year.

Thanks in advance!

[PuckPoltergeist]

Thanks, kensai. There were reports of a stream of kernel error messages when using one of these patches (but that might have been a KCL patch rather than kernel patch). Did you see anything like that ?


The errors come from the binary blob. This can only be fixed by the ATI/AMD devs.

the patch to get the source compile with 2.6.30:

diff -Nru fglrx-orig/build_mod/drm_os_linux.h fglrx/build_mod/drm_os_linux.h
--- fglrx-orig/build_mod/drm_os_linux.h 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/drm_os_linux.h 2009-06-17 14:08:22.000000000 +0200
@@ -42,7 +42,7 @@
#define DRM_IRQ_ARGS int irq, void *arg, struct pt_regs *regs
/** backwards compatibility with old irq return values */
#ifndef IRQ_HANDLED
-typedef void irqreturn_t;
+//typedef void irqreturn_t;
#define IRQ_HANDLED /* nothing */
#define IRQ_NONE /* nothing */
#endif
diff -Nru fglrx-orig/build_mod/firegl_public.c fglrx/build_mod/firegl_public.c
--- fglrx-orig/build_mod/firegl_public.c 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/firegl_public.c 2009-06-17 15:21:09.000000000 +0200
@@ -282,6 +282,18 @@

// ================================================== ==========
/* global structures */
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,29)
+#undef pci_enable_msi
+int pci_enable_msi(struct pci_dev* dev)
+{
+ int status;
+
+ status = pci_enable_msi_block(dev, 1);
+
+ return status;
+}
+#endif //LINUX_VERSION_CODE > KERNEL_VERSION(2,6,29)
+
int ip_firegl_open(struct inode* inode, struct file* filp)
{
int m;
@@ -1226,8 +1238,6 @@
*/
int ATI_API_CALL KCL_SetPageCache_Array(unsigned long *pt, int pages, int enable)
{
- unsigned int i;
- int ret = 0;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
if (enable)
{
@@ -1238,6 +1248,8 @@
return set_memory_array_uc(pt, pages);
}
#else
+ unsigned int i;
+ int ret = 0;
for( i = 0; i < pages; i++ )
{
ret = KCL_SetPageCache((void *)pt[i], 1, enable);
@@ -1448,7 +1460,11 @@
*/
KCL_TYPE_Uid ATI_API_CALL KCL_GetEffectiveUid(void)
{
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+ return current->cred->euid;
+#else
return current->euid;
+#endif
}

/** /brief Delay execution for the specified number of microseconds
@@ -1820,15 +1836,28 @@
*/
void ATI_API_CALL KCL_PosixSecurityCapSetIPCLock(unsigned int lock)
{
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+ struct cred *new = prepare_creds();
+ if (!new) {
+ printk(KERN_ERR "fglrx: could not allocate memory\n");
+ return;
+ }
+#else
+#define new current
+#endif
if (lock == 0 )
{
- cap_lower(current->cap_effective, CAP_IPC_LOCK);
+ cap_lower(new->cap_effective, CAP_IPC_LOCK);
}
else
{
- cap_raise(current->cap_effective, CAP_IPC_LOCK);
- }
- return;
+ cap_raise(new->cap_effective, CAP_IPC_LOCK);
+ }
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+ commit_creds(new);
+#else
+#undef new
+#endif
}

/** \brief Get number of available RAM pages
diff -Nru fglrx-orig/build_mod/firegl_public.h fglrx/build_mod/firegl_public.h
--- fglrx-orig/build_mod/firegl_public.h 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/firegl_public.h 2009-06-17 14:11:15.000000000 +0200
@@ -18,6 +18,7 @@
#define _FIREGL_PUBLIC_H_

#include <stdarg.h>
+#include <asm/pgtable.h>
#include "kcl_pci.h"
#include "kcl_io.h"

@@ -600,6 +601,11 @@
#define cpu_has_pge test_bit(X86_FEATURE_PGE, &boot_cpu_data.x86_capability)
#endif

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+#undef pgprot_writecombine
+#undef pgprot_noncached
+#endif#
+
#ifndef pgprot_writecombine
#define pgprot_writecombine(prot) __pgprot((pgprot_val(prot) & ~(_PAGE_PCD)) | _PAGE_PWT)
#endif
diff -Nru fglrx-orig/build_mod/kcl_acpi.c fglrx/build_mod/kcl_acpi.c
--- fglrx-orig/build_mod/kcl_acpi.c 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/kcl_acpi.c 2009-06-17 14:33:21.000000000 +0200
@@ -18,6 +18,12 @@
#include <linux/autoconf.h>
#include <linux/acpi.h>

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+#include <../drivers/acpi/acpica/acconfig.h>
+#include <../drivers/acpi/acpica/aclocal.h>
+#include <../drivers/acpi/acpica/acobject.h>
+#endif
+
#include "kcl_config.h"
#include "kcl_type.h"
#include "kcl_acpi.h"


Changes on the linux source aren't necessary.

[Kano]

Did not try your patch yet, but how do you get rid of flush_tlb_page which is in the binary part?

[RealNC]

Kindly ask AMD for an fglrx build with the debug symbol still in :P

[PuckPoltergeist]

Did not try your patch yet, but how do you get rid of flush_tlb_page which is in the binary part?

Not sure, but either it's because auf my kernel config (had the same issue with nvidia some time ago) or flush_tlb_page ist x86 specific und doesn't occour on x86_64.
But I think we should be able to create flush_tlb_page in the fglrx sources as I've done with pci_enable_msi, if necessary.

edit:
It's the config (I'm not using SMP here) and also flush_tlb_page is only called in firegl_public.c

[cliff]

Open source is great, open source drivers are great. But when you pay over 500 bucks for what you think is the best high end card at the time 4870 X2 and the proprietary drivers are crap it kind of makes you want to never buy ATI again. I bought the 4870 x 2 so I could play the new GTA game. It was unplayable with the settings set below half. The previous
GTA looked better at this point and played smoother. At first I blamed Vista. Then I dumped Windows and Learned Linux then I dumped the ATI card and bought a mid range Nvidia card and am now playing games Google Earth works great in Jaunty as well.
Lessons learned Windows sucks, ATI's drivers suck!
P.S no I'm not playing GTA in Linux :rolleyes:
Linux Games Publishing has some great games now ported to Linux and they run great!!

[mtippett]

In current wine-git + catalyst 9.6 eve-online is working perfectly without patches, probably a lot of other shader model 3 games too. :D

Yes. That wasn't actually a driver fix, but a wine fix.

http://ati.cchtml.com/show_bug.cgi?id=1575

The problem when most developers only have one brand of card is that they assume that the implementation is correct and begin to assume that the way the majority driver is implemented is the right way.

I am not saying any driver does not have bugs, but a monoculture isn't healthy either.

Regards,

Matthew

[hpestilence]

Yes. That wasn't actually a driver fix, but a wine fix.

http://ati.cchtml.com/show_bug.cgi?id=1575

The problem when most developers only have one brand of card is that they assume that the implementation is correct and begin to assume that the way the majority driver is implemented is the right way.

I am not saying any driver does not have bugs, but a monoculture isn't healthy either.

Regards,

Matthew

Actually it was this bug that was mostly the problem.

http://ati.cchtml.com/show_bug.cgi?id=1462

Once it was fixed Henri was quick to fix a wine bug in which a shader used 15 vec4 varyings + gl_FrontColor and gl_FrontSecondaryColor.

The describeDrawable wine bug was only hit if you ran WINEDEBUG=wgl along with wine.

[mtippett]

Actually it was this bug that was mostly the problem.

http://ati.cchtml.com/show_bug.cgi?id=1462

Once it was fixed Henri was quick to fix a wine bug in which a shader used 15 vec4 varyings + gl_FrontColor and gl_FrontSecondaryColor.

The describeDrawable wine bug was only hit if you ran WINEDEBUG=wgl along with wine.

Okay my bad.

Note to others: If you find a bug, making a reproducable reduced test-case really helps. Also note the delay between engagement and release.

Matt

[energyman]

Cheers energyman.
I was going to make my own ebuild tonight, but you've saved me the trouble!

my ebuild is incomplete - it always patches for 2.6.29 and it doesn't patch for .30 yet - because I was lazy ;) Also: no reiser4 for .30 yet.

but if you have to use 2.6.28 you can comment out the epatch - and if you need .30 - adding a patch to an ebuild is easily done.

[cruiseoveride]

I just tried 9.6 with fc11 userspace and 2.6.28.10, no go.

9.5 worked with the same kernel using fc10 userspace though.

[mirv]

my ebuild is incomplete - it always patches for 2.6.29 and it doesn't patch for .30 yet - because I was lazy ;) Also: no reiser4 for .30 yet.

but if you have to use 2.6.28 you can comment out the epatch - and if you need .30 - adding a patch to an ebuild is easily done.

It's all good - I'm still running 2.6.29 anyways (I just like seeing Tuz for a bit longer).

[cutterjohn]

Downgrade to Fedora 10, compile wine-git and HL2 with catalyst 9.6 works great with radeon 4850 here all the DX9 effects on! :)That depends. With 1.1.23 (wine) and the default fbo backbuffering mode a large number of D3D apps are crashing with catalyst. Apparently some sort of inability to render a particular texture type.

Changing the rendering type to backbuffer allows some apps to get a bit further, but the only D3D app that I've tried (Guild Wars) crashing after loading when it begins to render the playscreen.

X3 Reunion doesn't render menus/text and many textures properly(black areas) using either native .dlls or wine versions so I'm inclined to believe that this is yet another catalyst bug as replacing some of the wine .dlls with native ones apparently allows it run well on nVidia parts.

Opengl based windows apps seem to work OK, or at least the only one that I tried, Minions of Mirth runs fine.

At least the horrible flickering that opengl apps exhibited a while ago is gone, just wish that they'd fix the compiz/beryl awake from sleep freeze, video playback freezes, texture rendering, etc. (These all have entries in the unofficial bugzilla already and in wine's bugzilla as well, but those are mostly broken catalyst problems and have been marked as such.)

I feel like an beta tester.

[Melcar]

...

I feel like an beta tester.

Well, the last "stable" WINE release *is* 1.0.1.
1.1.23 broke a lot of Windows installers for me; almost none of my games can install. 1.1.18-1.1.21 seem to be the best revisions.

[mklean]

Running Demigod with wine git - fbo using fglrx 9.6 renders DX9 mo-better.

I'll try Guild Wars when I get the chance and confirm if I get the same problems. Cutterjohn, you are running fglrx 9.6?

[Bitmasker]

Well, the last "stable" WINE release *is* 1.0.1.
1.1.23 broke a lot of Windows installers for me; almost none of my games can install. 1.1.18-1.1.21 seem to be the best revisions.

I can add some further (anecdotal) evidence of openGL apps under 1.1.23 not working with 9-6 (windows apps crash out, X stays up thankfully)

I've not checked 1.1.21 but have found 1.1.22 to run stably.

Ubuntu 9.04 - AMD64 2.6.28,2.6.30 with fglrx 9-6

[NeoBrain]

I can add some further (anecdotal) evidence of openGL apps under 1.1.23 not working with 9-6 (windows apps crash out, X stays up thankfully)

I've not checked 1.1.21 but have found 1.1.22 to run stably.

Ubuntu 9.04 - AMD64 2.6.28,2.6.30 with fglrx 9-6

Anyone having trouble with Wine 1.23 please try to change HKEY_CURRENT_USER/Software/Wine/Direct3D/OffscreenRenderingMode to either of the methods described at http://wiki.winehq.org/UsefulRegistryKeys.
Wine changed the default value of that thing in 1.1.23 (not sure if the info on the wiki page has been fixed accordingly, yet), so it was expectable that many apps might break (on the other hand, other areas improved with this method).
If things suddenly start working magically, file a bug in the Wine bugzilla, maybe it's just a driver bug or indeed something wrong in Wine.

[cutterjohn]

Running Demigod with wine git - fbo using fglrx 9.6 renders DX9 mo-better.

I'll try Guild Wars when I get the chance and confirm if I get the same problems. Cutterjohn, you are running fglrx 9.6?Yep, just installed it the other day and tried GW with both backbuffer AND fbo. Same results as with 1.1.22.

With backbuffer it crashes right after logging in and apparently finishing the "loading" screens, i.e. when it starts to try to render a play screen.

With fbo, it just bombs out before even getting to the login screen.

I have debugging enabled, and see no complaints of missing .dlls(Had alot of these a long time in in the 0.9x series.) Just some complaints of various shader operations not supported, and then usually a stack error.

This is WITH fbo rendering:
err:ntdll:RtlpWaitForCriticalSection section 0x7e475900 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0018, blocked by 0009, retrying (60 sec)
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.I had the same error under 1.1.22 as well IIRC, however I did not own GW until AFTER I had already gone to 1.1.22.

This is WITH bacbuffer rendering
fixme:win:EnumDisplayDevicesW ((null),0,0x33eb54,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33e228,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33dc28,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33dcb8,0x00000000), stub!
fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEn umerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found
fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEn umerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found
fixme:d3d:IWineD3DDeviceImpl_SetDialogBoxMode (0x155740) Dialogs cannot be disabled yet
err:d3d:getColorBits Unsupported format: WINED3DFMT_R32_FLOAT
fixme:d3d:IWineD3DDeviceImpl_SetDialogBoxMode (0x155740) Dialogs cannot be disabled yet
err:d3d:getColorBits Unsupported format: WINED3DFMT_R32_FLOAT
...
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #171:
fixme:d3d_shader:print_glsl_info_log Fragment shader was successfully compiled to run on hardware.
...
fixme:win:EnumDisplayDevicesW ((null),0,0x15cdad4,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x15cde50,0x00000000), stub!
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #186:
fixme:d3d_shader:print_glsl_info_log Fragment shader was successfully compiled to run on hardware.
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.'...' = skipped lines, bunch of complaints about keyboard layout stub, the GLSL error I'm guessing aren't a problem, but then at the end we also see that we die with the same error.

The Steam client itself seems to run OK, which is what I used to install GW.

I read all about the massive installer problems w/1.1.23 AFTER I started looking for "fixes" for my wine problems again. As a matter of fact, I noted that the reports appeared for the SVN version BEFORE 1.1.23 was even released. Seems like someone dropped the ball on that...

Just to be clear I've got catalyst 9.6, Ubuntu 9.04 x86-64(latest updates), and wine 1.1.23 on an MSI GT725-074US.

As to the offscreenrendering mode when defaulted to fbo, as wine does now when there is no registry key entry, crashes just about everything using D3D and the catalyst drivers. Creating the key and setting the value to backbuffer allows many D3D programs to get further, however in my case(s) above(this post, as well as others) I'm right back to where I was before.

Doing a good deal of searching on the winehq.org pages, and the web it seems that the problem is the inability of catalyst to render certain types of textures, and seems to have been deemed a catlyst driver bug by the wine developers.

The reason that I feel like a beta tester is that the only measurable improvement I can see over the catalyst version from 9.2 IS the fix to remove screen flicker when an opengl app was running in a window, and the apparent removal of random screen corruption from 9.5->9.6 or at least I haven't observed it(corruption) yet with 9.6.

I STILL get random video playback freezing X.org(rest of the machine is probably up, but I've got no backup machine ATM to try to ssh in to this one), as the ALT-PRTSCR+RSEINUB reboots ok.

I also STILL get freezes upon waking from sleep/hibernate with compiz/beryl enabled. Other users have reported this as well, IIRC we had a bried discussion about it in the 9.5 thread.

Pretty much the low quality of catalyst X.org drivers have pretty much forced me to give up on using linux + X.org for anything even remotely graphically intensive for fear or hardlocking the machine and/or triggering other wonder catalyst bugs which seem to be endless in number and severe in nature.

[Bitmasker]

Anyone having trouble with Wine 1.23 please try to change HKEY_CURRENT_USER/Software/Wine/Direct3D/OffscreenRenderingMode to either of the methods described at http://wiki.winehq.org/UsefulRegistryKeys.
Wine changed the default value of that thing in 1.1.23 (not sure if the info on the wiki page has been fixed accordingly, yet), so it was expectable that many apps might break (on the other hand, other areas improved with this method).
If things suddenly start working magically, file a bug in the Wine bugzilla, maybe it's just a driver bug or indeed something wrong in Wine.

Despite this being a Direct3D key it allowed my opengl game to load without error under wine 1.1.23 (with OffscreenRenderingMode -> backbuffer). Thanks!

[mklean]

The texture/crash issue is fixed in wine.git (http://source.winehq.org/git/wine.git/?a=commit;h=7599520321e3fbb7fe6ed4cfe237c564c4647f 5a), at least for the fbo. This problem should be resolved in the 1.1.24.

I ran into the installer bug for GW with 1.1.23. I'll need to back down to 1.1.21. Unfortunately I have a busy weekend ahead so I'm not sure when I will get the time.

[Darksurf]

I hope nobody fucked up his system with Darksurf's instructions.

Here:
http://rapidshare.com/files/245611112/ati-drivers.tbz
download that
extract in /usr/local/portage/x11-drivers/
make sure you have ~arch set for ati-drivers
emerge ati-drivers
eselect opengl set ati.

AND DON'T FOLLOW THE INSTRUCTIONS FROM Darksurf!

What the heck are you talking about? I am using the drivers right now with absolutely no problems. This also was for a gentoo based distro.
Cant help it if you aren't linux savy enough to follow simple instructions. If anyone uses a gentoo based distro and would like help with this, I'll gladly give step by step instructions on how to do it.
This way it can easily be removed using portage and upgraded when a better version or ebuild comes out.

Till then, don't tell people not to listen to others just cause you don't understand or cannot follow instructions. If you've got a better ebuild then just say so, no need to attack others.

[energyman]

oh yeah? skipping 'eselect opengl set ati' and then forcing the ati libs into the system by the installier is simply braindead. If you can't even understand why that is stupid you shouldn't even use a gentoo based system. Harsh, yes. But true.

If I must remind you. In gentoo, opengl is managed by different diurs for the implementations. eselect then sets the correct symlinks.

So far, so good. This gives a lot of flexibility. And cleanliness.
If you use the installer, it writes the files where the symlinks should go. Suddenly you can not switch around easily (which had to be done for some apps to compile in the past). Suddenly you have crap not managed by any package manager in the system.
Pure idiocy.

[cruiseoveride]

This driver is pure evil. Look at how otherwise sane people are now ready to kill each other.

By the way, i got the sucker working on ubuntu 9.04 x86_64, with kernel 2.6.28.13

[Darksurf]

oh yeah? skipping 'eselect opengl set ati' and then forcing the ati libs into the system by the installier is simply braindead. If you can't even understand why that is stupid you shouldn't even use a gentoo based system. Harsh, yes. But true.

If I must remind you. In gentoo, opengl is managed by different diurs for the implementations. eselect then sets the correct symlinks.

So far, so good. This gives a lot of flexibility. And cleanliness.
If you use the installer, it writes the files where the symlinks should go. Suddenly you can not switch around easily (which had to be done for some apps to compile in the past). Suddenly you have crap not managed by any package manager in the system.
Pure idiocy.

My my, is flaming the only thing your good at? I used slackware for 4 years and never had the need for a package manager to do my work for me. R you saying that you cannot manage your own computer without the help of a package manager or a GUI? If you cannot do this you have no right to ridicule me. at least I made an effort instead of crying like some of your friends. You make a mountain out of a mole hill. These things are easily fixed. Quit your crying.

Instead of flaming, help others. Ebuild manifest is one way to do things, ebuild digest is the way i've been doing it for a couple years now. I've had no problems and it works fine. Don't see what your complaint is there.

Also, you did a good job on the ebuild, just needed a little TLC for some of us so I gave it a little update for the 2.6.30 kernel users
and those who use Xen. I'm not trying to show you up or anything, I'm just out to help.

http://www.megaupload.com/?d=ZY31Q2ZK

This should work for both 2.6.29 and 2.6.30.

cd and extract in /usr/portage/x11-drivers/ati-drivers
ebuild ati-drivers-8.624.ebuild manifest (yeah, it works too)
emerge ati-drivers
eselect opengl set ati

Energyman, Thanx for a working ebuild. Gentoo is still kinda new to me. I've used Slackware most my life. No need to be nasty, we can all be nice and help out each other without flaming. ;)

[RealNC]

Gentoo isn't Slackware. You aren't supposed to do things by hand in Gentoo. There are tools you should use, or you break the system. So your instructions are not for everyone. If you don't know how to unbreak the system, don't follow them. If you know how to unbreak your system, I suppose you didn't need those instructions in the first place :D

[Darksurf]

Gentoo isn't Slackware. You aren't supposed to do things by hand in Gentoo. There are tools you should use, or you break the system. So your instructions are not for everyone. If you don't know how to unbreak the system, don't follow them. If you know how to unbreak your system, I suppose you didn't need those instructions in the first place :D

You do have a point, but any linux system allows you to do things by hand. Thus the freedom and flexability of linux. You don't always need to use the tools, they are helpful, yet sometimes they do hinder your possibilities. Gentoo and Slackware users should usually be advanced users. Many novice users use ubuntu (no insult intended) and have tools to do these things for them, but some advanced users want to push the limits of what the tools allow. Improvisation is then used to acquire what is wanted and allows those who are yet advanced to learn.

Slackware is like linux bootcamp. You do EVERYTHING by hand so you understand linux and how the file structure, files, etc work. So if something goes wrong you know how to fix it without GUI and/or tools and sometimes you just make your own tools and scripts. That is how i learned. I'm sure gentoo users can handle themselves just fine with the basic knowledge of how linux and the files work. And novice users of Gentoo can use Sabayon (its what I use). It has a binary package manager as well as portage and they are compatible with each other. Thus allowing advanced users and novice users to use what they prefer and giving an OOTB (out-of-the-box) experience.

But again, you do have a point. Those not of an advanced nature wouldn't be happy with the results unless they had help. :)

[doubledr]

guys, calm down. But, Darksurf, energyman is right. If we follow your way, then the /usr/lib/libGL.so symlink will have a big trouble in compiling new x-server, mesa, libdrm etc, because the portage will delete the symlink at the switching OpenGL library stage and cause an error in compiling.

[Laughing1]

Anyone have a patch for opensuse 11.2 [?], it uses kernel 2.6.30. :)

[JDifool]

Just thought I might give my experience to all the complainers around here.

My first ATI 4850 died for some obscure reason, and since I heard that the NVIDIA UNIX driver was so much better than the ATI one, I replaced it by a 9800GT (big mistake in terms of performance over the 4850 i know, but the price tag of the GTX260 is way higher...).

So i came back home, and installed the NVIDIA driver. So far so good.
I'm using Slackware 12.1 with 2.6.27, compiz with rox-filer. I noticed no real difference at first since I had no real problem with the latest ATI apart from the openGL apps. XV was fine with both drivers (mplayer patched to make it work with compiz), compiz too.

At some point, using the scale compiz module, hard freezes came to happen. Bad news indeed, since I figured out that the NVIDIA team, despite numerous reports of the same error, just isn't ready to fix it for some obscure reason (to my knowledge at least). The NV forum is also loaded with unhappy users (but none of them are yelling that ATI is better, for some reason :)).

I switched back to the 4850 because it's much better in Dos Games compared to the 9800 GT (even GTX). The driver seems fine with me in Linux overall, I can watch 1080p HD movies without any performance issue in Compiz, I can play OpenGL games too. Sure the latest kernel isn't supported, and I understand it might be frustrating for the latest develoment (which ones, out of curiosity ?). But, it does mostly what it is supposed to do, isn't it ?

Things are going better now, and will keep going this way I'm sure.
Grass is always greener next door.

Enjoy! :)

[cutterjohn]

fbo offscreen rendering appears to have been fixed in wine 1.1.24 which has just been released. Also X3R got fixed for me as well, in that the menu now renders and so do ingame textures, although all of the "normal" wine problems still exist. i.e. requires native libraries for movie playback, trading, etc. mouse is EXTREMELY laggy.

So those, apparently were actually wine bugs and not fglrx bugs.

GW still crashes as normal, and still wants to repair the archive every startup. The latter is definitely a wine bug, while I'm not at all sure about the cause of the former. In any even it now actually crashes in the loading screen itself instead of seeming to get as far as starting to render the playscreen.

My sleep & video playback & other assorted bugs remain which I'm still pointing the finger at fglrx for as in the sleep freeze problem disabling compiz/beryl works around that one.

@jdifool
The 192SP 260 is about the same price as the 4850 while the 216SP is c. $50 more which is not alot more, and it IS a better performing card than the 4850. The 216SP 260 IS going into my i7 build because of these drivers. (Briefly consider CF 4770s, but NOT with these drivers.)

[JDifool]

Nice link to the 216sp, it wasn't out when I bought my 4850 (and I think my shuttle would have to be modded for the card to fit...)
It doesn't change my point though.

Thanks for the info.
cheers.

[Fixxer_Linux]

Gentoo isn't Slackware. You aren't supposed to do things by hand in Gentoo. There are tools you should use, or you break the system. So your instructions are not for everyone. If you don't know how to unbreak the system, don't follow them. If you know how to unbreak your system, I suppose you didn't need those instructions in the first place :D

Very true.
However, for those who feel adventurous, here's a post in Gentoo forums that explains how to install a fglrx driver which is not in the portage tree (stucked in 9.3 probably for compatibility reasons ?).
http://forums.gentoo.org/viewtopic-t-772478-highlight-.html

In a nutshell, it's about creating a local overlay, copy the ebuild files from portage tree, modify them to accept 9.5 or 9.6 drivers, manifest them and finally emerge them.

This looks simple, but there is few caveats to avoid in order to keep a nice and clean running gentoo.

I have to admit that I didn't follow that topic, as I'm part of the guys who don't know how to unbreak my system. So, I'm waiting patiently the update in the official portage tree. Much safer.

[RealNC]

You can read the official documentation on how to create overlays rather than some people writing on forums :P

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=5#doc_chap2

[DogWizard]

The errors come from the binary blob. This can only be fixed by the ATI/AMD devs.

the patch to get the source compile with 2.6.30:

diff -Nru fglrx-orig/build_mod/drm_os_linux.h fglrx/build_mod/drm_os_linux.h
--- fglrx-orig/build_mod/drm_os_linux.h 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/drm_os_linux.h 2009-06-17 14:08:22.000000000 +0200
@@ -42,7 +42,7 @@
#define DRM_IRQ_ARGS int irq, void *arg, struct pt_regs *regs
/** backwards compatibility with old irq return values */
#ifndef IRQ_HANDLED
-typedef void irqreturn_t;
+//typedef void irqreturn_t;
#define IRQ_HANDLED /* nothing */
#define IRQ_NONE /* nothing */
#endif
diff -Nru fglrx-orig/build_mod/firegl_public.c fglrx/build_mod/firegl_public.c
--- fglrx-orig/build_mod/firegl_public.c 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/firegl_public.c 2009-06-17 15:21:09.000000000 +0200
@@ -282,6 +282,18 @@

// ================================================== ==========
/* global structures */
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,29)
+#undef pci_enable_msi
+int pci_enable_msi(struct pci_dev* dev)
+{
+ int status;
+
+ status = pci_enable_msi_block(dev, 1);
+
+ return status;
+}
+#endif //LINUX_VERSION_CODE > KERNEL_VERSION(2,6,29)
+
int ip_firegl_open(struct inode* inode, struct file* filp)
{
int m;
@@ -1226,8 +1238,6 @@
*/
int ATI_API_CALL KCL_SetPageCache_Array(unsigned long *pt, int pages, int enable)
{
- unsigned int i;
- int ret = 0;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
if (enable)
{
@@ -1238,6 +1248,8 @@
return set_memory_array_uc(pt, pages);
}
#else
+ unsigned int i;
+ int ret = 0;
for( i = 0; i < pages; i++ )
{
ret = KCL_SetPageCache((void *)pt[i], 1, enable);
@@ -1448,7 +1460,11 @@
*/
KCL_TYPE_Uid ATI_API_CALL KCL_GetEffectiveUid(void)
{
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+ return current->cred->euid;
+#else
return current->euid;
+#endif
}

/** /brief Delay execution for the specified number of microseconds
@@ -1820,15 +1836,28 @@
*/
void ATI_API_CALL KCL_PosixSecurityCapSetIPCLock(unsigned int lock)
{
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+ struct cred *new = prepare_creds();
+ if (!new) {
+ printk(KERN_ERR "fglrx: could not allocate memory\n");
+ return;
+ }
+#else
+#define new current
+#endif
if (lock == 0 )
{
- cap_lower(current->cap_effective, CAP_IPC_LOCK);
+ cap_lower(new->cap_effective, CAP_IPC_LOCK);
}
else
{
- cap_raise(current->cap_effective, CAP_IPC_LOCK);
- }
- return;
+ cap_raise(new->cap_effective, CAP_IPC_LOCK);
+ }
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+ commit_creds(new);
+#else
+#undef new
+#endif
}

/** \brief Get number of available RAM pages
diff -Nru fglrx-orig/build_mod/firegl_public.h fglrx/build_mod/firegl_public.h
--- fglrx-orig/build_mod/firegl_public.h 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/firegl_public.h 2009-06-17 14:11:15.000000000 +0200
@@ -18,6 +18,7 @@
#define _FIREGL_PUBLIC_H_

#include <stdarg.h>
+#include <asm/pgtable.h>
#include "kcl_pci.h"
#include "kcl_io.h"

@@ -600,6 +601,11 @@
#define cpu_has_pge test_bit(X86_FEATURE_PGE, &boot_cpu_data.x86_capability)
#endif

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+#undef pgprot_writecombine
+#undef pgprot_noncached
+#endif#
+
#ifndef pgprot_writecombine
#define pgprot_writecombine(prot) __pgprot((pgprot_val(prot) & ~(_PAGE_PCD)) | _PAGE_PWT)
#endif
diff -Nru fglrx-orig/build_mod/kcl_acpi.c fglrx/build_mod/kcl_acpi.c
--- fglrx-orig/build_mod/kcl_acpi.c 2009-05-30 01:21:53.000000000 +0200
+++ fglrx/build_mod/kcl_acpi.c 2009-06-17 14:33:21.000000000 +0200
@@ -18,6 +18,12 @@
#include <linux/autoconf.h>
#include <linux/acpi.h>

+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,28)
+#include <../drivers/acpi/acpica/acconfig.h>
+#include <../drivers/acpi/acpica/aclocal.h>
+#include <../drivers/acpi/acpica/acobject.h>
+#endif
+
#include "kcl_config.h"
#include "kcl_type.h"
#include "kcl_acpi.h"


Changes on the linux source aren't necessary.


Thank you for the patch - most elegant I have found on the net.
Kano, I can confirm it works with 2.6.30 unmodified kernel - at least on my openSUSE_11.1 system.

For 2.6.30-git18 and catalyst 9-6 I found that the following one patch to the linux kernel:
add "EXPORT_SYMBOL(find_task_by_vpid);" in pid.c
also makes your patch work with 2.6.30-git18, so fglrx will probably work with 2.6.31 as well.

Looking forward to your patch for 2.6.31 without modified kernel sources!

[Kano]

Maybe it is only needed for 32 bit.

[PuckPoltergeist]

Maybe it is only needed for 32 bit.

You mean flush_tlb_page? I don't find it in the driver, neither in the glue layer nor in the binary. :confused:

[Kano]

Did you try 9-3 and other drivers too? 9-3 is needed for older cards too. Of course not possible for Xserver 1.6.

[PuckPoltergeist]

Did you try 9-3 and other drivers too? 9-3 is needed for older cards too. Of course not possible for Xserver 1.6.

No, I've only checked 9.6 cause the patch is only made for 9.6.

[Kano]

Usually the same patch works at least down to 9-2 (did not test older ones). I did not try this patch however, but the fglrx kernel module code did not change much...

[RealNC]

9.2... Seems like yesterday. Not!

5 months passed and AMD still hasn't figured out how to support anything newer then 2.6.28.

Great.

[FunkyRider]

So, after cutting half their produce line off (X1K and below), they still can't get things a little bit better.

Why don't ATI drop support for fglrx at all? so they can save some money to put into better place.

[RealNC]

They introduced kernel 2.6.9 support (not a typo, that's 2.6.9) with Catalyst 9.6. So they *are* working.

Sigh.

[kensai]

I forgot to tell, but I have a catalyst 9.6 working with a stock kernel 2.6.30 without patching the kernel. Just a whole bunch of patches for catalyst. http://aur.archlinux.org/packages.php?ID=22899 there you go guys, enjoy.

[energyman]

or you use the officila 9.6 ebuild from portage and also get all patches and no need for kernel patching.

[kensai]

Kudos to the gentoo devs, for having all those patches in fact, I got most of them from gentoo.

[cutterjohn]

Actually since "upgrading" to kernel 2.6.28-13.45 on Ubuntu 9.04 I'm starting to observe graphic corruption in 2d desktop (compiz/beryl off). MSI GT725-074US 4850 mobility radeon. x86-64

This time around it's rectangular areas of the screen where the background turns black, and is clearable by switching virtual desktops or otherwise forcing a screen refresh.

Also observed a very small line of 5-10 pixels(horizontal) corruption that appeared while using firefox.

NOTE: I did NOT bother to rebuild/install catalyst 9.6 with the upgrade as it was a minor change, and have not yet installed the latest minor kernel update.

Initially I thought that it might be heat related problems, but the GPU was reporting temps of c. 50C when I first noticed the problem. Also I have not observed this problem under Vista, but there I have a relatively ancient catalyst (8.12) as I can't be bothered to experiment with the dontargue method of overriding idiotic vendor lockins. (Thanks AMD! I REALLY appreciate that!) (Also have to find where I put my Vista backup disks... just in case the dontargue method goes horribly wrong, and maybe time for the MSI mystery BIOS update too...)

Oh yeah, still experiencing random hard locks when playing back video. Seems to occur most commonly AFTER waking from sleep, reqing ALT-PRTSCR+RSEINUB. (This NEVER comes back, as I've left it frozen for up to 15m to see if it was similar to another problem that Ive read about with older ATI card IIRC, where video would freeze for 30s or so then resume "normal" operation.)

[AdrenalineJunky]

actually, i've noticed an improvement with this driver release in one area.

using Xv rendering in Mplayer i get no video tearing with compositing enabled.

games on the other hand still seem to have the tearing issue.

for anyone curious i'm using arch/2.6.30

[bridgman]

Also I have not observed this problem under Vista, but there I have a relatively ancient catalyst (8.12) as I can't be bothered to experiment with the dontargue method of overriding idiotic vendor lockins. (Thanks AMD! I REALLY appreciate that!)

Sorry, but I'm not having any luck parsing this. Can you help me understand what you mean here ?

[NeoBrain]

Actually since "upgrading" to kernel 2.6.28-13.45 on Ubuntu 9.04 I'm starting to observe graphic corruption in 2d desktop (compiz/beryl off). MSI GT725-074US 4850 mobility radeon. x86-64

This time around it's rectangular areas of the screen where the background turns black, and is clearable by switching virtual desktops or otherwise forcing a screen refresh.

Also observed a very small line of 5-10 pixels(horizontal) corruption that appeared while using firefox.

NOTE: I did NOT bother to rebuild/install catalyst 9.6 with the upgrade as it was a minor change, and have not yet installed the latest minor kernel update.

Initially I thought that it might be heat related problems, but the GPU was reporting temps of c. 50C when I first noticed the problem. Also I have not observed this problem under Vista, but there I have a relatively ancient catalyst (8.12) as I can't be bothered to experiment with the dontargue method of overriding idiotic vendor lockins. (Thanks AMD! I REALLY appreciate that!) (Also have to find where I put my Vista backup disks... just in case the dontargue method goes horribly wrong, and maybe time for the MSI mystery BIOS update too...)

Oh yeah, still experiencing random hard locks when playing back video. Seems to occur most commonly AFTER waking from sleep, reqing ALT-PRTSCR+RSEINUB. (This NEVER comes back, as I've left it frozen for up to 15m to see if it was similar to another problem that Ive read about with older ATI card IIRC, where video would freeze for 30s or so then resume "normal" operation.)

That might still be due to the kernel upgrade, if it doesn't find your fglrx kernel module, it's normal that things don't work ;)
Try doing "sudo modprobe fglrx" and see if "dmesg | grep -i fglrx" gives any errors, if either print some error message you should try to rebuild your kernel module.