The Truth About ATI/AMD & Linux

[Svartalf]

1- Control Center, this function is only a squeleton of the windows Control Center. The speed at which AMD/ATI are developping-it now, it will take years before it gets the functionality of the one available in windows.

That's mostly because of the resources they've been putting to the effort in writing drivers. Keep in mind that they haven't been putting much effort into anything but really those set-top boxes and DirectX because "That's where the money is...", even though that was a bad bet, really- not the set-tops, but the DirectX.

2- AIGLX, I believe that we may get this before the end of the year.

Maybe, maybe not. Most of the work is on maintenance coding as best as I can see. They're probably working on making the Linux implementation of the "Orca" drivers perform adequately on Linux. If this is the case, it's going to take a long while yet. I'm going to expect it much later, at least middle of next if not end of next at the rate at which things are progressing. That way I won't be setting myself up for disappointment and can be pleasantly surprised when they beat those expectations.

3- Performance, The ATI driver performance in windows is twice the performance in Linux, therefore driver performance has to increase 2 folds (100%). I don't think that AMD/Ati will ever be able to do that. If it is possible, it means that the ATI linux driver is baddly designed and coded, therefore the whole driver team should be replaced.

I hesitate to demand their replacement. I know some of the guys there in the Linux and other groups within the OpenGL driver group. They're not all idiots there- it's just that they have nobody with a solid understanding of the Linux internals- Kernel developer level understanding of how things like interrupts, etc. really work. A drop of half to two thirds in performance from Windows to Linux on a piece of silicon implies an interrupt behavior caused by trying to wedge the interrupt handler design from Windows into Linux. I've given this spiel to numerous people at several companies over time. Linux achieves interactivity and overall performance through a different scheduling philosophy than Windows does. In a 3D accelerator, if you stall the pipeline for any reason, it slows things down (duh...), but in many cases it's a catastrophic slowdown that brings it to half speed or slower.

The capsule summary is as follows:

The user space piece waiting on an interrupt reply in Windows will get a priority lift, etc. and will get executed before threads within the context and may cause the process context to get swapped in if it's out.
It is based off of the MxN thread scheduler and it's pretty much due to the high context switch times Microsoft happens to have in any NT codebase variants, including Vista.

The user space piece waiting on an interrupt reply in Linux will get told that it got the interrupt, but will be held in it's same place in the priority queue for execution. In Linux, the highest priority thread of execution gets ran first- to it's time atom or to a yield of the CPU. Implicitly and always. This behavior is based off of the relative high speed of context switch (fastest non real-time context switch on the books right at the moment...) and a need to provide fair scheduling (which is a good thing with a SERVER OS- consistent runtime behavior makes for better overall server performance...). In Linux, well written code, coupled with the extremely low context switch times Linux possesses, will outperform Windows code and be as or more interactive- but only if you abide by the rules set aside by the scheduler's behavior.

What I suspect is happening is that the code is written for Windows' behavior for it's scheduler and that they've got too much driver code in userspace for the Linux side of things. They've got something waiting for the GPU idle signal back from the card and stalling the pipe because it's already idle, but the thread of execution handling the command dispatch doesn't know this until it's timeslice is ran which could be millseconds after the fact.

What I suspect, is that the ATI card were designed for directX (makes sense, as all the current ATI cardss are based on the 9700Pro which was designed by ATI with the help of Microsoft). Probably low level directx functions are hardwired directly on the gpus.

Actually, while DirectX was defined by what ATI offered to Microsoft, there's no "hardwired" anything in those chips. They're pure and simple stream processors. What you're seeing is a lack of understanding of how Linux actually works- they just don't get you can't just drop certain pieces of a Windows driver straight into Linux and get them to work right.

The present driver's monthly schedule has been going for 2 years, so it was not invented by AMD. In that 2 years if the driver team was not able to increase the driver performance, nobody will be able to convince me that in the next 6 months the linux drivers will get performance parity with the windows driver.

I would have to concur on that one. They've very, very few people actually working on Linux work compared to Windows/Windows CE work right at the moment. They need more and they need some architects that can actually design the OS interface edge the right way instead of forcing a Windows edge into that space.

For the past 6 months AMD has been in talk mode only, look at all the bad news: R600, except for the high-end model, was a paper launch. Probably, Barcelona if release in July, will be a paper launch, has we know know, that the Barcelona may not be released before October of this year.

Heh... Indeed. Like I said, they KNOW they've got some problems- I just don't think they know quite how to extricate themselves from the mess they're in right at the moment.

[yoshi314]

the dri irc logs (i gave link earlier) indicate that there is some work under the hood going in fglrx. it way to technical for me to understand, though :]

the thing that strikes me, however is that the reverse engineering team mentioned that fglrx employs certain anti-gdb hacks, to make their task more difficult.

and then i thought to myself: if ati/amd is so overprotective about their IP in linux drivers, the majority of development efforts might actually go into hindering the efforts of opensource radeon driver developers. maybe that's why fglrx sucks - or maybe that's their way of resolving issues with the opensource community, that was misunderstood as opening of the drivers ?

yeah, just a stupid thought.

[Svartalf]

the dri irc logs (i gave link earlier) indicate that there is some work under the hood going in fglrx. it way to technical for me to understand, though :]

Not for me.

the thing that strikes me, however is that the reverse engineering team mentioned that fglrx employs certain anti-gdb hacks, to make their task more difficult.

Only for someone that doesn't have a bus analyzer for PCI-E or AGP. Someone well-heeled enough could RE that thing in short-term. They're doing the anti-GDB stuff because it's cheap, easy, and they're betting on someone not being able to field 10-25k to do that sort of stuff...

and then i thought to myself: if ati/amd is so overprotective about their IP in linux drivers, the majority of development efforts might actually go into hindering the efforts of opensource radeon driver developers. maybe that's why fglrx sucks - or maybe that's their way of resolving issues with the opensource community, that was misunderstood as opening of the drivers ?

yeah, just a stupid thought.

No, it's like I said- they don't "get" Linux, pure and simple. They're trying to wedge in a Windows square peg of a driver answer into the round hole of a Linux driver problem with a 12# sledge and it's not working very well.

[sundown]

Myabe the entire ATi community on Linux around the world should make a donation for the purchase of a bus analyzer then and give it to the reverse engineers

[yoshi314]

it would be way better than tux500 fundraiser :]

[Licaon]

imho, i've already sposored the driver team when i bought the card

[chilinux]

Myabe the entire ATi community on Linux around the world should make a donation for the purchase of a bus analyzer then and give it to the reverse engineers

But if ATI continues to claim they have provided the specs, why then are we having to reverse engineer. ATI had marketed (and made money off of) the full feature set of the R200. It is dishonest to provide a driver specification document which has less features than several cheap video cards on the market and claim the specificatons where provided to the FOSS community.

The results that a bus analyzer provides over just having the actual specs is very limited. For example, using a bus analyzer to figure out how to take advantage of a iDCT (MPEG decompression) hardware accel would take a long time, a lot of skill and still not guarentee results. And changes between chipsets may require additional reverse engineer in the future as well.

In the short terms, your better off just buying a video card from a company that is more honest about providing the marketed features of the card to the Linux community. There are several *cheap* video cards that provide more features than the R200 specifications that ATI has released (keep in mine the specifications given to the FOSS is a major subset of the marketted specifications).

In the long term, donating to the Open Graphics Project will go much farther than donating a bus analyzer. The FOSS community has shown that they can produce an OS that matches or exceeds the quality and functionality of most commerical OSes. It is time the same is done with video cards as well.

Bottom line: AMD/ATI has not, is not and never will be someone the FOSS community can rely on other than continue to give PR lies like:

1) claims that ATI is committed to providing MPEG/iDCT decompression in hardware

2) ATI implies that the full R200 specs are provided/available to all FOSS developers when only a subset of the specs are provided in non-redistribution terms to a couple developers

3) ATI claims that they are "working" with FOSS developers when they haven't replied to in over three years to at least one of the developers

[Regenwald]

holy:

http://a.m.d.justgotowned.com/

[Svartalf]

But if ATI continues to claim they have provided the specs, why then are we having to reverse engineer.

The claims come from their Marketing people- why do you THINK we're still having to reverse engineer things?

The results that a bus analyzer provides over just having the actual specs is very limited. For example, using a bus analyzer to figure out how to take advantage of a iDCT (MPEG decompression) hardware accel would take a long time, a lot of skill and still not guarentee results.

Well, it would end-run around the GDB blocks... I didn't say you couldn't find someone with the skill, etc.- or that it'd be any easier than any of the other processes (because using GDB isn't going to be any easier, really...).

And changes between chipsets may require additional reverse engineer in the future as well.

This would be the case with any reverse engineering efforts anyhow.

In the short terms, your better off just buying a video card from a company that is more honest about providing the marketed features of the card to the Linux community. There are several *cheap* video cards that provide more features than the R200 specifications that ATI has released (keep in mine the specifications given to the FOSS is a major subset of the marketted specifications).

VIA's UniChrome? I didn't think that it PERFORMED as well as ATI's. It's why we're doing this painful crap- so we can have a usable GPU.

Intel's latest REAL attempt at a GPU is an actual contender. I'm giving them my business right now because of it. NVidia supports us largely in an appropriate manner, based on their goals right at the moment (Opening things up would be the truly appropriate manner, but...)- so they get my business too. AMD, on their GPU segment, will not at this point until they "get it"- whatever form this actually takes. I do not expect them to "get it" anytime in the near future.

In the long term, donating to the Open Graphics Project will go much farther than donating a bus analyzer. The FOSS community has shown that they can produce an OS that matches or exceeds the quality and functionality of most commerical OSes. It is time the same is done with video cards as well.

And that would be what I tell people- and mirrors what I think of the whole thing. The current crop of results from OGP would be in the class of a Rage 128 or maybe a R100 card. Not bad for a first pass, really- and it'll play many of the games out there right out of the gate and allow you AIGLX as well. What would things be like with the NEXT iteration?

Bottom line: AMD/ATI has not, is not and never will be someone the FOSS community can rely on other than continue to give PR lies like:

1) claims that ATI is committed to providing MPEG/iDCT decompression in hardware

2) ATI implies that the full R200 specs are provided/available to all FOSS developers when only a subset of the specs are provided in non-redistribution terms to a couple developers

3) ATI claims that they are "working" with FOSS developers when they haven't replied to in over three years to at least one of the developers

And I really, really wish someone at AMD/ATI would READ THIS and take it seriously. The train's about to leave the station and it'd be a damned shame if they got left back on the platform like so many others in the industry.

[Michael]

See: http://www.phoronix.net/forums/showt...=9098#post9098