“Last week we had published The Truth About ATI/AMD & Linux, and to no real surprise, the feedback ranged from beliefs that it was propaganda to others being grateful that AMD finally shared some additional information with their Linux customers about the fglrx development cycle. While the article was far from being propaganda, what had outraged a number of open-source developers were AMD’s comments on the R200 support or there the lack of. In this article, we have a few additional comments to share along with what some open-source developers had to say about AMD’s information.”
Just throwing out a few questions on things that surprised me from the article:
1. Lastest Intel GMA chipsets do not have specs released? I thought they did.
2. 2D nv driver is *provided* by NVidia? I thought that the nv driver was a reverse enginieering effort. (Not to be confused with the 2D/3D Nouveau effort.)
3. Original R200 specs from ATI were provided to only a few people, under NDA, and were quite incomplete. I didn’t know that, but it really shouldn’t… and doesn’t… surprise me.
nv is provided by nVidia to Xorg, and only they can maintain it. Nouveau is not using any nv code (in fact they based off a BeOS/Haiku reverse eng’d nvidia 3d driver) because nv code was obfuscated in 1999, maybe done to prevent 3d use.
I saw a mailing list link a few days ago where Keith Packard said he was trying to get Intel to release the new specifications for new GMA chipsets…
Nouveau is not using any nv code
That’s not true. DDX part (xf86-video-nouveau) is based on nv driver. If you don’t believe me, you can look at any source file and read copyright info (for instance http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=b… ). Nouveau developers were deobfuscating nv source code (it’s still in the TODO list -> http://nouveau.freedesktop.org/wiki/ToDo ). More information here -> http://airlied.livejournal.com/34017.html
You’re right, thanks for correcting. It’s funny how they had to use a BeOS driver to start with though isn’t it
They won’t even let a 600 line 2d r500 ATI driver be released. That means you can’t start up X on any Linux distro AFAIK.
http://airlied.livejournal.com/43975.html
http://airlied.livejournal.com/43520.html
http://airlied.livejournal.com/31180.html
“I wrote a driver for my X1300 card for 2D using that info and a VBE modesetting tool that trapped all the IO accesses. The code mod to the radeon driver is about 600 lines of actual code. I submitted this to ATI for release due to the NDAs I have with them. It is now > 4 months since I did this and I’ve heard nothing back from ATI apart from the initial interface.”
That quote is from last year…
That is all so uber-weird. Apart from being forced to use fglrx on Linux system even for simple 2D, one practical consequence is that unaccelerated ATI hardware is painfully slow on for instance Opensolaris. Thanks for nothing ATI.
I bet there is a big fat palantir tuned in on Microsoft somewhere up the ATI Orthanc.
I wonder what we can do about this. Sure, my next graphics card won’t be an ATI, but I doubt that will have any (visible) impact. And I also doubt that the nVidia card I’m going to buy will be better supported with open source drivers than the (admittedly stinking cheap) ATI one I’m using now. I think I’ll choose an Intel one for my next laptop, but again Intel isn’t exactly a friend to free/open source software.
It would be nice if there were one authoritative “Linux hardware” site were people could check hardware compatibility and, more important, be guided through their choices. If there a very visible “At the present moment company XXX is the most friendly towards FLOSS, buy from them” sign things might change: some tens of thousand disgruntled customers leaving would surely be noticed by these guys.
Rehdon
I agree. I keep hearing from people around me and on the net how friendly Intel are now that some GMA drivers are around.
I would like to see a site containing serious moderated history of topics concerning companies actions. This would not only clear up the confusion, and help people on buying hardware from the right companies, but also motivate companies to behave better or keep doing it.
Currently we have many pages containing information about specific hardware. I wish for some focus on vendors too.
Maybe we just have to wait for or work towards a similar ideology in the hardware field.
Something like “Open Specification” hardware.
Then you could have a truly “free” computing experience. A computer built using F/OSH running F/OSS.
Wake me up when they release *BSD drivers. Cookie goes to nVidia again…
“””
Cookie goes to nVidia again…
“””
I wouldn’t be too quick to present any awards to either of them. Just because NVidia treats their OSS customers less badly in some ways…
ya know its kind of funny. remember 3 or 4 years ago when intel was teh “bad guy” and AMD was suposidly this knight in shining armor. its funny to think that Intel has now been much more coperative with the open source community. Personaly i love it. and i like the intel GMA3000, i hope the linux drivers work well then they come out.
Intel has always been pretty friendly to the open source community. AMD wasn’t too bad either, although not quite at the same level. It’s just the recently acquired ATI part of their company that isn’t.
Edited 2007-06-08 21:55
Original R200 specs from ATI were provided to only a few people, under NDA, and were quite incomplete. I didn’t know that, but it really shouldn’t… and doesn’t… surprise me.
Same feeling here.
I think companies like ATI and nVidia will always keep the drivers for the high end cards closed. Not because they are “bad” people or because the code is poorly written or they just love their drivers; but because releasing source code gives away all the hardware details which is suicide in the market.
Those who use Linux for graphically demanding applications will have to make do with binary blobs.
> releasing source code gives away all the hardware details
I don’t believe that for a second. I might believe that the source code might hint at a few design details, but nothing substantial, and certainly not everything or even much.
There is a lot to hide in modern high end GPUs in a competitive market. GPUs have a lot of additions on top of the usual CPU, registers, bus architecture – which can be extracted from the drivers. Simple things like what the register sizes are, how floating point numbers are dealt with – stored, operated on etc can be easily read from (commented) source files while general system behavior can be “guessed” quite accurately.
Take a look at the source code for the nv driver, originally written by nVidia to clear the doubts. Even when these companies do release open drivers, they play dirty tricks like removing comments, making the code harder to understand etc.
nv_hw.c has 3 lines of comments for ~1600 lines of code (w/o counting the license, copyright etc).
Its not a question of belief. These are verifiable facts.
edit : I do share the general frustration about the unwillingness of companies to open drivers, but I also understand that not everyone believes in free software, or not everyone can afford to do so all the time.
Edited 2007-06-09 01:04
I cannot believe that GPUs have more to hide than conventional CPUs. If CPU manufacturers can release specifications (e.g. op-codes) without harming their business then surely so can GPU manufacturers*. It is high time people stopped putting up with this.
* We don’t want source code, we want specifications on how to interface to the device.
* We don’t want source code, we want specifications on how to interface to the device.
We, on the other hand, want the companies to release drivers, even binary, of the same quality, with the same level of attention for our free platforms as they do with windows so our hardware work as well on Linux or BSD as they do on windows.
http://en.wikipedia.org/wiki/Binary_blobs#Reasons_against_using_bin…
If you want binary blobs you will forever be beholden to the manufacturer. You become helpless. Driver no longer compatible with newer kernel API? Doesn’t support awesome new effects feature X? Has a bug? Has a security hole? Hardware is no longer supported by the manufacturer? Are these things going to be fixed? That is up to the manufacturer. If they decide it’s not worth their while you are out of luck. These are not theoretical concerns. Every one of those examples occurs today.
Users say they ‘just want it to work’. Well making things ‘just work’ is not magic. If a driver breaks in the ways above it is not ‘just working’. You should think about how developers can deliver high quality drivers to you. It’s absurd to say that this can be better achieved if only the manufacturer can write them. (Or at least if other developers are purposefully crippled in doing so.)
If you want binary blobs you will forever be beholden to the manufacturer.
True. Thats why I insist that the manufacturers
either –
provide high quality, well tested, well maintained, well supported, needfully updated binary drivers
or –
release open source drivers.
You become helpless.
I feel a bit helpless even while using F/OSS at times :-). When simple but annoying bugs don’t fixed quickly, when fixing the bug myself is beyond my technical prowess, when things don’t work and I cant find answers online, to name a few instances.
To stick to the topic, I use the omega drivers for ATI on windows. Though they are binary drivers, not once have I felt helpless because there haven’t been any instances to cause me frustration. Maybe I’m lucky but if Linux binary drivers were of the same class, I would not feel helpless.
That is why my opinion is that either give us “good” drivers or open drivers.
It’s absurd to say that this can be better achieved if only the manufacturer can write them.
It is indeed absurd to say that. I think its proper to say that getting manufacturer written driver is one way to get good drivers and releasing their source is another way. Both ways can deliver bad drivers too mind you.
I guess the question boils down to –
Do you want “Free” drivers regardless of quality or do you want good drivers regardless of license philosophy.
To demand open, free drivers for all hardware from all companies is in my opinion a bit arrogantly dogmatic.
Funny, I’ve had the opposite experience. As soon as a piece of hardware becomes ‘legacy’ the company stops supporting it. Going from Windows 98->2000 I had graphics cards, and scanners that became useless. The same problem will happen going 32bit->64bit. I call that helpless. Company goes out of business, you’re helpless (it has happened to me, not a small company either). Having to wait years for the manufacturer to decide it’s worth it’s while to implement a feature (e.g. stream processing), I call that helpless. It’s not just a question of working drivers but a question of what you are enabled, or rather, not disabled, from doing.
The point, however, is irrelevant, since there is nothing preventing having specifications (and thus free drivers) and binary blobs. They can coexist. You certainly wouldn’t be worse off having the choice.
How about free, good drivers? What reason do you have to believe that, given specifications, free software drivers will be inferior to manufacturer supplied binary blobs? In fact, why not have both? Let them compete, we will see how they fare.
Your mistake is that you implicitly assume that ‘good’ drivers are the binary only drivers supplied by manufacturers. That is not the case — some examples I outlined in my previous post. ‘Works right now, for me’ is a pretty poor metric for ‘good’.
[q]
To demand open, free drivers for all hardware from all companies is in my opinion a bit arrogantly dogmatic.
[q]
That is not what sane developers are asking for. What they demand are specifications. *They will write drivers for the company*. To demand that manufacturers provide documentation on how to operate their devices is neither arrogant nor dogmatic.
Graphics hardware was born and raised just like any other bus device, but industry forces are putting graphics on a collision course with the CPU. The graphics vendors will need to confront the reality that graphics is becoming a special case of stream processing and a sibling of the logic and vector units in today’s processor pipelines.
Today, graphics hardware is programmed using graphics APIs like OpenGL and lesser-known APIs for HPC applications. These interfaces call down into proprietary drivers to dispatch work to the GPU. In the future, graphics hardware will be targeted by compilers and virtual machines, much like CPUs.
Graphics vendors will have to decide whether to open their ISAs to allow free software compiler and virtual machine packages to target their hardware or to restrict their hardware to proprietary code generation tools. Choosing the closed route will be suicide in a market tightly bound to developer mindshare.
Intel’s Larrabee project is a clear indication that graphics hardware is on an evolutionary course toward the same programming model we’ve been using for decades on CPUs. The central idea is to make graphics an extension of the x86 ISA. This will make compiler support simpler and more effective, especially for free software suites like GCC, and it will open the doors for the development of more powerful interfaces for graphics, multimedia, and scientific programming.
This is one of those issues where market forces will eventually demand an open approach. In the short-term, Intel will lead, AMD will waffle, and NVIDIA will stay the course. Those that believe that their drivers are a competitive advantage will ultimately realize that capability is the fundamental consideration.
It doesn’t matter how many FPS you push in a particular game if you can’t support the latest desktop effects or the new codec acceleration library. Open graphics will make way for growth outside of the high-end gaming market, whereas closed graphics vendors are relegated to one-trick ponies.
NVIDIA has already put decided to put all of their eggs in one basket, claiming that it would be foolish to go after Intel in the mainstream graphics market. Maybe they’re right, and AMD is charting a course for failure. NVIDIA has chosen to target a mature market with well-known requirements. They’d rather dominate a stable market than compete vigorously in a growing market.
Both Intel and NVIDIA have sensible strategies with clear intentions. AMD is pandering to the free software community for no clear reason as they fail to compete favorably with NVIDIA on the high-end. They have an identity crisis to go along with their execution missteps. It’s easy to argue that AMD is headed for tough times, but I’ll reserve judgment since they are currently at the very bottom of their cyclical competitive position.
“[…] but because releasing source code gives away all the hardware details which is suicide in the market.”
If this is truly and veritably the case with these drivers, then the drivers and hardware are flawed by design. The source code need only detail the *interface* to the card, not necessarily the _internals_ of it.
The commands that my OS of choice gives to the hardware, and how that hardware actually runs those commands are two totally separate things. (For example, my Linux kernel build is continually using x86_64 instructions to manipulate my Core2’s hardware….but the Core2 chip itself actually compiles those instructions in microcode to a RISC-like set of operations which it then runs on the hardware.)
Exactly what I was thinking. Just like OpenGL is an API, it tells the video card what to do, and from there the video card processes it. Isn’t that what the P word is for in GPU?
And damned if the video card manufacturers would have to actually compete on merits of better internal architecture on their cards rather than “my drivers are more stable than yours.”
The world of software would simply be better if they could release the specifications. Imagine an open source driver for windows as well (personally I think ATI and nVidia’s drivers kind of suck under it as well, damn Matrox for leaving the video card industry.)
> but the Core2 chip itself actually compiles those instructions in microcode to a RISC-like set of operations which it then runs on the hardware.
Which is a ‘dirty’ trick to maintain backwards compatibility, just it’s quite fast as it’s in hw.
Still, the same may happen with new DX10 compliant cards. The API between DX and drivers is precise and compelling. ‘Public’, somehow.
And it’s not unreasonable that vendors might decide to implement it in hw, plus something else eventually.
Eventually the specs will open, driven by the emerging middleware for GPGPU market. Still this will happen, IMHO, after the yet-to-start-for-real market will have settled a bit – or to give an end to the battles.