Slashdot Mirror
Carmack Donates $10k to Mesa
Emil writes wrote in to tell us that that John Carmack [?]
has donated $10k to Mesa [?] to assist in the development
of optimized 3d drivers for release with Mesa 3.1. Very cool.
You can find out more about Id
or check out The Mesa Website.
Update: 05/13 04:24 by H :In somewhat related news, RealTime wrote to say "Precision Insight (the people funded partly by RedHat?) have made available their design documents for the 3D Direct Rendering Infrastructure for XFree86. The final package will be released under an XFree86 style license. "
May 1999 - John Carmack of id Software, Inc. has made a donation of
US$10,000 to the Mesa project to support its continuing development.
Mesa is a free implementation of the OpenGL 3D graphics library and id's
newest game, Quake 3 Arena, will use Mesa as the 3D renderer on Linux.
The donation will go to Keith Whitwell, who has been optimizing Mesa to
improve performance on 3d hardware. Thanks to Keith's work, many
applications using Mesa 3.1 will see a dramatic performance increase
over Mesa 3.0. The donation will allow Keith to continue working on
Mesa full time for some time to come.
For more information about Mesa see www.mesa3d.org. For more
information about id Software, Inc. see www.idsoftware.com.
Brian Paul
brian_paul@mesa3d.org
May 12, 1999
The Free Software Foundation is a 501(c)(3) organization, so donations to them are tax deductable. I don't know if they want hardware or not, but money is always appreciated. :-)
Although financial support is definitely something many spare-time-Linux-hackers only dream of, what the Linux 3D community really needs is the cooperation of hardware vendors. Only then will accellerated 3D on Linux be able to compete with the Windows platform.
Matrox has made the first, and biggest step. They have released nearly their entire specification for the G200 chip. This has generated a big development effort, seemingly overnight, to finally get an accellerated 3D solution for Linux. Although the released specification was incomplete, it was enough to get rudimentary 3D support started.
As of late, Quake2 runs accellerated on G200 hardware. And best of all, the source is with us.
Recently, other 3D hardware companies seem to be dipping their toes in the water. 3DFX and nVidia have indicated their interest in Linux, with 3DFX looking to hire Linux specialists, and nVidia pledging a binary-only solution, but I argue that these are not as desirable. The whole "Linux way" revolves around community-based open source efforts, and this requires that a chip's specification be released.
Don't get me wrong. A binary-only driver is better than nothing, but not much better.
One concern among 3D hardware vendors is that releasing the specification will allow competitors an edge. True, the 3D hardware market is competitive at best and downright cutthroat at worst. But let's get real for a minute. A 3D card's lifespan is about six months. It takes this long for an even better card to come out that blows away the previous one. I find it hard to believe that in six months, a competitor can take a register-level specification, reverse engineer it, design, test, and manufacture a better chip (remember we need a _better one_ in six months) and beat the sales of the original chip. It's just not feasable, especially since all the hardware companies already have so much invested in their own R&D.
Point is, hardware companies, please listen to reason. It is only beneficial to release your chip specifications. Upon doing so, you will 1. gain the trust and respect of the Linux community, 2. get free Linux support from the talented developers who are just foaming at the mouth to write drivers for your chip, and 3. be able to compete in the Linux 3D market which despite what Microsoft tells you is not going away any time soon.
If you don't have a linux strategy by now, you should be asking yourself why not?
Very cool, indeed. A while ago Carmack donated $10k to the FSF, too, because Quake (the original, true, DOS version) was built with djgpp. If I remember his .plan update correctly, he did that after winning the cash in Las Vegas...
:-) Seems he just wants the world to be a better place. Technically.
It's good to see him putting some of the money he earns to good use (as opposed to buying one more Ferrari
I hope it does boost his sales by over 10K. Open
Source/Free Software can be creating win-win situations.
>"Why not? How are graphics fundamentally different than, say, network cards?"
>
> Because they're a *lot* more complicated.
More complex than a NIC driver? Yeah. But more complex than, say, a distributed filesystem? No, not really. As you say:
>Video cards these ARE computers in their own right.
Yep, they're complicated, but that's because an awful lot of complexity is _in the card_. Is the _interface_ to a graphics card's functionality more complex than other kernel entities? Again, no, not really.
A lot of people have serious misunderstandings about what should or should not go into the kernel. Generally, I think things should be kept out of the kernel unless there's a good reason for putting them in, but such good reasons are not uncommon. At the same time, I think that allowing user-level access to hardware resources is a bad idea, but if it's done in a very tightly controlled way it can be great. For example, at Dolphin I worked on a shared-memory card. If it had worked properly, processes on separate nodes could share memory as easily and transparently (and almost as quickly) as processes on the same node. That would have been way cool. Of course, an important part of the hardware and software design was how to allow applications access to the mapped data areas without allowing them to access control stuff, and as of the time I left the card didn't really work very well anyway. So we have examples of how all these "rules" can and should be broken in specific cases.
Two of the best reasons for putting stuff in the kernel have to do with address spaces and synchronization. The address-space problems are readily resolvable in more advanced research-type operating systems, at least mostly, but in some ways the fundamental and unchangeable UNIX model of processes and address spaces etc. makes this extremely difficult and a new driver is still safer/easier than a severely-hacked virtual memory system even if it's harder/riskier than a user-space program. The synchronization issues are probably more important wrt putting graphics in the kernel or not. If all you're mapping into user space is frame buffers, fine; the worst that can happen is that somebody draws over somebody else's part of the screen. But as soon as you provide user-level access to any other graphics facilities at all, you start opening up a big synchronization Can O' Worms. In some ways, you end up more vulnerable than if you put the gritty bits in the kernel where proper synchronization (which may be complex and non-obvious or even impossible to do without a high level of data sharing which brings you into the address-space side of things) can be rigidly enforced.
I don't know enough about the itty-bitty details of graphics-device interfaces to take a particular stand on whether they should go into the kernel or user space or a little of both (the last seems most likely). I just think that most of the arguments I've seen on the issue are totally "off" wrt why we should or should not implement things in-kernel. There seems to be a lot more ideology and stubbornness involved than actual risk assessment or performance modeling.
Slashdot - News for Herds. Stuff that Splatters.
He brings joy to millions of computer owners worldwide. He probably grew up a total dork, parked behind his 286 for most of his childhood, didn't kiss a girl until he was 20 and you guys bag him for buying an expensive car. Weak. He's got the right idea, spend your teen years learning how to code extremely well, then get rich buy a fast car and get some action when you're older. Smart guy, this one.