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. "
Matrox G200 is "slightly" accelerated, and as it
stands, even once the drivers are mature, will
probably only reach Voodoo1 speeds.
Matrox has withheld specs for their "Warp engine"
which does hardware triangle setup.
Despite 3dfx's recent job offers, it doesnt look
like the video card manufacturers are buckling at
all on the issue of proprietary specs. It's all
lip service so far.
"Why not? How are graphics fundamentally different than, say, network cards?"
Because they're a *lot* more complicated.
Video cards these ARE computers in their own
right. Modern video drivers are among the largest
and most complicated (code-wise) of any drivers
that a modern OS will use. More code == more opportunity
for bugs, and bugs in the kernel are *really* bad
news. You want to keep that stuff well isolated
from anything that could take the whole system
down.
Add to that the fact that the kernel is constantly
changing. It would take a great deal of vigilance
to keep the KGI drivers in working order. Open
source is *NOT* magic, and plenty of Linux kernel
drivers in the past have broken, and stayed
broken for a LONG time.
GGI people will tell you that it's impossible to
write stable video drivers outside the kernel.
It's not true, the drivers for my particular card
are very stable, and X has _NEVER_ crashed my
system.
GGI people, in the many arguments I've had with
them, show their colors: they're game playing,
X haters. They love to rail against X..."it's
big, it's bloated, it's slow, it's insecure, yada
yada yada". On my current system, X, at it's
peak requires less than 5% CPU time and less than
5% of memory. It's NOT bloated, it's NOT slow.
And there's really little of any substance to
fear from suid root X, and even that problem will
be solved without the "ripping up the floorboards"
KGI approach.
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
Carmak has been quite active on the g200 mailing list... (talked general driver opt. looked at the code, etc.)
it's really cool to have his input and point of view on, what is arguably, his domain...
you don't see guys like tim sweeny (sp?) (of unreal) looking at the g200 code the day q3test is supposed to ship for windows!
i believe that he (they - id) has made it (obviously) and has realized that he has made it, and now wants to do 'the right thing' (in their eyes, obviously not opensource q3, but q1 soon). cross platform, help support work on linux, push mac to get off their asses, looked at M$ and decided that if anyone was going to get openGL sorted out (driver wise) that id was going to have to do it themselves, or even push that the graphic card co's put out full opengl drivers... q3 uses a limited subset of openGL (like 90% of the calls are to one method, so that driver guys can easily optimize) and he could have stuck w/ the miniGL hacks that people had, but instead he has single handedly forced all the major card manufactorers to supply the world w/ working openGL drivers, this benifits the end user more than anyone else (ok, the M$ end user).
i wouldn't be surprised if, in the future, he has a few words w/ someone like matrox on behalf of the g200 group (i can dream at least)
henri
Maybe we will see it someday. I think they should plan for it. This requires making a GLXcontext and an X "GC" be the same object, making OpenGL start up with an "identity" transformation that matches the X coordinates (currently it comes up undefined), and as a temporary stopgap, making all X drawing not work if the current GL transform is not the identity or if Z buffer is on (so that people don't use it and then complain later on when it does not work).
I would also like to see X *always* provide a 32-bit true color visual and fake it on the display hardware, so we could stop thinking about those stupid colormaps!
You're probably correct here. I might just be blind to something, but I can't see anything but benefits coming from releasing hardware specs. They won't have to pay in-house developers to release binary drivers. I'd also be more quick to buy some piece of hardware if I knew that it had good drivers.
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. :-)
People donate stuff all the time to these causes. I know friends of mine who have given up video and sound cards to have someone develop linux drivers for them. I wonder if at some point they will be seen as tax write-offs and these donations can increase a thousand-fold.
Eventually programmers could be paid for their donations though others donations.
-----------
Resume
Football Sports Contest - Win $500 for having an e
I noticed that on their web page they have asked folks not to use MesaGL for legal reasons. How about MesaGPL :)
\forall code \in C, \frac{\Delta readability(code)}{\Delta t} < 0
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?
Ummm, but don't hackers get hungry and need shelter? I see no reason not to use the word "Donation" in this case. Besides, I don't agree with your definition of how the word should be used anyways. If you give money to a cause that you think is worthy of your money then it is a donation.
---
I like the Everything links, myself... actually *useful* when you're not familiar with something. and Everything is an interesting project, IMO. not like the links are hard to ignore or anything... just a pleasant little touch
(insert witty quote here)
And a donation to a library only helps people who can read. It's not that big of a difference, after all. It is a donation for something that is freely available to all, just like a donation to a library or museum. Or maybe it's more like sponsoring a poet or author on the condition that he/she release the work to the public for free. The point is, there is much more to charity and donations than feeding and clothing the homeless. Sure that's a great way to make the world a better place, but it's far from the only way.
My own little pet-peeve is that X is still stuck in/with the 2D-window metaphor.
IMHO, direct 3D rendering into multiple X11 windows is too limiting. I want to be able to do it the other way as well; render X11 windows into/onto 3D objects.
I'm tired of looking through windows; I want to be in that room on the other side!
--The more you know, the less you know.
I like the links to Everything. It's not as though they get in the way.
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.