The Dawn of Nvidia's Technology
While the nitty gritty detail of recollections captured when still fresh in memory can be fascinating, I especially appreciate reflections written a few decades later as it allows putting the outcomes of key decisions in perspective, as well as generally enabling more frank assessments thanks to fewer business and personal concerns.
So judging by actions, not words, they had a clear software/firmware advantage by then already.
Cuda is ok, but it's the sheer mass of people targeting the platform that makes it more interesting than eg opencl. It hasn't don't anything clearly better aside from aggressively trying to court developer interest. It will pass and we will have stronger runtimes for it.
What really sets nvidia apart is its ability to market to people. Truly phenomenal performance.
largely an artifact of luck.
I disagree with "largely". Luck is always a factor in business success and there are certainly some notable examples where luck was, arguably, a big enough factor that "largely" would apply - like Broadcast.com's sale to Yahoo right at the peak of the .com bubble. However, I'm not aware of evidence luck was any more of a factor in NVidia's success than the ambient environmental constant it always is for every business. Luck is like the wind in competitive sailing - it impacts everyone, sometimes positively, sometimes negatively.
Achieving and then sustaining substantial success over the long run requires making a lot of choices correctly as well as top notch execution. The key is doing all of that so consistently and repeatedly that you survive long enough for the good and bad luck to cancel each other out. NVidia now has over 30 years of history through multiple industry-wide booms, downturns and fundamental technology transitions - a consistent track record of substantial, sustained success so long that good luck can't plausibly be a significant factor.
That said, to me, this article didn't try to explain NVidia's long-term business success. It focused on a few key architectural decisions made early on which were, arguably, quite risky in that they could have wasted a lot of development on capabilities which didn't end up mattering. However, they did end up paying off and, to me, the valuable insight was that key team members came from a different background than their competitors and their experiences with multi-user, multi-tasking, virtualized mini and mainframe architectures caused them to believe desktop architectures would evolve in that direction sooner rather than later. The takeaway being akin to "skate to where the puck is going, not where it is." In rapidly evolving tech environments, making such predictions is greatly improved when the team has both breadth and depth of experience in relevant domains.
At a time when PC memory maxed out at 640 megabytes,
Pretty sure the author meant write 640 kilobytes.
At a time when PC memory maxed out at 640 megabytes, the fact that the PCI bus could address 4 gigabytes meant that quite a few of its address bits were surplus. So we decided to increase the amount of data shipped in each bus cycle by using some of them as data. IIRC NV1 used 23 address bits, occupying 1/512th of the total space. 7 of the 23 selected one of the 128 virtual FIFOs, allowing 128 different processes to share access to the hardware. We figured 128 processes was plenty.
PC memory was nearly always sold in powers of two. So you could have SIMMs in capacity of 1MiB, 2MiB, 4, 8, 16MiB. You could usually mix-and-match these memory modules, and some PCs had 2 slots, some had 4, some had a different number of slots.
So if you think about 4 slots that can hold some sort of maximum, we're thinking 64MiB is a very common maximum for a consumer PC, and that may be 2x32 or 4x16MiB. Lots of people ran up against that limit for sure.
640MiB is an absurd number if you think mathematically. How do you divide that up? If 4 SIMMs are installed, then their capacity is 160MiB each? No such hardware ever existed. IIRC, individual SIMMs were commonly maxed at 64MiB, and it was not physically possible to make a "monster memory module" larger than that.
Furthermore, while 64MiB requires 26 bits to address, 640MiB requires 30 address bits on the bus. If a hypothetical PC had 640MiB in use by the OS, then only 2 pins would be unused on the address bus! That is clearly at odds with their narrative that they were able to "borrow" several more!
This is clearly a typo and I would infer that the author meant to write "64 megabytes" and tacked on an extra zero, out of habit or hyperbole.
I can’t find the purchase receipts or specific board brand but it had four SDRAM slots, and I had it populated with 2x64 and 2x256.
Edit: Found it in some old files of mine:
I was wrong! Not four DIMM slots... three! One must have been 128 and the other two 256.
Pentium II 400, 512k cache
Abit BF6 motherboard
640 MB PC100 SDRAM
21" Sony CPD-G500 (19.8" viewable, .24 dot pitch)
17" ViewSonic monitor (16" viewable, .27 dot pitch)
RivaTNT PCI video card with 16 MB VRAM
Creative SB Live!
Creative 5x DVD, 32x CD drive
Sony CD-RW (2, 4, 24)
80 GB Western Digital ATA/100
40 GB Western Digital ATA/100
17.2 GB Maxtor UltraDMA/33 HDD
10.0 GB Maxtor UltraDMA/33 HDD
Cambridge SoundWorks FourPointSurround FPS2000 Digital
3Com OfficeConnect 10/100 EtherNet card
3 Microsoft SideWinder Gamepads
Labtec AM-252 Microphone
Promise IDE Controller card
Hauppage WinTV-Theatre Tuner CardI don't think any mathematical relationship between the address bus and either 640KiB or 640MiB was intended, it was just the anchor point for how huge 4GiB of addressing was viewed at the time.
The article then goes on to say that the NV1 used 23 bits of the address bus but adds in the next paragraph that 16 bits remained to use for data. That math isn't working out for me.
Actually, I'm really struggling to understand how this scheme would work at all. It strongly implies open addressing with no other MMIO devices to conflict with, but that's just not how I thought PCI worked. Maybe someone who knows more can explain it to me.
The whole thing a bit ironic since Bill Gates took great pains to say he never said 640KiB is all you need (or something like that). Given my example of the IBM PC/AT it definitely was not common understanding of upper limits in 1995 apocryphal or not.
Another possibility: apparently https://www.os2museum.com/wp/windows-nt-3-1-and-os2-memory-d... all x86 machines released before maybe 1993 are restricted to 64MiB, even under Windows NT and other fully 32-bit OSes, because the BIOS simply can't report having any more RAM than that. By early 1993 the first "service" allowing the reporting of more than 64MiB of system RAM (up to the full 4GiB supported by x86) was starting to appear on some BIOSes.
Apparently the effective memory limit for Windows 3.1 is 256MiB https://web.archive.org/web/20150518111050/https://support.m... while for Windows 95 it's approximately 480MiB https://devblogs.microsoft.com/oldnewthing/20030814-00/?p=42... . So it's plausible that Rosenthal had one of those in mind, even if 640MiB is not exactly the right number (and even if you'd actually hit BIOS or wallet limitations first).
The days of 640 kB memory were long forgotten.
Even in 1990, a decent PC would have had a 386 CPU with 4 MB of RAM, which would have been used as extended memory by the MS-DOS programs, while the cheapest computers would have been PC/XT clones with a NEC V20 CPU and with 2 MB of expanded memory, so still well beyond the 640 kB.
It made everything feel real!
Later, the company switched new employees to 3x 10,000 RPM SATA drives. Not quite as grindy, but still loud.
I remain a bit mystified about why it would be a hard maximum, though. Did such motherboards prevent the user from installing 4x256MiB for a cool 1GiB of DRAM? Was the OS having trouble addressing or utilizing it all? 640MiB is not a mathematical sort of maximum I was familiar with from the late 1990s. 4GiB is obviously your upper limit, with a 32-bit address bus... and again, if 640MiB were installed, that's only 2 free bits on that bus.
So I'm still a little curious about this number being dropped in the article. More info would be enlightening! And thank you for speaking up to correct me! No wonder it was down-voted!
That was a weird time in computing. Things were getting fast and big quickly (not that many years later, I built a dual-socket Xeon at 2.8 GHz, and before that my brother had a dual socket P3 at 700 MHz.) but all the expansion boards were so special-purpose. I remember going out of my way to pick a board with something like seven expansion slots.
But I think your question about why the author said 640 is fair! Maybe they had a machine like mine around then. Or maybe it’s something NVIDIA was designing around?
I remain a bit mystified about why it would be a hard maximum, though. Did such motherboards prevent the user from installing 4x256MiB for a cool 1GiB of DRAM?
Probably not - it's not that rare to see the supported maximum memory be a function of the biggest DIMM you can buy, I guess as a reflection of the biggest configuration the manufacturer could test.
I had a few such motherboards, with Pentium III "Coppermine" and with AMD Athlon "Thunderbird" (with 3 DIMM sockets, 2 accepting 256 MB modules and 1 accepting 128 MB modules).
While I had initially equipped them with less memory, i.e. either 128 MB or 256 MB, because of the high cost at that time, eventually I had maxed up the installed memory to 640 MB on the Athlon motherboards.
At that time, the memory controller was not included in the CPU, but it was contained in an external chip, the Northbridge. The MB chipsets could come from various vendors, including Intel and Via. Depending on the chipset, different maximum amounts of SDRAM could be supported. Sometimes there were also limits for the maximum amount of RAM caused by the L2 cache controller, due to the size of the tags required in cache lines. Even with the same chipset, the MB manufacturer could choose to route different numbers of address lines to the sockets, probably depending on whether the extra capacitive loading caused by a bigger memory module would have allowed it to function at the rated speed on that PCB.
64 MB would have been a typical maximum memory around 1998 (2 sockets for 32 MB SDRAM modules, on a MB with an AGP socket for the graphics card), so if the author would have had that year in mind, you would be right.
https://en.wikipedia.org/wiki/Synchronous_dynamic_random-acc...
Undervolted and OC'd to 1800+ under Linux, 2100+ under NetBSD.
Stable and rock-solid :-)
https://en.wikipedia.org/wiki/DIMM#History
The GP may be thinking of double-sided modules, which could be SIMMs or could be DIMMs; it was just a matter of how the chips were arranged.
https://news.ycombinator.com/item?id=18120477
https://groups.google.com/g/alt.folklore.computers/c/mpjS-h4...
QUESTION: I read in a newspaper that in 1981 you said, ``640K of memory should be enough for anybody.'' What did you mean when you said this?
ANSWER: I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time.
The need for memory increases as computers get more potent and software gets more powerful. In fact, every couple of years the amount of memory address space needed to run whatever software is mainstream at the time just about doubles. This is well-known.
When IBM introduced its PC in 1981, many people attacked Microsoft for its role. These critics said that 8-bit computers, which had 64K of address space, would last forever. They said we were wastefully throwing out great 8-bit programming by moving the world toward 16-bit computers.
We at Microsoft disagreed. We knew that even 16-bit computers, which had 640K of available address space, would be adequate for only four or five years. (The IBM PC had 1 megabyte of logical address space. But 384K of this was assigned to special purposes, leaving 640K of memory available. That's where the now-infamous ``640K barrier'' came from.)
A few years later, Microsoft was a big fan of Intel's 386 microprocessor chip, which gave computers a 32-bit address space.
Modern operating systems can now take advantage of that seemingly vast potential memory. But even 32 bits of address space won't prove adequate as time goes on.
Meanwhile, I keep bumping into that silly quotation attributed to me that says 640K of memory is enough. There's never a citation; the quotation just floats like a rumor, repeated again and again.
Now we have Vulkan. Vulkan standardizes some things, but has a huge number of options because hardware design decisions are exposed at the Vulkan interface. You can transfer data from CPU to GPU via DMA or via shared memory. Memory can be mapped for bidirectional transfer, or for one-way transfer in either direction. Such transfers are slower than normal memory accesses. You can ask the GPU to read textures from CPU memory because GPU memory is full, which also carries a performance penalty. Or you can be on an "integrated graphics" machine where CPU and GPU share the same memory. Most hardware offers some, but not all, of those options.
This is why a lot of stuff still uses OpenGL, which hides all that.
(I spent a few years writing AutoCAD drivers for devices now best forgotten, and later trying to get 3D graphics to work on PCs in the 1990s. I got to see a lot of graphics boards best forgotten.)
The talk being "The Road to The Future".
I've discussed this in the context of Rust renderers. There are about four of them, and they all sit on top of Vulkan and export roughly similar APIs. The API is roughly comparable to three.js - meshes, textures, materials, lights, shadows, and updating are supported. They all get to the point where they can load static glTF scenes, and then the devs hit the hard concurrency problems and bail.
That's a much more comfortable level for users who need to get something done in 3D. Vulkan level belongs to people who write engines.
Getting off topic, though. This is not a retro problem. This is a current problem.
Further discussion on the Vulkan roadmap request for comments on Discord, here.[2]
[1] https://vulkan.org/user/pages/09.events/vulkanised-2025/T2-T...
[2] https://discord.com/channels/427551838099996672/115155677637...
This is why a lot of stuff still uses OpenGL, which hides all that.
Kind of. If you go look, they usually load extensions, which expose more hardware functionality.
https://video.matrox.com/en/about/history-of-innovation
1996: Matrox launches the Matrox Genesis Series vision processor, and with its highly pipelined, parallel-processing architecture, establishes a new performance industry standard.The company also introduces Matrox DigiSuite, the first affordable all-digital system for real-time, non-linear editing. The award-winning DigiSuite breaks new ground in offering a full set of professional-quality editing and effects capabilities. DigiSuite becomes the world's best-selling professional video editing card.
Because Nvidia became one of the most valuable companies in the world, there are now two books explaining its rise and extolling the genius of Jensen Huang,
Yeah, he's a real genius. (Sarcasm). He is a marking guy, there is no genius behind this man.
The fact that Nvidia uses its market position cause harm to the industry by strong-arming partners to toe the line makes this company a problem, just like all the others. They operate like any other predatory corporation.
He is a marking guy,
You would be wrong. He worked at AMD as a design engineer, and later went to LSI logic helping customers put out custom ASICs. One of his customers, a big customer, was Sun, helping with their SPARC processor and the GX graphics chips, and no doubt many others.
In 1989-1991 I did three ASICs at LSI Logic -- and Jensen was my liason there on the latter two. He was incredibly smart, hard working, technically knowledgeable, kind, patient, and generous with his time despite being very busy.
The marketing stuff came later (or maybe said better: it was latent and it came out later)
Back then I was quite p***d not being able to keep the Voodoo, how little did I know how it was going to turn out.
He worked with James Gosling on Andrew at CMU and NeWS at Sun, and on X10 as well as X11 and ICCCM, and he implemented the original X10 compatibility layer that was in NeWS 1.0, before X11 was a "thing".
https://en.wikipedia.org/wiki/David_S._H._Rosenthal
One of my favorite classics is his Recreational Bugs talk[1989] by "Sgt." David Rosenthal (author of the ICCCM, developer of the Andrew Window Manager, X10, X11, and NeWS, employee #4 and chief scientist at Nvidia):
https://blog.dshr.org/2018/05/recreational-bugs.html
"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.
Here's his review of "The Philosopher of Palo Alto", a book about Mark Weiser:
https://blog.dshr.org/2023/06/the-philosopher-of-palo-alto.h...
At the 1985 Alvey Workshop "Methodology of Window Management", David Rosenthal and James Gosling presented "System Aspects of Low-Cost Bitmapped Displays" and "A Window Manager for Bitmapped Displays and Unix" about their work on Andrew at CMU. And James presented "SunDew - A Distributed and Extensible Window System" about his work at Sun, which was later renamed NeWS, and was what convinced David to leave CMU and join him at Sun.
System Aspects of Low-Cost Bitmapped Displays:
https://www.chilton-computing.org.uk/inf/literature/books/wm...
A Window Manager for Bitmapped Displays and Unix (with the first known use of the term "Gorilla effect" as it applies to computer graphics):
https://www.chilton-computing.org.uk/inf/literature/books/wm...
SunDew - A Distributed and Extensible Window System:
https://www.chilton-computing.org.uk/inf/literature/books/wm...
Warren Teitelman's "Ten Years of Window Systems - A Retrospective View" covers the fascinating history of Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew systems:
https://www.chilton-computing.org.uk/inf/literature/books/wm...
Here's David Rosenthal's notorious Sun Deskset Environment flame that some rogue leaked to the Unix-Haters mailing list (inspiring the Unix-Haters Handbook's X-Windows chapter), in which he poignantly concluded:
"It's like having a Roy Lichtenstein painting on your bedroom wall.":
From: DR
Date: 18 Oct 90 17:02:39 GMT
Newsgroups: sun.open-windows
Subject: Re: Deskset environment
[NS replied to me directly. Her reply illustrates the
reasons why I sent out yesterday's mail so perfectly that
I'm taking the liberty of copying my reply to
openwindows-interest]
> When we give standard Deskset presentations, a couple of
> things tend to "dazzle" the audience ...
>
> 1. Use the MT Calendar template to generate an
> appointment. Mail it to yourself, then
> drop it onto CM which will schedule it. The
> template is totally hokey (we're working on
> it) but it works and is wizzy.
>
> 2. Build a small application with GUIDE and make it
> on the spot. Show it up and running on XView
> in minutes. You can talk to BW about that
>
Thank you, but you have completely missed the point. I
don't want to show people how whizzy the standard default
desktop environment is. That's your job.
I want to give a talk about a quite different subject. I
merely want to *use* the desktop environment to achieve my
own ends. And as soon as I try to actually *use* it for
something instead of merely showing off the glitz, it falls
to pieces in my hands. Unfortunately, this is becoming all
too common in Sun products these days, because we no longer
*use* the things we build for anything but whizzy demos.
Have you ever actually tried to *use* the desktop for
anything? Like, say, printing a PostScript file? The
answer has to be no - because dropping a PostScript file on
the print tool doesn't work. Or binding a shell command to
a pattern? Again no, because doing so depends on
undocumented features of /etc/filetype. Even trying to
create a new icon from the standard set causes the icon
editor to dump core. I'm not joking when I say that I've
been filing a bug report every couple of hours of trying to
use the desktop. Its this kind of fragility that shows me
that I'm treading on fresh snow. No-one else has walked
this way.
And that is a truly sad commentary on the state of Sun -
no-one has been this way because no-one believes that
there's anything worth doing over this way. The reason Unix
was such an advance over previous operating systems was that
you could customize your environment in arbitrary ways.
With just a few shell scripts, for example. Its just like
the cold war - in our anxiety to compete with the enemy
we've ended up losing the things that made our way of life
worth defending in the first place. Like the freedom to
disagree with the authorities.
> I believe you're correct in saying that most people live
> with the default environment, but I think it's only partly
> because they don't know how to customize it. We've done
> some user testing and, surprisingly, people either prefer
> the default environment or just don't want to take the
> time to make it special. This is particularly true of
> people like admins, marketing, etc.
Testing whether people actually do customize their
environment is beside the point. Of course they don't. In
order to do it, I have to write C code using bizarre
features of Xview, exercise all my shell wizardry, and
dredge up undocumented features of the system from the
source. And you're suprised when admins can't do this? I
don't expect admins to do it. But I do expect ISVs and
Sun's SEs to be able to do it, and right now they can't.
PS - I notice that someone filed a bug today pointing out
that even your example of dropping a mail message on CM
doesn't work if CM is closed. That's a symptom of the kind
of arrogance that all the deskset tools seem to show -
they're so whizzy and important that they deserve acres of
screen real estate. Why can't they just shut up and do
their job efficiently and inconspicuously? Why do they have
to shove their bells and whistles in my face all the time?
They're like 50's American cars - huge and covered with
fins. What I want is more like a BMW, small, efficient,
elegant and understated. Your focus on the whizzy demos may
look great at trade shows, but who wants to have their tools
screaming at them for attention all the time? It's like
having a Roy Lichtenstein painting on your bedroom wall.all an application could do was to invoke methods on virtual objects .. the application could not know whether the object was implemented in hardware or in the resource manager's software. The flexibility to make this decision at any time was a huge advantage. As Kim quotes Michael Hara as saying:“This was the most brilliant thing on the planet. It was our secret sauce. If we missed a feature or a feature was broken, we could put it in the resource manager and it would work.”
Absolutely brilliant. Understand the strengths and weaknesses of your tech (slow/updateable software vs fast/frozen hardware) then design the product so a missed deadline won’t sink the company. A perfect combo of technically savvy management and clever engineering.
It was one of the earliest Sun games distributed with a free playable demo that you could unlock by buying a license key. It would let you play for a minute or so and then the simulation would stop abruptly. That inspired me to do the same thing with SimCity for the Sun: you could play for a few minutes, then the simulator would switch to a cellular automata that would scramble your city, until you bought a license key to unlock it.
The GX was an 8-bit display, so it uses a 256 color palette, and drew shaded colors by halftone stippling. You can clearly see that in this video:
Aviator 1.5.1 running on SunOS 4.1.4 on a Sparcstation 20
https://www.youtube.com/watch?v=4RQscDJCy4c
Aviator had "aircraftcap" file in the format of (yech) a termcap file, that allowed you to configure your aircraft, and several fighter aircraft, small planes, and a 747 were included.
I heard a story about a fighter pilot who played Aviator, but he noticed something was wonky about how a plane he was familiar with flew. So he too a look at the aircraftcap file, and was able to find the problem, tweak it, and then it flew much more to his satisfaction!
You could dogfight over the network, and the sneaky thing to do was to hack your aircraftcap file to mount your guided missiles far behind you fighter jet, so when somebody was on your tail, you could shoot them in the ass!
Software in silicon: the methodology behind Sun's GX graphics accelerator architecture:
https://ieeexplore.ieee.org/document/63673
Sun GX Series Graphics Workstations:
https://old.hotchips.org/wp-content/uploads/hc_archives/hc01...
AVIATOR 1.5 FOR SUN NETWORKS OPENS UP GRAPHICS WORKSTATION GAMES MARKET (July 8 1991):
https://www.techmonitor.ai/hardware/aviator_15_for_sun_netwo...
SGI Users Group Forum: "Aviator" - a flight sim program for Sun GX - does anyone have this installed? Can anyone run it and get screenshots or video?
https://forums.sgi.sh/index.php?threads/aviator-a-flight-sim...
Vintage Computer Federation Forums: The "Aviator" flight sim for Sun GX hardware (e.g. SPARCstations)
https://forum.vcfed.org/index.php?threads/the-aviator-flight...
Reddit: A request to owners of Sun GX hardware such as SPARCstations: Can anyone post screenshots or footage from the late 80s/early 90s flight sim "Aviator"?
https://www.reddit.com/r/vintagecomputing/comments/y9zfhs/a_...