New 3D Chips - Banshee, G200, RIVA TNT And Savage3D

NVIDIA RIVA TNT

When NVIDIA announced RIVA TNT at WINHEC this year, everybody was amazed about the huge numbers they were talking about. 250 Mtexels/s texel fill rate and 8 million triangles/s are numbers far beyond what any current 3D chip is able to provide. As time went by NVIDIA had to learn that those numbers will not be achieved this year anymore, because the huge 8 million transistors chip is getting too hot at 125 MHz clock as long as it's produced in 0.35 micron technology. Thus the claims from WINHEC won't be fulfilled before the shrunk to 0.25 micron has taken place, and nobody expects this to happen before 1999. Instead of this, NVIDIA is now talking of 180 Mtexels/s and 6 million triangles, due to a chip clock reduced down to 90 MHz.

The specs of TNT are still impressive enough though. TNT stands for `Twin Texel' and is supposed to point out that TNT has got two rendering pipelines that can work in parallel, equivalent to the two texelfx2 units in the Voodoo2 chipset. Each pipeline can produce one pixel per clock. Games like Quake2 or Unreal and many future games are using more than just one texture map. Quake 2 does e.g. have a texture map and then a lighting map as well, which both have to be taken into consideration when drawing a pixel. One pipeline has to first render the pixel using the texture map, then another time using the lighting map. The same is valid for bump mapping, where there is a texture map and an environment map that has to be put on top of each other. Two parallel pipelines can do both stages at the same time, thus increasing rendering performance. Voodoo (only on Quantum3D boards) and Voodoo2 were the first main stream 3D chipsets that could do this parallel rendering, TNT is now the next chip that provides this important feature. ATI's Rage128 and 3Dlabs' Permedia3 will follow soon.

6 million triangles sound impressive as well, but since there's no clear definition of triangle rates, it could be that this number is a bit on the high side. A high triangle rate is very important too nowadays, since only high polygon counts can make a scene look really detailed. E.g. a face of a player in Quake2 could look a lot better if it would consist of more polygons.

NVIDIA is also very proud on TNT's 2D engine and my results will show you that they've got all reasons to be. Other features like DVD support and such are not quite that important for the retail market and count mainly for OEMs really. ATI and S3 are making a big deal out of the missing `motion compensation' feature of TNT and Banshee, but this is only important to people who want to watch DVD on their computer monitor and who are using a weak CPU at the same time.

TNT was supposed to be the Voodoo2-killer in the first place, but it looks as if this will not quite be reached, since NVIDIA had to retract the originally claimed numbers. The claim that TNT will reach the performance of two Voodoo2 boards in SLI configuration is certainly more wishful thinking than anything else. Nevertheless does TNT have several serious benefits over Voodoo2 and even Voodoo2 SLI. First of all there is the 2x AGP interface, which can prove quite helpful for games that are using very large textures. Secondly can TNT display games at resolutions up to 1600x1200, Voodoo2 is limited to 800x600 and Voodoo2 SLI is limited to 1024x768. TNT has got a 24 bit Z-buffer that provides more accuracy than the 16 bit Z-buffer of Voodoo2 and TNT is able to do 32 bit color rendering ... something that Voodoo2 is also not able to do.

What we should expect from TNT is very good 3D performance, close to Voodoo2 performance, excellent image quality, excellent 2D performance and quality (internal 250 MHz RAMDAC) and high resolution support in 3D. Most of those expectations will become satisfied....

S3 Savage3D

`Voodoo2 performance at S3 prices' is the slogan for the Savage3D and after I first opposed to that opinion I've now got to seriously consider it. However, there still are quite a few unanswered questions. First of all it's true, Savage3D is performing very well in the benchmarks. It surpasses Voodoo2 and scores pretty much the same as Banshee does. In games that use multi-texturing the Voodoo2 can show its muscles though, since the Savage3D doesn't have a second texture unit as well as Banshee. All in all the benchmark results are very close to Banshee, sometimes a bit faster, sometimes a bit slower. From that point of view there is all reasons to congratulate S3 for their new chip.

However , there are a whole lot of issues that remain unsolved or need to be discussed still though.

S3 Savage3D - Quake 2

The bug I found in Quake 2 was a major thing to me as a Quake 2 player. Several maps in Quake 2 have some kind of window screens, where you can look through and see if your opponent is there on the other side of that glass screen. Well-known maps with that are e.g. `The Frag Pipe' and `Sudden Death'. When you see your opponent in the other room, you can jump on a button and flood this room with lava, thus killing your opponent who loses a frag this way. The first two drivers I got from S3 wouldn't let you look through the screen, the windows appeared as opaque white boxes with some textures on it. The latest driver I received partly solves this problem, but you've still got a hard time recognizing anything behind the glass.

Unfortunately, when rushing out the new driver, the S3 testing team overlooked a new bug, which makes the game even less playable now. You haven't got a cross hair anymore. Now I may not be Thresh, but I think that most Q2 players will have a serious problem without a cross hair.

S3 will certainly be able to sort out this bug as well, but it's another proof that the Savage3D drivers are not mature yet. I really wonder what driver Hercules is planning to ship with their Savage3D cards this week.

Last but not least there is a serious gamma problem with Savage3D in Quake 2. The light seems to flicker, depending on which direction you look at. Most of the time it's horribly dark, but then suddenly everything gets brighter for a moment.

Download 640x480 BMP file (900kB)
No crosshair and hardly transparent screens - that's Quake 2 with the Savage3D.

Download 640x480 BMP file (900kB)
Crosshair is where it belongs and you can look through the screen just fine - Quake 2 with the G200.

S3 Savage3D - Quake 2 Map `NEWS3'

This Quake 2 map was developed by S3 to show the advantage of texture compression used by Savage3D. It uses a huge amount of textures, so that only cards that can do at least AGP texturing are able to run it at a reasonable speed. This means that cards with 3Dfx chips cannot really be used very well with this map, Matrox' G200 with its AGP 2x support is looking a lot better than Voodoo2 and Banshee, but Savage3D easily beats them all. The only problem with Savage 3D is that you need to enable the registry setting `AA', standing for `auto-AGP'. That wouldn't be too bad, but e.g. Turok runs slower with this setting enabled. I wonder how this issue is supposed to be solved. You cannot be asked to change registry settings for each game.

S3 Savage3D - AGP

S3 claims that Savage3D has full AGP 2x support. You know how highly I rate this feature, but if something is used for marketing I may be allowed to check it as well. Final Reality has a nice AGP benchmark built in, which lets you check the AGP transfer performance of an AGP board. Banshee naturally sucks at this feature, because it hasn't got a real AGP implementation altogether. G200 with its AGP 2x support scores a fine 76 fps whilst Savage3D only scores 23 fps. This doesn't look like a good AGP 2x implementation at all. After enabling the `AC' or `auto compression' registry setting, which forces all used textures to be compressed, the result quadruples to 96. This is not surprising because the textures get compressed 4:1, which is almost exactly the increase we are getting here. S3 told me that Savage3D has definitely got an AGP 2x implementation, but the results I'm seeing speak a different language. Intel's performance tool IBASES shows exactly the same result, G200 scores more than 6 times as high as Savage3D.

S3 Savage3D - Sin

Ritual's upcoming new game that's based on the Quake 2 engine should normally run with the Q2 wrapper as well. However the first two drivers wouldn't let me run Sin in OpenGL mode at all and the new driver I've got run's Sin horribly slow for a short while before the game simply crashes. I may ask what Hercules is going to tell their customers who want to play Sin after they bought a Savage3D board next week.

S3 Savage3D - Chip Clock

When playing a game I came across several triangle drawing errors. This effect is well known to all Voodoo users who overclocked their cards. It seems as if the Savage3D chip with its 125 MHz clock frequency is close to being overclocked. This issue will most likely be solved in the future and the Hercules cards that are supposed to ship this week are only running at 110 MHz and thus won't have this problem.

S3 Savage3D - Texture Compression And Benchmarking

Whilst all the current D3D games only run with texture compression when forced to do so by the `AC' registry setting, Quake 2 is always using texture compression because the OpenGL/D3D wrapper enables it permanently. This leads to quite a few unusual situations. Before you are running a map for the first time, all the static textures of this map are compressed and stored onto the hard drive in the subdirectory `S3tex'. The compression of all those textures can take up to 5 minutes, particularly in case of big 64 player maps. You also have to be aware that quite a huge amount of hard drive space is needed for that. Once the map has been ran once, this compression doesn't take place anymore and the map starts straight away. Now there aren't only static textures in games but also so called dynamic textures, which are produced all of the time, depending where you are walking around in the sewer and what you are looking at. Those textures are compressed on the fly while you play the game. The effect of this is that a benchmark always gets faster after each run, because more and more of those dynamical textures are somewhere in the memory cache of the system. A benchmark runs always the same route through a sewer, so the dynamic textures are always the same. The problem is, that in actual game play you hardly ever walk the exact same route twice. Thus different new dynamic textures are produced all of the time. The result of this situation is that actual game play does never run as smoothly as the frame rates scored after several benchmark runs would make you expect. I have yet to still test this issue, but I had the feeling that in actual Q2 game play the card occurred a lot slower than the high frame rates would suggest. It is very difficult to quantify this though.

I would like to give an example on how the frame rate results change when running the demo several times: 64-65-69-71 fps in the 1st , 2nd , 3rd and 4th run of the mon2.dm2 demo in Quake 2 at 640x480. This does not happen with any other graphics card and is clearly explained by the dynamic textures issue.

S3 Savage3D - Questionable Registry Settings

I have never come across as many different registry settings as in the Savage3D driver. Some of them occur a bit strange and can impact benchmarking by a considerable amount. The number one topic is the `AC' setting. It forces texture compression for any game that's run. Texture compression can degrade the image quality, which is why game developer are strongly against this feature, as you can read in those 8 voices from the 3D game developing industry. Enabling `AC' leads to better benchmark results of course and how many reviewers take the time to look at what the game benchmark looks like? Another setting is `AT', which means `auto-mipmapping'. This feature is well known from NVIDIA's RIVA 128 driver and widely disapproved. It causes strange artifacts and thus also degrades image quality. S3 states that they are not planning on enabling these features in any of their drivers, but one may wonder what those settings are there for in the first place. It gives an easy tool to OEMs for scoring very well in benchmarks, while degrading image quality. Last but not least is there a setting called `FD', which improves the performance in Incoming. I haven't got a clue what it does though.

I hope you can appreciate that there are two reasons for being so critical at the Savage3D. The one reason is that the first Savage3D boards are supposed to ship soon. This seems too early to me. The other reason is that a few claims of S3 don't seem to be met. The AGP performance is below par and the issue with the `auto' registry settings could be used as a tool to only reach high benchmark results. Last but not least is there a possible divergence between benchmark results and actual game play, also generated by texture compression.

Benchmark Setup

The benchmarks were run in the following configuration:

• Asus P2B motherboard w/ Intel 440BX chipset
• 
  Adaptec 2940UW SCSI host adapter
  IBM DGVS 09U SCSI hard drive
  64 MB LGS PC-100 SDRAM DIMM
  Intel Pentium II 400 and Celeron 266 CPU
  Windows 98 operating system
  DirectX 6 final release
• 3Dfx Voodoo Banshee driver:
• 
  4.10.01.0090-1.00
  "Flip on Vsync disabled"
• Matrox Millennium G200 driver:
• 
  4.10.01.4140
  "Flip on Vsync disabled"
• NVIDIA RIVA TNT reference driver:
• 
  4.10.01.0032
  "Flip on Vsync disabled"
  Chip clock 95 MHz
  Memory Clock 112.5 MHz
  Used RAM Type: SGRAM
• Savage3D driver:
• 
  4.10.01.4000-6.00.20B
  Registry settings:
  AA on
  AC off
  AM off
  AT off
  VO off
  WE on
  WV off
  "Flip on Vsync disabled, automatic texture compression disabled"
• All games run in 16 bit color mode.
• Winstone 98 ran at 1024x768, 85 Hz refresh rate.