AMD Catalyst 9.1 Brings OpenGL 3.0

[nbi1]

It's probably more appropriate to say "that the bulk of ATI's Linux customers have deemed worthy of attention", but I understand your point.

We have been increasing focus on consumer users over the last year, starting with Ubuntu (IIRC you already had the driverw working on Ubuntu ?) and the "fragility" you talk about, which IMO is more related to the installer being not quite sufficiently sophisticated yet, will disappear over time. Given the complaints I'm already hearing about the "relatively old" kernel and Xorg in Lenny I suspect the install issues will turn out to be pretty trivial.

That said, depending on how much you want to live on the leading edge of Linux and X development, you may eventually find that the open source drivers actually do a better job of making you happy than anyone's binary driver. Good luck with whatever direction you take.

To be precise the highest level of success I achieved with any ATI driver was to get 8.561 (Catalyst 8.12) working with the stock Intrepid kernel (2.6.27-9). *But* (and there always is a "but" with ATI drivers) I was unable to get that rebuilt for use with the 2.6.28 kernel under Intrepid. So ATI is essentially holding me hostage to a particular kernel of a particular distro. Sounds like MS Windows doesn't it? For many linux users who upgrade their HW incrementally and depend on current kernels to provide support that sort of thing is totally unacceptable.

And it really isn't surprising that the ATI driver works under Ubuntu. Phoronix published an article about the rapport between Canonical and ATI. My question on that is why was Canonical singled out and why does ATI not believe it's in their interest to make that same info available to other distros so that they may do whatever is neccessary to package the driver in a friendly and robust way for their end users?

I continue to be astonished why your AMD masters are tolerating these antics on the part of ATI. Clearly with regards to the linux driver ATI's philosophies and conduct have not advanced AMD's interests.

[bridgman]

To be precise the highest level of success I achieved with any ATI driver was to get 8.561 (Catalyst 8.12) working with the stock Intrepid kernel (2.6.27-9). *But* (and there always is a "but" with ATI drivers) I was unable to get that rebuilt for use with the 2.6.28 kernel under Intrepid. So ATI is essentially holding me hostage to a particular kernel of a particular distro. Sounds like MS Windows doesn't it? For many linux users who upgrade their HW incrementally and depend on current kernels to provide support that sort of thing is totally unacceptable.

Were we actually holding you hostage to a specific kernel, or had we just not yet fixed issues related to the specific and recent kernel you wanted to use ?

And it really isn't surprising that the ATI driver works under Ubuntu. Phoronix published an article about the rapport between Canonical and ATI.

This one is news to me; can you give me a hint how to find the article ?

Ubuntu works because we test on Ubuntu, along with RHEL and the SuSE distros.

My question on that is why was Canonical singled out and why does ATI not believe it's in their interest to make that same info available to other distros so that they may do whatever is neccessary to package the driver in a friendly and robust way for their end users?

We picked Ubuntu as the next distro to support because over 50% of our non-enterprise user requests were for Ubuntu. Nothing else was even close. Next on the list were Fedora and Debian, although both were well behind Ubuntu). We figured that adding support for Ubuntu would at least help with Debian issues in the same way that supporting RHEL was helping a bit with Fedora.

The packaging scripts are maintained in an open repository on Phorogit so you can see who is maintaining them. I think one of our guys is maintaining the Debian scripts in his spare time in the absence of anyone from the Debian community volunteering.

AFAIK we make the same information and beta access available to any distro; if you hear anything different please let me know.

I continue to be astonished why your AMD masters are tolerating these antics on the part of ATI. Clearly with regards to the linux driver ATI's philosophies and conduct have not advanced AMD's interests.

To be clear, which antics are you talking about ? We work with people across AMD to determine where to set priorities. I know you would obviously be happier if we favored Debian over SLES and RHEL, for example, or favoured bleeding-edge kernels and Xorg releases over stodgy enterprise distro releases, but that is not the direction indicated either by the majority of our customers or by our internal business folks.

Can I ask you a question ? Once we have open source 3D support for 6xx/7xx up to the same level as 5xx (roughly GL 1.4) with some performance improvements, will that meet your needs for work on Debian or are you using Debian as a primary gaming / commercial workstation system ?

[RealNC]

The various distros should package Catalyst in their repos just like they do with every other software. And also keep it up-to-date. I don't see why Catalyst should support all distros out there out of the box. Even in Gentoo (the one I use), which is probably the most hostile environment for binary-only packages, you can install Catalyst easily ("emerge ati-drivers"). The distro itself knows best how to install a piece of software.

[nbi1]

The point that I was trying to make is that the packaging of 3rd party drivers can have varying degrees of difficulty. If it's too difficult and/or tedious then if left entirely to the distro packagers there will be a schedule hit. If there is close cooperation between the vendor and distro packager then things go smoothly. In the absence of such cooperation it's the vendors responsibility to take initiative and make sure it gets done. This should require no prodding, it's in the vendor's own interest to get this done. OTOH, if the vendor doesn't really care about linux then distro packaging issues make a nice excuse.

[nbi1]

Oh my god I got it working.

Ubuntu has perverted the build process IMHO, but if you look to the next release level for the source package you need you may find it. So in my case I utilized the 2.6.28 package from Jaunty. Using the source package rather than a tarball from kernel.org is the path to success. A tarball could be used but .debs will need to be generated from it first.

Creating an initrd has become a real clusterf*ck so it's best to skip it if possible. Just compile what you need into the kernel.

This is where the gotcha lies, identifying exactly what is needed. In the case of fglrx something not obvious needs to be loaded as a module. Yes, I know all the obvious modules that need to be loaded. Previously I tried creating /etc/modules manually based on all the available info as to what is needed, but that wasn't working. I then decided to brute force it by using the .config from 2.6.27-9 to build the 2.6.28 kernel and using the output of `lsmod` (while 2.6.27-9 is booted) to populate /etc/modules for the 2.6.28 boot. Sure enough that works. Had the nagging feeling that a solution was close.

Next job is to figure out which of the loaded modules is the magic ingredient for making it all work. Then I can strip out all the kacka that Ubuntu throws in by default.

[Kano]

You can skip the initrd when you use native root option not UUID when you check with

cat /proc/cmdline

or in /boot/grub/menu.lst or in case of grub2 it is a setting in /etc/default/grub. But I would highly recommend using an initrd until you optimize for fast booting to gain a tiny bit speed. Especially with multiply controllers life is much easier with UUIDs. When you look at the Ubuntu 2.6.28 release thead I descibed how to create debs from any kernel. If you want to use ubuntu's 2.6.28 on older systems it is a bit tricky. If needed i could explain that too as i do that always for Kanotix

[Vighy]

To be precise the highest level of success I achieved with any ATI driver was to get 8.561 (Catalyst 8.12) working with the stock Intrepid kernel (2.6.27-9). *But* (and there always is a "but" with ATI drivers) I was unable to get that rebuilt for use with the 2.6.28 kernel under Intrepid. So ATI is essentially holding me hostage to a particular kernel of a particular distro. Sounds like MS Windows doesn't it? For many linux users who upgrade their HW incrementally and depend on current kernels to provide support that sort of thing is totally unacceptable.

strange because in gentoo is so simple to switch between kernels when it compiles.
If the driver supports the kernel, or you've got a patch, then the fglrx works.

What ubuntu does with kernel modules is somewhat obscure. That's why it may not work

Obviously there are no packaging scripts for gentoo: we maintain our ebuilds (IIRC thanks to dberkholz and je_fro ) that work really well!

The problem with fglrx is that just 1-2% of ATi's customers use it.
If home people using linux were at least the 25% of AMD's the market, fglrx would have been a great driver!

[nbi1]

strange because in gentoo is so simple to switch between kernels when it compiles.
If the driver supports the kernel, or you've got a patch, then the fglrx works.

What ubuntu does with kernel modules is somewhat obscure. That's why it may not work

Obviously there are no packaging scripts for gentoo: we maintain our ebuilds (IIRC thanks to dberkholz and je_fro ) that work really well!

The problem with fglrx is that just 1-2% of ATi's customers use it.
If home people using linux were at least the 25% of AMD's the market, fglrx would have been a great driver!

LOL. "obscure" is being very generous.

I completely agree. It should be easy. And in the past it has been. I think in their attempts to differentiate their distros some linux vendors have gotten too cute with distro specific methods and techniques. And some developers have actually bought into this (I won't mention names, they know who they are. ). Maybe it would be a good idea to think about a plain vanilla standard approach to these sorts of things, something in the spirit of how LSB addresses init.

[nbi1]

Were we actually holding you hostage to a specific kernel, or had we just not yet fixed issues related to the specific and recent kernel you wanted to use ??

Same thing, isn't it?

This one is news to me; can you give me a hint how to find the article ?

Summer of 2008. Yeah I know, Phoronix doesn't seem to have a good search function for archived articles.

Ubuntu works because we test on Ubuntu, along with RHEL and the SuSE distros.



We picked Ubuntu as the next distro to support because over 50% of our non-enterprise user requests were for Ubuntu. Nothing else was even close. Next on the list were Fedora and Debian, although both were well behind Ubuntu). We figured that adding support for Ubuntu would at least help with Debian issues in the same way that supporting RHEL was helping a bit with Fedora.

The packaging scripts are maintained in an open repository on Phorogit so you can see who is maintaining them. I think one of our guys is maintaining the Debian scripts in his spare time in the absence of anyone from the Debian community volunteering.

AFAIK we make the same information and beta access available to any distro; if you hear anything different please let me know.

Not quite sure how you're coming up with the numbers to make vendor decisions, but Debian has held top linux server share for some time (at least according to Linux Journal). I have created hosted servers that utilize Debian as the platform OS and when it comes to stability it's 2nd to none. Obviously server share numbers don't have directly applicable meaning for desktop video cards, but it isn't a big jump to conclude that if it's solid for servers then it might be solid for desktops too.

To be clear, which antics are you talking about ? We work with people across AMD to determine where to set priorities. I know you would obviously be happier if we favored Debian over SLES and RHEL, for example, or favoured bleeding-edge kernels and Xorg releases over stodgy enterprise distro releases, but that is not the direction indicated either by the majority of our customers or by our internal business folks.

Can I ask you a question ? Once we have open source 3D support for 6xx/7xx up to the same level as 5xx (roughly GL 1.4) with some performance improvements, will that meet your needs for work on Debian or are you using Debian as a primary gaming / commercial workstation system ?

The antics of constantly promising cool things and failing to have even basic functionality available. Functionality which apparently nVidia has had for some time.

I've said it many times. Just give me solid 2D. I use my workstation to do commercial video editing using tools available under Windows and Linux. More and more tools/utilities are being developed/ported to linux every day. mencoder, ffmpeg, and dvd authoring are already pretty good under linux. Sometimes I need to boot into Windows to use Avisynth and related tools, but hopefully the day draws near when booting into Windows won't be neccessary at all.

Having said all that, I am somewhat mollified by at last (after about 6 weeks of futzing around) getting 8.561 working with 2.6.28 under Intrepid. Maybe I don't have to buy that nVidia card just yet.

Question: Why is there a version and release number? For example, 8.56.4 and 8.561? This was quite disconcerting until I saw the two linked together in the Xorg log file.

[bridgman]

Same thing, isn't it?

Not really; you said that we were "locking you into one kernel", I'm pretty sure we don't lock you into a single kernel and therefore we can't "fix it". What I guess you mean is "I would like you to support new kernels more quickly", which is a fair point and something we do want to improve.

Summer of 2008. Yeah I know, Phoronix doesn't seem to have a good search function for archived articles.

OK, thanks; I'll keep looking.

Not quite sure how you're coming up with the numbers to make vendor decisions, but Debian has held top linux server share for some time (at least according to Linux Journal). I have created hosted servers that utilize Debian as the platform OS and when it comes to stability it's 2nd to none. Obviously server share numbers don't have directly applicable meaning for desktop video cards, but it isn't a big jump to conclude that if it's solid for servers then it might be solid for desktops too.

We're looking at client numbers; server drives the CPU market but client drives the GPU market.

The antics of constantly promising cool things and failing to have even basic functionality available. Functionality which apparently nVidia has had for some time.

This is where I get that confused look on my face. I don't think we're promising *anything* other than to keep improving the drivers and to be open about where we focus our testing so that you know which distros are likely to be relatively hassle-free. We have said in the past that we were working towards approximate feature parity with other OSes and on improving support for consumer users, but AFAIK that's it.

I've said it many times. Just give me solid 2D. I use my workstation to do commercial video editing using tools available under Windows and Linux. More and more tools/utilities are being developed/ported to linux every day. mencoder, ffmpeg, and dvd authoring are already pretty good under linux. Sometimes I need to boot into Windows to use Avisynth and related tools, but hopefully the day draws near when booting into Windows won't be neccessary at all.

If you're just looking for solid 2D (I guess you're lumping video in with 2D ?) then you may find that the open soruce drivers rapidly become your driver of choice. They go one step past "timely support of new xorg and kernel code", since they are actually used to develop and test that new xorg & kernel code.

Having said all that, I am somewhat mollified by at last (after about 6 weeks of futzing around) getting 8.561 working with 2.6.28 under Intrepid. Maybe I don't have to buy that nVidia card just yet.

Oh good

Question: Why is there a version and release number? For example, 8.56.4 and 8.561? This was quite disconcerting until I saw the two linked together in the Xorg log file.

I don't understand this one either, but I am trying to find out. AFAIK there should only be one version.