Affiliates
NVIDIA Editors' Day 2003
Date: 2003-10-27 | Author: Chad Unrein
Company:
Related Reviews:
Introduction
In an effort to shake things up a bit in their public relations efforts, NVIDIA held their first ever Editors' Day on Tuesday, October 21, 2003 in San Francisco, California. They invited web affiliates and developers from around the world to be a part of this unique event. I was lucky enough to get to go to represent Bjorn3D.com. Many of NVIDIA's representatives stressed that this event was unlike anything else they have ever done. How you ask? For one, high level people who have been crucial in getting NVIDIA where it is today were more accessible than usual. These people included: David Kirk, Chief Scientist; Kurt Akeley, Chief Technical Officer; Dwight Diercks, Vice President of Software Engineering; Nick Triantos, Director of OpenGL Software Development; and Ben De Waal, Director of DirectX Software Development. Even NVIDIA CEO and co-founder Jen-Hsun Huang joined the group to talk to us about the company during lunch. He was joined by id's CEO, Todd Hollenshead.

The first part of the day focused on educating the attendees about some of the technology in the GeForceFX line of graphics cards and debunking some of the negative press NVIDIA has received about performance and optimizations. And the second part of the day was focused on developers' relationships with NVIDIA and showcasing new games that will be coming out sooner (XIII) or later (S.T.A.L.K.E.R.).
I must admit that I have never been to any event like this or anything close to this. Not even a renowned LAN event. Unfortunately, that means I cannot really compare it to anything else NVIDIA or any other company has done. So, I'll just cover the event as it was and as I experienced it.
Shady Shader Tales and Onerous Optimizations?
The day started off with a series of four presentations given by Kurt Akeley, David Kirk, Dwight Diercks, and Nick Triantos. They presented their topics on 21st Century Graphics Architecture as the rest of the team sat in front of the audience as a panel for answering questions, which the attendees were encouraged to ask at any time and about anything. Ben De Waal was also a member of the panel.
![]() |
| From left to right: David Kirk, Nick Triantos, Ben De Waal, Dwight Diercks, and Kurt Akeley (standing behind Diercks). |
Kurt Ackeley started off with his presentation about how graphics APIs, namely DirectX, are continuing to become more and more procedural. Earlier graphics APIs were more descriptive in nature. He covered the challenges this poses for programming and optimization. I'm not going to go into any more detail on this topic because I think people really want to read about what NVIDIA said about some of the more controversial topics as of late.
David Kirk dove right into the controversial topic of pixel shaders with his presentation. He also discussed some of the architectural choices NVIDIA made for their latest NV3x chips. Basically, much of the presentation was spent defending and explaining NVIDIA's choice to go with mixed mode (16-bit and 32-bit) floating point precision. Of course, he pointed out all the pitfalls of going with 24-bit floating point (as ATI did with their latest generation of graphics chips). I think he would have liked to go with a completely 32-bit architecture, but, as he pointed out that is not economical right now, and the NV35 would have been twice the size it is today! That would make it even more expensive! Also, Kirk believes that a pure 16-bit or 24-bit architecture is not a good choice either because some programs will not work at all because of the lack of precision. Going with either of these options would have made NV35 smaller, faster, and easier to work with, but it also would have been less capable. Another fine point he made was that there is an IEEE standard for 32-bit floating point, which NVIDIA follows, and although there is not a standard for 16-bit, many animation studios, CAD and authoring tools, and Adobe's Photoshop use it. However, there is no standard for 24-bit floating point. Now, I don't mean to make this out to be a huge issue, but I think using standards and accepted practices is a good thing, and I think NVIDIA deserves some credit for it. The key thing Kirk said that NVIDIA did poorly was unintentionally making their NV3x architecture difficult to write programs for quickly. He also showed a slide that presented some limitations of the architecture that I believe had not previously been made public. I must admit that I do not fully understand all of these, and I did not get great notes about what he said about them. But, for the sake of the reader, I will provide the information as it was on his slide:
Performance Limits:
Setup -> Triangle FIFO clocks/triangle
Gatekeeper: 4 clocks/triangle, 32 triangles in flight, 128 parameters in flight
Quad loopback RAM: 256 2-register quads in flight
Core FIFO & texture latency FIFO: >176 slots in flight
Core, texture unit: 1 quad * 2 textures / clock
Max # registers up to 32, depending on precision
Register port limitation: shader/combiner conflict
Well, there you have it, straight from the Chief Scientist. I will let you digest those facts and interpret them as you will. Finally, Kirk pointed out that the GeforceFX architecture is optimized for long shaders (up to 1024 instructions) and interleaved texture/math instructions, but it is sensitive to instruction order. That is why they put so much effort into their shader optimizing compiler. In contrast, the Radeon architecture is optimized for short shaders (only up to 64 instructions) and blocks of texture/math instructions but sensitive to instruction co-issue (vector/scalar paired instructions) and dependent texture fetch limitations. Of couse, this is all coming from an NVIDIA employee, so interpret it how you will, but I don't think he was spinning it too much. He firmly believes that the full power of the NV3x architecture has not been exploited yet or is just now being realized.
One thing that I think we must keep in mind when reading/thinking about these issues is that developers had ATI hardware long before NVIDIA hardware; therefore, NVIDIA has had to play catch up for a while. It is the first time in many hardware generations that NVIDIA has been in this position, and it has been a learning experience for them.
Director of Software Engineering Nick Triantos followed up the shader presentation with one about NVIDIA's new optimization guidelines and the GeForceFX Unified Compiler's role in this. In an effort to gain people's trust again in the wake of the much publicized driver "compromises" the company has made over the last year or so, NVIDIA wants the world to know that is now following a strict process for optimization analysis. Before these guidelines were in place, individual developers usually decided on what would work best for an optimization, and now they feel that that model just does not fit their goals any longer. They definitely wanted a more controlled process. Here is my reproduction of a diagram that was presented to illustrate their internal development process for optimizations:
Basically, what this boils down to is a rigid set of guidelines that will force NVIDIA to make uniform decisions on driver optimizations. The Automatic Quality Check step involves hundreds of systems running various operating systems and many generations of NVIDIA hardware running an automated suite of tests. The Driver Validation System (DVS) automatically verifies that image quality is maintained. The guidelines that NVIDIA has set for optimizations are: 1) An optimization must produce the correct image, 2) An optimization must accelerate more than just a benchmark, and 3) An optimization must not contain pre-computed states.
Triantos also discussed NVIDIA's progress with their optimizing compiler. It was first introduced into the driver with the 44.12 release. One optimizing compiler is used for both Direct3D and OpenGL drivers. The goals of this compiler are to maintain high utilization of math units in shader and combiners, to minimize register usage, and to optimize program scheduling to hide latencies between shader and texture. To close this topic, I leave you with a picture of a slide that discloses the improvements introduced in the 50 series of drivers.
That pretty much sums up the major topics discussed during the first part of the day. Of course, the panel was deluged with questions as they presented their topics. That's what they asked for, and that's definitely what they got.
Disclosure: Bjorn3D review products are sometimes provided by the vendors who manufacture the hardware. Review samples are in some cases retained by the reviewer that reviews the product for further comparison to other similar products. Companies that buy ads on the site do not get any special treatment when it comes to reviews and any ad-sales are not connected to the reviews or the review scores.


