AMD/ATI lost another Linux customer

[m4rgin4l]

no, patching is the distris job. If your distri can't do it, look for one that does.

gentoo is even more 'moving' than fedora - and there fglrx is not really a problem. The ebuilds include all patches needed. Sure, sometimes you have to get it from bugzilla - or do it yourself in the first days after a release - but it is easily done.

Why patching to support the latest kernel (and the rest of the sw stack) is the distro's job? I'm willing to accept that for the OSS drivers, but not for the proprietary drivers.

[doubledr]

Why patching to support the latest kernel (and the rest of the sw stack) is the distro's job? I'm willing to accept that for the OSS drivers, but not for the proprietary drivers.

I think iit is because each distro has its own policy for installing files.

[m4rgin4l]

I think iit is because each distro has its own policy for installing files.

That might be the case for the distro managed packages, but I was referring to the manufacturer provided package.

Also, Fedora does not include proprietary packages on its repos, so they wouldn't do it anyway

[energyman]

again, use a distri that puts the user first - like gentoo :P

[Hasenpfote]

Hey m4rgin4l, I'm one of the guys like you! But in my case, I bought a 3870 which doesnt allow me to play Team Fortress 2 in Linux (crashes when loading a map, right now flickering because ATi HDMI is used). I never entered a map. But I bought the 3870 because of AMDs step to release documentation. I could have bought a Geforce 8800GT at that time, but I wanted to support AMD.

In the first step, I justed wanted to tell you:
Are you taking part in OOS driver development? No? Then STFU!
But on the other hand: With buying an AMD card, you already supported them! So, your task is done! Now its their task to give you drivers for your platform.

But the main reason why I'm being so hard to AMD is, because you're right saying "They dont care about costumers!" Need a prove?
The so called "Themen-Woche" (Topic-Week) on planet3dnow: http://www.planet3dnow.de/vbulletin/...play.php?f=197
It was advertised with users can ask AMD, AMD answers! AMD did NOTHING!!!! Let me repeat: NOTHING!!! They totally blamed one of the biggest sites in Germany! Wanna see how to do it properly? Look at the Intel-Evening: http://www.planet3dnow.de/vbulletin/...play.php?f=198 They nearly answered everything! Last time, when they couldn't answer, they asked a spezialist at the company and gave the answer later.

AS a stock owner (yeah, I made that mistake, too), I wrote to AMD. The answer?

I will forward your email to the Director of our
product PR division. We will look into the matter and work to find a
solution to ensure all inquiries are addressed appropriately in the
future.

Well, thank you! How about apologizing to planet3dnow and making a REAL topic-week?

Overall: You're right! AMD doesn't take care about costumers, after they bought a card. Well.. yeah.. Wait! They supported a funny overclocking event (http://www.planet3dnow.de/vbulletin/blog.php?cp=8). Thanks AMD! Good Job and cheap advertisement for your superduperuberoverclockable CPUs, that can't compare at stock speed with Intels High-End-CPUs.

Sorry for being offtopic... But I needed to say this!

[L33F3R]

I could have bought a Geforce 8800GT at that time, but I wanted to support AMD.

I find it funny how people can be so generous to a company that doesnt properly support your platform and yet not donate a dime to the various projects that make up that platform.

[bakou]

What the hell?

As a user of a Lenovo T500 with switchable graphics between the Intel 4500X chipset and an ATi 3650, I feel the need to add to this discussion. I can't believe we have an AMD employee here going on about "BLEEDING EDGE" software support. That is completely ridiculous. Let me say I am no open source crusader, I use the NVIDIA closed sourced drivers on other machines, and I wold also use fglrx IF IT WORKED. I respect that you have released documents on open source, but if you really wanted to effect changes quickly in the Linux community you would just release the source for fglrx for Linux, since it is obvious you need the open source community's help developing that buggy piece of shit, rather than forcing them to reverse engineer everything from scratch just to protect some kind of trade secrets, which are no longer really secrets anyway.

Since my machine uses many new components I am required to use these so-called bleeding edge kernels. The oldest kernel I can use to give me wireless support is 2.6.27, 2.6.28 supposedly works with it however it is buggy and I experienced some crashes. Additionally, the oldest kernel I can use to get proper support for my Intel chipset GPU with the new Intel drivers is a heavily patched version of 2.6.29, or preferably 2.6.30 (both of these also work great with the wireless, thank you!). Intel or NVIDIA do not send their employees to troll forums complaining about bleeding edge software, rather they actually work on supporting the current state of Linux software, and they do a fine job of it. Also the NVIDIA closed source drivers add support for these 'bleeding edge' kernels usually before they are even officially out.

Since, as you can see I use a laptop from a company you have obviously made a deal with to officially support, I find it rather insulting that your company has sent you here to make excuses, since you are not supporting it whatsoever in Linux. The fglrx driver serves almost no purpose that I can see, it is too buggy to use for any practical reason 3D drivers are used, even if I was willing to downgrade my kernel and forget about supporting the rest of my perfectly good hardware from companies which make working drivers available in a timely manner. It would be completely impractical for me to downgrade my entire system and compromise all my other hardware anyway, just to use drivers with buggy 3D rendering, buggy compositing and buggy video playback (oh right, all 3 reasons to even use a 3D card in the first place!)

I am sorry for the insulting and ranting tone of this post, but given you appear to be posting on behalf of AMD/ATi you are bringing out the worst of my feelings on this issue, and your stance is illogical and inexcusable.

[bridgman]

I am sorry for the insulting and ranting tone of this post, but given you appear to be posting on behalf of AMD/ATi you are bringing out the worst of my feelings on this issue, and your stance is illogical and inexcusable.

No worries. We're here to listen as well.

As a user of a Lenovo T500 with switchable graphics between the Intel 4500X chipset and an ATi 3650, I feel the need to add to this discussion. I can't believe we have an AMD employee here going on about "BLEEDING EDGE" software support. That is completely ridiculous.

With respect, you are using "bleeding edge" differently from the way I do, and then getting mad about something I did not say. The recent Fedora releases have included code which is 3-6 months *ahead* of the upstream kernels -- that's what I'm calling bleeding edge, not the regular released kernels you need for new hardware support.

For distros with recent kernels from upstream I have been using the term "faster moving" (relative to the enterprise distros which make up most of our customer base) - if you don't think that is fair please let me know what you would consider appropriate.

Let me say I am no open source crusader, I use the NVIDIA closed sourced drivers on other machines, and I wold also use fglrx IF IT WORKED. I respect that you have released documents on open source, but if you really wanted to effect changes quickly in the Linux community you would just release the source for fglrx for Linux, since it is obvious you need the open source community's help developing that buggy piece of shit, rather than forcing them to reverse engineer everything from scratch just to protect some kind of trade secrets, which are no longer really secrets anyway.

Please remember that AMD employees are the ones adding new hardware support to the open source drivers, with full access to the hardware design teams. Not sure where "reverse engineering" comes into it but maybe I'm missing your point.

Since my machine uses many new components I am required to use these so-called bleeding edge kernels.

Again, you are the one using "bleeding edge" to refer to regular upstream kernels. I use it to refer to distros containing code which is *ahead* of the upstream.

The oldest kernel I can use to give me wireless support is 2.6.27, 2.6.28 supposedly works with it however it is buggy and I experienced some crashes. Additionally, the oldest kernel I can use to get proper support for my Intel chipset GPU with the new Intel drivers is a heavily patched version of 2.6.29, or preferably 2.6.30 (both of these also work great with the wireless, thank you!).

We need to shorten the gap between new kernel release and support in fglrx in order to deal with the new hardware enablement issues you mention. Matthew and I have both said this multiple times, however we have also said that this will be a gradual effort, not something that happens overnight.

You don't have to wait for us, however -- the fglrx driver is written to an OS-neutral API, and the install package includes source code for a Kernel Compatibility Layer. This allows distro packagers or any interested third party to adapt the code to newer / different kernels without requiring modifications to the driver itself.

Intel or NVIDIA do not send their employees to troll forums complaining about bleeding edge software, rather they actually work on supporting the current state of Linux software, and they do a fine job of it.

Neither do we. You are getting mad about things which we have not said or done. I might do it in the future though, so there's no harm in having a good rant just in case

The point I am trying to make (without success, apparently ) is that we are continuing to improve the open source and the proprietary drivers in parallel, however right now if you want to use the newest kernel versions then the open source drivers are your best bet.

Also the NVIDIA closed source drivers add support for these 'bleeding edge' kernels usually before they are even officially out.

Our open source drivers also track the latest kernels and X servers, and they are used by developers *making* changes to the underlying code. The proprietary drivers do not, although I expect they will close the gap over time.

Since, as you can see I use a laptop from a company you have obviously made a deal with to officially support, I find it rather insulting that your company has sent you here to make excuses, since you are not supporting it whatsoever in Linux. The fglrx driver serves almost no purpose that I can see, it is too buggy to use for any practical reason 3D drivers are used, even if I was willing to downgrade my kernel and forget about supporting the rest of my perfectly good hardware from companies which make working drivers available in a timely manner. It would be completely impractical for me to downgrade my entire system and compromise all my other hardware anyway, just to use drivers with buggy 3D rendering, buggy compositing and buggy video playback (oh right, all 3 reasons to even use a 3D card in the first place!)

What happens when you run the open source drivers with your kernel of choice ? I realize you won't have 3D HW acceleration yet, although we're getting pretty close, but display, 2D acceleration and video playback should be solid today. If they are not please let us know.

[bakou]

Well you may be using bleeding edge to describe that, but the fact of the matter is fglrx (as far as I'm aware) doesn't support any kernels newer than .28, Which I believe was released around 8 months ago. I am a Gentoo user, I could downgrade but as I explained in my post it just would not make any sense in my situation, as my Intel card works great (I would LIKE to use the more powerful 3D capabilities of my ATi GPU!).

I have no desire to test the open source drivers until they have reliable 3D support for the same reason as above. My idea of good video playback is using mplayer OpenGL with direct rendering and shader based scaling (that is the only technology I am aware of on Linux that can compete with WinXP/Vista VMR, for example).

I didn't know it is the AMD engineers who are adding hardware support to the open source drivers, or working on them at all. In that case, wouldn't it be more a matter of cutting and pasting code from the fglrx driver then re engineering it to be more compatible with X protocols?

I have heard that the R600 drivers are just now starting to render triangles which is very good, but I don't think they are available for much public testing short of checking out drivers on git yourself (which can lead to some very messy situations...).

Why then do you continue to allocate resources to fglrx if you could just allocate them all to the open source effort which is what most people on Linux want anyway, and will probably result in a much better driver in the long run? I see that progress is being made, I just don't understand the logic behind the management of resources, especially in light of your response. Of course with collaboration between the OS community supporting new software and kernels will never be an issue, that is the whole point! That is why it will be better! Why pay your employees to constantly track kernel changes like nVidia when people are willing to do it for you? It makes a lot of sense to go totally open on Linux when there are an army of programmers willing to help. That is exactly why I am so frustrated with this situation where I am in limbo with two drivers where neither one is really useful, I'm sure they are both useful to people who have 2 year old PCs, but this is not how the world works.

Anyway Thank you for your response, I feel somewhat better about the situation now, my main concern is then why aren't more engineers and programmers from AMD working on the R600 open source effort rather than beating the dead horse that is fglrx on Linux (I know it works fine on Windows, that is probably why I'm logged in on Windows now lol)

No worries. We're here to listen as well



With respect, you are using "bleeding edge" differently from the way I do, and getting mad about things I did not say. The recent Fedora releases have had code that is 3-6 months *ahead* of the upstream kernels -- that's what I'm calling bleeding edge, not the regular released kernels you need for new hardware support.

For distros with recent kernels from upstream I have been using the term "faster moving" (relative to the enterprise distros which make up most of our customer base) - if you don't think that is fair please let me know what you would consider appropriate.



Please remember that AMD employees are the ones adding new hardware support to the open source drivers. Not sure where "reverse engineering" comes into it but maybe I'm missing your point.






We need to shorten the gap between new kernel / X server release and support in fglrx. Matthew and I have both said this multiple times. We have also said that this will be an incremental effort.



Neither do we. You are ssying things which we did not.



Our open source drivers also track the latest kernels and X servers, and they are used by developers *making* changes to the underlying code. The proprietary drivers do not, although I expect they will close the gap over time.



What happens when you run the open source drivers with your kernel of choice ? I realize you won't have 3D HW acceleration yet, although we're getting pretty close, but display, 2D acceleration and video playback should be solid today. If they are not please let us know.

[bridgman]

I have no desire to test the open source drivers until they have reliable 3D support for the same reason as above. My idea of good video playback is using mplayer OpenGL with direct rendering and shader based scaling (that is the only technology I am aware of on Linux that can compete with WinXP/Vista VMR, for example).

You might be surprised how well Xv works for you on the open source drivers. Same shader based scaling, plus lower CPU utilization and some additional filtering & colour space options. Not saying you should rip out your current setup on my say-so, but it might be worth checking what other users are saying.

I didn't know it is the AMD engineers who are adding hardware support to the open source drivers, or working on them at all. In that case, wouldn't it be more a matter of cutting and pasting code from the fglrx driver then re engineering it to be more compatible with X protocols?

Just to keep us on the same page for names, fglrx is the "engineering" name for the Linux Catalyst driver, which in turn is basically an X/DRI driver that uses common code shared across multiple OSes.

The hardware layers of the Catalyst drivers (including fglrx) are perhaps 20x the size of the corresponding open source code, at least on the 3D side, and use a different underlying architecture. The extra size is what it takes for the last bit of performance and functionality. We were originally hoping to be able to leverage the hardware layers from the proprietary drivers but it turned out not to be practical because of the size and the architectural differences.

On the display/modesetting side, the open source drivers use AtomBIOS, which lets us run the same code used by the proprietary drivers. For functinality not covered by AtomBIOS we generally obtain pseudocode from the Catalyst driver teams and use that as an implementation guide.

The first round of new hardware support was done entirely by community developers while we were building an internal team, but the model that we are using today is that AMD developers focus on adding new hardware support which leaves community developers free to add features and functionality to the existing drivers. The lines are pretty fuzzy though -- community developers are already helping to troubleshoot and fix bugs in the 6xx/7xx 3D driver, and agd5f has been helping with the KMS/GEM/TTM implementation effort.

I have heard that the R600 drivers are just now starting to render triangles which is very good, but I don't think they are available for much public testing short of checking out drivers on git yourself (which can lead to some very messy situations...).

First triangle was 9 months ago. Now we have most of the major functions working and are trying to hunt down a nagging problem with vertex buffers so that we can expand the testing. The back-to-front copy used in GLSwapBuffers is not yet HW accelerated but agd5f is working on that now. We are approaching the point where distro packagers should think about picking up the code but we're not there yet.

Why then do you continue to allocate resources to fglrx if you could just allocate them all to the open source effort which is what most people on Linux want anyway, and will probably result in a much better driver in the long run? I see that progress is being made, I just don't understand the logic being the management of resources, especially in light of your response. Of course with collaboration between the OS community supporting new software and kernels will never be an issue, that is the whole point! That is exactly why I am so frustrated with this situation where I am in limbo with two drivers where neither one is really useful, I'm sure they are both useful to people who have 2 year old PCs, but this is not how the world works.

Simple. The fglrx driver is what we need for the professional workstation market. Over the last 18 months or so we have also started using it to deliver high end features to consumer users. I expect that most consumer users will be perfectly happy with the open source drivers, however.

We could have done all the development in secret and only announced when we were finished, but I think that would have taken longer and annoyed the community in the process. We wanted to hire developers who were familiar with the open source stack, and it seemed to make the most sense to have them keep working closely with the rest of the community. That meant you had to watch and suffer while we development took place rather than just being given the end product, but I still think this is the right way to proceed.

Anyway Thank you for your response, I feel somewhat better about the situation now, my main concern is then why aren't more engineers and programmers from AMD working on the R600 open source effort rather than beating the dead horse that is fglrx on Linux (I know it works fine on Windows, that is probably why I'm logged in on Windows now lol)

The critical path items for the open source drivers have been (a) writing and releasing the programming docs, and (b) coming up to speed on the latest driver stack. I don't think adding more developers would have really made that much difference.

Our largest Linux market is still the professional workstation market, which is almost entirely based on enterprise distros and relatively stable hardware platforms. That's where fglrx comes from, and where it continues to be essential. As long as we are making a proprietary driver, we are also trying to use it as a vehicle to deliver neat new features to consumer users, such as MultiView and Crossfire.

I'm logged in on Windows too, but for different reasons -- after 2 years and a big box of scrapped hardware I still haven't found a Linux analog modem driver or standalone modem that can handle my crappy rural phone line ;(