My horrible experience with ATI

[muep]

The official support for kernels is more or less settling into the distribution release cycle for us. It means that we may skip restabilizing for a kernel if there are not distros targetting that kernel. For example, Karmic is targetting 2.6.31, and so our work is primarily focused on that kernel (targetted at Karmic's release).

I understand that AMD is free to choose what they are going to support. I still find it a bit offensive that they choose to go so much un Ubuntu's terms. Fedora 11 (which I use) has Linux 2.6.29, which Catalyst doesn't support, despite the fact that even 2.6.30 is already available. Sounds also like we won't be getting Catalyst in the July release, either

Luckily I have the free drivers. Some would certainly like to use OpenGL software on Fedora 11, too.

[mtippett]

I understand that AMD is free to choose what they are going to support. I still find it a bit offensive that they choose to go so much un Ubuntu's terms. Fedora 11 (which I use) has Linux 2.6.29, which Catalyst doesn't support, despite the fact that even 2.6.30 is already available. Sounds also like we won't be getting Catalyst in the July release, either

Luckily I have the free drivers. Some would certainly like to use OpenGL software on Fedora 11, too.

Our supported distributions are primarily driven by direct requirements, ie: distributions that are used by the first level companies that buy our chips. This settles down to the 4 distros mentioned before.

It is not on Ubuntu's terms. If Red Hat (RHEL) or SuSE (SLE) move to a new kernel earlier, then we move earlier. It just happens that there are typically Ubuntu releases earlier than SuSE or Red Hat. Note that Red Hat suggest us to not focus on Fedora as an incubator for RHEL, Novell suggested openSUSE as the incubator for SLE.

As mentioned before, new X versions and new kernel versions will be targetted for the next supported distribution that picks them up. The kernel has the source based KCL which should empower any reasonably kernel-literate developer to patch. PM me if there are any functions that are not fully understood and we can update the doxygen comments. Remember that the engineers in my team are graphics driver domain experts, not the-rest-of-the-kernel experts. It costs us just as much to investigate and understand the kernel changes and how they affect the driver.

Regards,

Matthew

[Markore]

Just my 2 cents.

What should do those people that have fglrx support removed
and therefore, can`t use newer Linux distributions with fglrx
and also free driver doesn`t support them.

Shouldn`t cards that are diched from fglrx support, be prepared for support in free drivers?
I am just narrowing attention to those customers "in between".

Not saying that peak of development shouldn`t be for newest cards.
If new-released card is supported right away on release, we would have
better user experience all the way.

Sorry for my conclusion about turning users to beta testers,
I realize now that AMD made enormous shift toward and made a big effort to supporting its Linux users.

Anyway, GNU/Linux is a community - and during whole lifetime
of a product i was fully available as an user for testing and testing and testing more, just to give my contribution to AMD efforts
so I suggest to AMD to harnest that power of users, Digg to any
user report came from site, etc and use those who want to do testing.

I just posted my message out of honestly disbelieve that somewhat older
graphics should be ditched from support this fast because AMD
should be carefull with integrated graphics users.
We are not power users of AMD graphics (yet we can aspire to insert some more powerfull graphics later) but we choosed AMD _platform_ as a whole.

[bridgman]

What should do those people that have fglrx support removed and therefore, can`t use newer Linux distributions with fglrx and also free driver doesn`t support them.

With the specific exception of 3D apps requiring high levels of GL support, I believe all of the GPUs and usage scenarios were already supported as well as or better than fglrx before the parts were dropped from fglrx. For 3D-intensive users we recommended that they stay with their existing distro release until the open source driver framework catches up with their needs.

If you see any other cases where products or usage scenarios are not supported by the open drivers, please let us know. Analog tv outputs are still causing trouble, but AFAIK everything else is supported.

Shouldn`t cards that are diched from fglrx support, be prepared for support in free drivers? I am just narrowing attention to those customers "in between".

Yes, I believe that is already the case. If you're not seeing that please let us know.

Not saying that peak of development shouldn`t be for newest cards. If new-released card is supported right away on release, we would have better user experience all the way.

The focus for fglrx is more on new parts (which makes sense, it's our launch vehicle for new products) but the focus for the open source drivers has primarily been on older parts. We're doing a push right now to get basic 6xx/7xx 3D running since the key community developers are focusing on adding features for older GPUs so there's nobody else to work on it, but in general the open source driver effort has gone at least as much into older parts as into newer ones.

Sorry for my conclusion about turning users to beta testers, I realize now that AMD made enormous shift toward and made a big effort to supporting its Linux users.

Thanks

Anyway, GNU/Linux is a community - and during whole lifetime of a product i was fully available as an user for testing and testing and testing more, just to give my contribution to AMD efforts so I suggest to AMD to harnest that power of users, Digg to any user report came from site, etc and use those who want to do testing.

Typical user reports are actually very difficult to use effectively other than as a way of pointing out areas where we may want to do more testing or documentation. In cases where we find users posting highly useable reports -- providing enough information to let an in-house developer quickly reproduce the problem -- we do try to invite those users into the beta test program so we can feed their findings directly back into the development process. There are practical limits to the number of people we can work with that way, so we certainly don't ask every good reporter we see.

The problem is that a lot of user reports are more along the lines of "I installed distro X, then I replaced components Y and Z, then I installed 13 different drivers and edited a bunch of files, then I installed fglrx and it didn't work, you guys suck". I'm obviously exaggerating a bit here, but you get the idea. The chances of us duplicating that user's system configuration is pretty much zero, and in cases where we know the same driver and hardware work on a stock system it's hard to do anything but suggest a fresh install (which is usually not well received).

When we ask for problems to be reproduced on a vanilla install of a distro we support it's not because we only care about those users, it's that reproducing the problem on a system we can duplicate in house is the only way our developers have a chance of doing anything about the problem.

I just posted my message out of honestly disbelieve that somewhat older graphics should be ditched from support this fast because AMD should be carefull with integrated graphics users. We are not power users of AMD graphics (yet we can aspire to insert some more powerfull graphics later) but we choosed AMD _platform_ as a whole.

For the record, I probably should mention that the open drivers already do a good job of supporting the typical usage scenarios of integrated graphics users. The cases where we have unhappy IGP users right now are generally where they are trying to do more than a typical IGP user, including gaming or other 3D-intensive apps. In those cases the open drivers aren't completely up to the task yet, but for the more common IGP usage scenarios I really do believe the open drivers are at least as good as fglrx was at the time we dropped support for the 3xx-5xx cores.

Anyways, I do appreciate your feedback. We can't always make everybody happy immediately (I don't think any vendor is doing that yet) but we can at least influence future priorities.

Thanks,
John

[PuckPoltergeist]

The kernel compatability layer (KCL) is in source form, and users are able to look at the kernel functions and update as needed. If there are comments that are missing that do not communicate the intent of a function sufficiently for a developer to adapt to a new kernel, then please PM a question for a KCL function to me.

Very rarely does a new kernel trigger an architectural change in the binary part of the driver, so realistically the community is at the same level of opportunity as the developers that report to me in updating to a new kernel.

You have the kernel source, you have the KCL source. If the KCL function isn't clear, tell me and I will get the doxygen comments updated.

The KCL is not the problem. This can be an is handled by the community. But when problems occour with the binary blob like with 2.6.28 and above

[fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_close] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0x7fd783efe000,handle:0xf0940000

then it should be handled faster by ATI/AMD.

[Nille]

Hi. most time people posting only about there problems. I just want to say im an happy AMD/ATI customer ( since over 10 years ) without problems with the fglrx and thanks John and Matthew for an nice work and obviously all people working on the ATI Drivers ( Open and Closed Source ).

PS. I hope we get maybe an present for Christmas called XvBA

[monraaf]

PS. I hope we get maybe an present for Christmas called XvBA

LOL, you still believe in Santa Claus, do you?

[Nille]

LOL, you still believe in Santa Claus, do you?

Im confident that we get it early or later.

[cutterjohn]

I'm sure that they must beta test these alpha quality drivers, but AMD does have a point in variances between linux distros w/various kernel and X.org versions running along with all of the distro specific patches applied.

OTOH there seem to be an ungodly number of bugs in the X.org catalyst drivers, some of which require system reboot which should NEVER happen, e.g. video playback after awake from sleep ALWAYS locks up at least X.org if not the entire system. (I am w/o a 2nd machine -to attempt to ssh in and verify this ATM.) Then there are the random screen corruption problems which are at least workaroundable by forcing a screen refresh.

I just keep hoping month after fruitless month that something awful will happen at AMD and they'll actually release a quality driver by mistake.

[EDIT]
It's kind of funny, in this case I'm actually holding out hope for the OSS drivers to be of higher quality than the vendor provided propietary one... (OSS drivers IME have serious problems for years and years, and I'd hazard that GPU drivers are some of the most difficult to write... or at least for GPUs that have any sort of decent functional capabilities...)
[/EDIT]

[Kano]

@mtippett

If patching fglrx drivers is so easy, why don't provide OFFICIAL patches? That is common for Nvidia drivers too, i have got a full collection of em...