OSNews

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

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.

"""
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...

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

> 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.

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.