Академический Документы
Профессиональный Документы
Культура Документы
plan (2000)
http://www.team5150.com/~andrew/carmack
March 18, 2007
Contents
1 February 3
1.1 Feb 23, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Feb 24, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 March 5
2.1 Virtualized video card local memory is The Right Thing.
(Mar 07, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Seumas McNally (Mar 27, 2000) . . . . . . . . . . . . . . . . 12
3 April 14
3.1 Apr 06, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 We need more bits per color component in our 3D accel-
erators. (Apr 29, 2000) . . . . . . . . . . . . . . . . . . . . . . 15
4 May 19
4.1 May 08, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 May 09, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 May 14, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 May 17, 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1
John Carmack Archive 2 .plan 2000
5 June 24
5.1 Well, this is going to be an interesting .plan update. (Jun
01, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CONTENTS
Chapter 1
February
This is a public statement that is also being sent directly to Slade at Quake-
Lives regarding http://www.quakelives.com/main/ql.cgi?section=dlagreement&file=
qwcl-win32/
I see both sides of this. Your goals are positive, and I understand the is-
sues and the difficulties that your project has to work under because of
the GPL. I have also seen some GPL zealots acting petty and immature to-
wards you very early on (while it is within everyone’s rights to DEMAND
code under the GPL, it isn’t necessarily the best attitude to take), which
probably colors some of your views on the subject.
We discussed several possible legal solutions to the issues.
This isn’t one of them.
While I doubt your ”give up your rights” click through would hold up in
court, I am positive that you are required to give the source to anyone
that asks for it that got a binary from someone else. This doesn’t provide
the obscurity needed for a gaming level of security.
I cut you a lot of slack because I honestly thought you intended to prop-
erly follow through with the requirements of the GPL, and you were just
3
John Carmack Archive 4 .plan 2000
trying to get something fun out ASAP. It looks like I was wrong.
If you can’t stand to work under the GPL, you should release the code to
your last binary and give up your project. I would prefer that you con-
tinue your work, but abide by the GPL.
If necessary, I will pay whatever lawyer the Free Software Foundation rec-
comends to pursue this.
March
This is something I have been preaching for a couple years, but I finally
got around to setting all the issues down in writing.
Now, the argument (and a whole bunch of tertiary information):
If you had all the texture density in the world, how much texture memory
would be needed on each frame?
For directly viewed textures, mip mapping keeps the amount of refer-
enced texels between one and one quarter of the drawn pixels. When
anisotropic viewing angles and upper level clamping are taken into ac-
count, the number gets smaller. Take 1/3 as a conservative estimate.
Given a fairly aggressive six texture passes over the entire screen, that
equates to needing twice as many texels as pixels. At 1024x768 resolu-
tion, well under two million texels will be referenced, no matter what
the finest level of detail is. This is the worst case, assuming completely
unique texturing with no repeating. More commonly, less than one mil-
lion texels are actually needed.
As anyone who has tried to run certain Quake 3 levels in high quality
5
John Carmack Archive 6 .plan 2000
texture mode on an eight or sixteen meg card knows, it doesn’t work out
that way in practice. There is a fixable part and some more fundamental
parts to the fall-over-dead-with-too-many-textures problem.
The fixable part is that almost all drivers perform pure LRU (least recently
used) memory management. This works correctly as long as the total
amount of textures needed for a given frame fits in the card’s memory
after they have been loaded. As soon as you need a tiny bit more memory
than fits on the card, you fall off of a performance cliff. If you need 14
megs of textures to render a frame, and your graphics card has 12 megs
available after its frame buffers, you wind up loading 14 megs of texture
data over the bus every frame, instead of just the 2 megs that don’t fit.
Having the cpu generate 14 megs of command traffic can drop you way
into the single digit frame rates on most drivers.
If an application makes reasonable effort to group rendering by texture,
and there is some degree of coherence in the order of texture references
between frames, much better performance can be gotten with a swap-
ping algorithm that changes its behavior instead of going into a full thrash:
Freeing the MRU texture seems counterintuitive, but what it does is cause
the driver to use the last bit of memory as a sort of scratchpad that gets
constantly overwritten when there isn’t enough space. Pure LRU plows
over all the other textures that are very likely going to be needed at the
beginning of the next frame, which will then plow over all the textures
that were loaded on top of them.
If an application uses textures in a completely random order, any given
replacement policy has the some effect..
Texture priority for swapping is a non-feature. There is NO benefit to
attempting to statically prioritize textures for swapping. Either a texture
We also took a dash out in my ferrari, thinking ”this is going to be the best
excuse a cop will ever hear if we get pulled over”.
Longbow continued to be successful, and eventually the entire family
was working full time on ”Treadmarks”, their new 3D tank game.
Over email about finishing the technology in Treadmarks, Seumas once
said ”I hope I can make it”. Not ”be a huge success” or ”beat the compe-
tition”. Just ”make it”.
That is a yardstick to measure oneself by.
It is all too easy to lose your focus or give up with just the ordinary dis-
tractions and disappointments that life brings. This wasn’t ordinary. Se-
umas had cancer. Whatever problems you may be dealing with in your
life, they pale before having problems drawing your next breath.
He made it.
Treadmarks started shipping a couple months ago, and was entered in
the Independent Games Festival at the Game Developer’s Conference
this last month. It came away with the awards for technical excellence,
game design, and the grand prize.
I went out to dinner with the McNally family the next day, and had the op-
portunity to introduce Anna to them. One of the projects at Anna’s new
company, Fountainhead Entertainment (http://www.fountainheadent.
com), is a documentary covering gaming, and she had been looking for-
ward to meeting Seumas after hearing me tell his story a few times. The
McNallys invited her to bring a film crew up to Canada and talk with ev-
eryone whenever she could.
Seumas died the next week.
I am proud to have been considered an influence in Seumas’ work, and I
think his story should be a good example for others. Through talent and
determination, he took something he loved and made a success out of it
in many dimensions.
http://www.gamedev.net/community/memorial/seumas/ for more infor-
mation.
April
13
John Carmack Archive 14 .plan 2000
My first recollection of a Jim Blinn article many years ago was my skim-
ming over it and thinking ”My god, what ridiculously picky minutia.”
Over the last couple years, I found myself haranguing people over some
fairly picky issues, like the LSB errors with cpu vs rasterizer face culling
and screen edge clipping with guard band bit tests. After one of those
pitches, I quite distinctly thought to myself ”My god, I’m turning into Jim
Blinn!” :)
I have been pushing for a couple more bits of range for several years now,
but I now extend that to wanting full 16 bit floating point colors through-
out the graphics pipeline. A sign bit, ten bits of mantissa, and five bits of
exponent (possibly trading a bit or two between the mantissa and expo-
nent). Even that isn’t all you could want, but it is the rational step.
It is turning out that I need a destination alpha channel for a lot of the
new rendering algorithms, so intermediate solutions like 10/12/10 RGB
formats aren’t a good idea. Higher internal precision with dithering to 32
bit pixels would have some benefit, but dithered intermediate results can
easily start piling up the errors when passed over many times, as we have
seen with 5/6/5 rendering.
Eight bits of precision isn’t enough even for full range static image dis-
play. Images with a wide range usually come out fine, but restricted range
images can easily show banding on a 24-bit display. Digital television
specifies 10 bits of precision, and many printing operations are performed
with 12 bits of precision.
The situation becomes much worse when you consider the losses after
multiple operations. As a trivial case, consider having multiple lights on
a wall, with their contribution to a pixel determined by a texture lookup.
A single light will fall off towards 0 some distance away, and if it covers a
large area, it will have visible bands as the light adds one unit, two units,
etc. Each additional light from the same relative distance stacks its con-
tribution on top of the earlier ones, which magnifies the amount of the
step between bands: instead of going 0,1,2, it goes 0,2,4, etc. Pile a few
lights up like this and look towards the dimmer area of the falloff, and
you can believe you are back in 256-color land.
There are other more subtle issues, like the loss of potential result values
from repeated squarings of input values, and clamping issues when you
sum up multiple incident lights before modulating down by a material.
Range is even more clear cut. There are some values that have intrinsic
ranges of 0.0 to 1.0, like factors of reflection and filtering. Normalized
vectors have a range of -1.0 to 1.0. However, the most central quantity in
rendering, light, is completely unbounded. We want a LOT more than a
0.0 to 1.0 range. Q3 hacks the gamma tables to sacrifice a bit of precision
to get a 0.0 to 2.0 range, but I wanted more than that for even primi-
tive rendering techniques. To accurately model the full human sensable
range of light values, you would need more than even a five bit exponent.
This wasn’t much of an issue even a year ago, when we were happy to just
cover the screen a couple times at a high framerate, but realtime graphics
is moving away from just ”putting up wallpaper” to calculating complex
illumination equations at each pixel. It is not at all unreasonable to con-
sider having twenty textures contribute to the final value of a pixel. Range
and precision matter.
A few common responses to this pitch:
”64 bits per pixel??? Are you crazy???” Remember, it is exactly the same
relative step as we made from 16 bit to 32 bit, which didn’t take all that
long.
Yes, it will be slower. That’s ok. This is an important point: we can’t con-
tinue to usefully use vastly greater fill rate without an increase in preci-
sion. You can always crank the resolution and multisample anti-alaising
up higher, but that starts to have diminishing returns well before you
use of the couple gigatexels of fill rate we are expected to have next year.
The cool and interesting things to do with all that fill rate involves many
passes composited into less pixels, making precision important.
”Can we just put it in the texture combiners and leave the framebuffer
at 32 bits?” No. There are always going to be shade trees that overflow
a given number of texture units, and they are going to be the ones that
need the extra precision. Scales and biases between the framebuffer and
the higher precision internal calculations can get you some mileage (as-
suming you can bring the blend color into your combiners, which cur-
rent cards can’t), but its still not what you want. There are also passes
which fundamentally aren’t part of a single surface, but still combine to
the same pixels, as with all forms of translucency, and many atmospheric
effects.
”Do we need it in textures as well?” Not for most image textures, but it
still needs to be supported for textures that are used as function look up
tables.
”Do we need it in the front buffer?” Probably not. Going to a 64 bit front
buffer would probably play hell with all sorts of other parts of the system.
It is probably reasonable to stay with 32 bit front buffers with a blit from
the 64 bit back buffer performing a lookup or scale and bias operation
before dithering down to 32 bit. Dynamic light adaptation can also be
done during this copy. Dithering can work quite well as long as you are
only performing a single pass.
I used to be pitching this in an abstract ”you probably should be doing
this” form, but two significant things have happened that have moved
this up my hit list to something that I am fairly positive about.
Mark Peercy of SGI has shown, quite surprisingly, that all Renderman sur-
face shaders can be decomposed into multi-pass graphics operations if
two extensions are provided over basic OpenGL: the existing pixel tex-
ture extension, which allows dependent texture lookups (matrox already
supports a form of this, and most vendors will over the next year), and
signed, floating point colors through the graphics pipeline. It also makes
heavy use of the existing, but rarely optimized, copyTexSubImage2D func-
tionality for temporaries.
This is a truly striking result. In retrospect, it seems obvious that with
adds, multiplies, table lookups, and stencil tests that you can perform
any computation, but most people were working under the assumption
that there were fundamentally different limitations for ”realtime” render-
ers vs offline renderers. It may take hundreds or thousands of passes, but
May
The .qc files for quake1/quakeworld are now available under the GPL in
source/qw-qc.tar.gx on out ftp site. This was an oversight on my part in
the original release.
Thanks to the QuakeForge team for doing the grunt work of the prepara-
tion.
And the Q1 utilities are now also available under the GPL in source/q1tools gpl.tgz.
I stayed a couple days after E3 to attend the SORAC amateur rocket launch.
I have provided some sponsorship to two of the teams competing for the
CATS (Cheap Access to Space) rocketry prize, and it was a nice opportu-
18
John Carmack Archive 19 .plan 2000
I have gotten a lot of requests for comments on the latest crop of video
cards, so here is my initial technical evaluation. We have played with
some early versions, but this is a paper evaluation. I am not in a position
to judge 2D GDI issues or TV/DVD issues, so this is just 3D commentary.
Nvidia Marketing silliness: saying ”seven operations on a pixel” for a dual
texture chip. Yes, I like NV register combiners a lot, but come on..
The DDR GeForce is the reigning champ of 3D cards. Of the shipping
boards, it is basically better than everyone at every aspect of 3D graphics,
and pioneered some features that are going to be very important: signed
pixel math, dot product blending, and cubic environment maps.
The GeForce2 is just a speed bumped GeForce with a few tweaks, but
that’s not a bad thing. Nvidia will have far and away the tightest drivers
for quite some time, and that often means more than a lot of new features
in the real world.
The nvidia register combiners are highly programmable, and can often
save a rendering pass or allow a somewhat higher quality calculation, but
on the whole, I would take ATI’s third texture for flexibility.
Nvidia will probably continue to hit the best framerates in benchmarks
at low resolution, because they have flexible hardware with geometry ac-
celeration and well-tuned drivers.
GeForce is my baseline for current rendering work, so I can wholeheart-
edly recommend it.
ATI Marketing silliness: ”charisma engine” and ”pixel tapestry” are silly
names for vertex and pixel processing that are straightforward improve-
ments over existing methods. Sony is probably to blame for starting that.
The Radeon has the best feature set available, with several advantages
over GeForce:
A third texture unit per pixel
Three dimensional textures
Dependent texture reads (bump env map)
Greater internal color precision.
User clip planes orthogonal to all rasterization modes.
More powerful vertex blending operations.
The shadow id map support may be useful, but my work with shadow
buffers have shown them to have significant limitations for global use in
a game.
On paper, it is better than GeForce in almost every way except that it
is limited to a maximum of two pixels per clock while GeForce can do
four. This comes into play when the pixels don’t do as much memory ac-
cess, for example when just drawing shadow planes to the depth/stencil
buffer, or when drawing in roughly front to back order and many of the
later pixels depth fail, avoiding the color buffer writes.
Depending on the application and algorithm, this can be anywhere from
basically no benefit when doing 32 bit blended multi-pass, dual texture
June
Most of this is not really public business, but if some things aren’t stated
explicitly, it will reflect unfairly on someone.
As many people have heard discussed, there was quite a desire to remake
DOOM as our next project after Q3. Discussing it brought an almost pal-
pable thrill to most of the employees, but Adrian had a strong enough
dislike for the idea that it was shot down over and over again.
Design work on an alternate game has been going on in parallel with the
mission pack development and my research work.
Several factors, including a general lack of enthusiasm for the proposed
plan, the warmth that Wolfenstien was met with at E3, and excitement
about what we can do with the latest rendering technology were making
it seem more and more like we weren’t going down the right path.
I discussed it with some of the other guys, and we decided that it was
important enough to drag the company through an unpleasant fight over
it.
An ultimatum was issued to Kevin and Adrian(who control > 50% of the
23
John Carmack Archive 24 .plan 2000
company): We are working on DOOM for the next project unless you fire
us.
Obviously no fun for anyone involved, but the project direction was changed,
new hires have been expedited, and the design work has begun.
It wasn’t planned to announce this soon, but here it is: We are working on
a new DOOM game, focusing on the single player game experience, and
using brand new technology in almost every aspect of it. That is all we
are prepared to say about the game for quite some time, so don’t push for
interviews. We will talk about it when things are actually built, to avoid
giving misleading comments.
It went smoother than expected, but the other shoe dropped yesterday.
Kevin and Adrian fired Paul Steed in retaliation, over my opposition.
Paul has certainly done things in the past that could be grounds for dis-
missal, but this was retaliatory for him being among the ”conspirators”.
I happen to think Paul was damn good at his job, and that he was going
to be one of the most valuable contributors to DOOM.
We need to hire two new modeler/animator/cinematic director types. If
you have a significant commercial track record in all three areas, and
consider yourself at the top of your field, send your resume to Kevin
Cloud.