Original Link: https://www.anandtech.com/show/410
S3 Savage 2000 (Diamond Viper II)
by Anand Lal Shimpi on November 18, 1999 10:46 PM EST- Posted in
- GPUs
For the past two product releases, S3 has done very little to offer the market a competitive solution.
Many were surprised when S3 introduced the Savage 3D back in 1998 at the E3 Expo in Atlanta. We had all assumed that S3 had resigned from the market after a dying reign in the early 90’s. The Savage 3D was the first consumer/gaming level graphics accelerator that had addressed the topic of possibly using a virtually lossless texture compression algorithm in order to address the issue of memory bandwidth effecting texture resolutions and complexity. On paper, and even in the first few trials, the Savage 3D seemed like a true winner -- a potential candidate for the "Voodoo2 killer" throne that the video market had so intently sought out. Unfortunately, the final shipping product was nothing more than a buggy disappointment. Poor drivers resulting in poor compatibility and poor performance (notice a trend?) left the Savage 3D as one of the most dreaded video cards to own. Only Hercules, a company that no longer exists in the same form that they once did, was able to make a decent Savage 3D card, but only after hand picking the chips they would use on their boards and running extensive tests on their products before finally allowing them into the hands of the consumers. No other manufacturer would even dream of spending so much time and effort on offering a single video chipset, and thus most manufacturers dropped their Savage 3D products, including Diamond Multimedia, a name that would later hold much significance for the company.
Then came the Savage4 in 1999, just about an entire year after the release of the Savage 3D, and the market wondered if we were due for another unpleasant surprise from the once dominant S3. The specs were released and they weren’t too disappointing at all, so we all wondered if maybe S3 did manage to get their act together. The initial benchmarks looked solid, the performance of the chipset was much improved over the old Savage3D and most of the bugs the original solution were fixed in the Savage4. A key sign of improvement was in the fact that Diamond Multimedia, a major player that had dropped their original Savage 3D product, was now supporting the Savage4.
The Savage4 ended up being a pretty good OEM solution because it was inexpensive and it worked, but, for the hardcore gamer and performance enthusiast, the chip was not a viable solution at all. The driver problems were still there. Later updates helped correct some of the original problems, but the chip itself really didn’t offer much over the competition other than a low price, which was being threatened by low end parts from NVIDIA and 3dfx that were in the works.
Recently, with the acquisition of Diamond Multimedia, a key player in the company’s history, information about the Savage 2000 chipset has surfaced. And now, just a week away from the availability of retail Diamond Viper II boards based on the Savage 2000 chipset, we are able to take a look at a final production board and compare it to NVIDIA’s greatest as well as the best of the rest out there. While it has often been said that the third time is the charm, that doesn’t seem to be the case with the Savage 2000.
The initial specs of the chipset indicated a 700 megatexels per second fill rate, which would put its theoretical fill rate a full 45% above that of NVIDIA’s recently released GeForce 256 (480 megatexels/s for the GeForce). At the same time, the Savage 2000 was to be the second consumer level graphics chipset of this generation to feature an on-board hardware transform and lighting engine that would help to off-load some of the transform and lighting calculations from the CPU and onto the graphics card. Once again, the product, on paper, appeared to be a very capable competitor.
On Paper
Since the initial 700 megatexels/s number was released, it has since been amended by S3 to read "up to 700 megatexels/s" with the actual product falling in at 500 megatexels/s, just slightly above the performance of the GeForce 256, on paper. The Savage 2000 architecture is quite flexible in terms of what it can do with that fill rate. The actual clock speed of the core is 125MHz, meaning that the 500 megatexels/s number is obtained by quadrupling that clock speed, meaning that the chip itself is capable of processing four texels per pass. The QuadTexture Engine allows the Savage 2000 to apply four textures to a single pixel, as the name implies, or two textures to two pixels.
This is in contrast to the GeForce 256 which is capable of processing four single textured pixels or two double textured pixels per pass. The only advantage the Savage 2000 has here is that it can do a single pass quad textured pixel, whereas the GeForce 256 can only do a single pass on a dual textured pixel.
While, on paper, this may make a difference, it shouldn’t make any difference in real world gaming. The reason behind this is that although a Savage 2000 can do a single quad textured pixel in one pass, the GeForce 256 can do two dual textured pixels in one pass and thus with another pass it can apply four textures to those two pixels. This means that in two passes, the Savage 2000 can do two quad textured pixels and so can the GeForce 256. In essence, the QuadTexture engine is nothing special and mostly a marketing term.
The disadvantage, however, comes in single texture games where the Savage 2000 cannot process four single textured pixels per clock, while the GeForce and other cards can. This isn't such a big deal any more because the days of the single textured game are numbered. In fact, most games that are simple enough that performance will generally not be an issue on a card like this.
The Savage 2000 offers, like its competitors, a 128-bit memory bus that operated at 155MHz. The 155MHz frequency is sort of an odd choice, because 7ns memory guarantees 143MHz operation and 6ns memory guarantees 166MHz operation, making 155MHz somewhat high for qualification with 7ns chips and below the 166MHz rating of 6ns chips. The only reasonable explanation for this frequency rating is that S3 anticipated that board manufacturers (specifically Diamond, since very few others have actually talked about Savage 2000 products) would be using 6.5ns/153MHz memory. In any case, the 155MHz memory frequency is noticeably lower than the 166MHz rated frequency of the memory on GeForce boards, putting the available bandwidth at 2.5GB/s on the Savage 2000 versus the 2.65GB/s on the GeForce. The thing to keep in mind is that, in spite of this limitation, the board will most likely ship with at least 6ns memory and will thus allow you to overclock to 166MHz and beyond since memory chips are rated quite leniently.
As we mentioned earlier, the Savage 2000 features an on-board hardware transform and lighting engine known as S3TL. The engine is supposed to be simpler than that found in NVIDIA’s GeForce, but S3 has been claiming that it is just as capable. In spite of this, the Savage 2000 features about half of the amount of transistors of the GeForce (12 million vs 23 million) and with almost identical chips, it leads one to wonder why S3TL can supposedly do just as much as the GeForce’s T&L without the chip being nearly as complex as the GeForce.
The Savage 2000 still offers support for S3TC, the texture compression algorithm S3 has been using since the introduction of their Savage 3D. Support for S3TC has definitely increased but it is still far away from full acceptance. At the time of publication, S3 had a Quake 3 level that took advantage of S3TC; however, due to the fact that the full game has not been released yet, they were unable to show it off. Upon the release of Quake 3 Arena, expect to see this impressive level. Some games are offering S3TC support, like Q3A, not to offer different textures but faster performance using the higher resolution textures.
0.18-micron & Overclocking
Unlike the competition, S3 is producing the Savage 2000 on a 0.18-micron fabrication process. NVIDIA is using a 0.22-micron process with their GeForce and 3dfx is making use of an enhanced 0.25-micron process. So, how is it that S3 can be at 0.18-micron while the two competitors arent?
It turns out that S3s Savage 2000 isnt completely 0.18-micron, rather a hybrid 0.18/0.22 micron solution. The move to true 0.18-micron will eventually occur, but for now only the transistors on the Savage 2000 are based on the 0.18-micron process, the rest of the chip is 0.22-micron. According to S3/Diamond, this hybrid technology has no downsides, but it seems odd that the hybrid construction would be just as good as a true 0.18-micron solution.
Because at least the transistors of the chip are based on the 0.18-micron design, it is very likely that the Savage 2000 will be a pretty good overclocker. The Diamond Viper II, the first Savage 2000 based video card, ships without a fan because of this. Adding a fan would probably allow for a fairly successful overclock on the Savage 2000 chip itself. Dont expect anything like a 125MHz to a 200MHz overclock, but reaching at least 150MHz shouldnt be a difficult task to accomplish. Unfortunately, at the time of publication, the only overclocking utility we had was built into the InControl Tools 99, which did not report the overclocked frequencies. We can only assume, judging by the way the Viper V770 Ultra's InControl Tools 99 worked, that each "Turbo Boost" setting increased the core frequency by 5MHz. At boost level 5 (or 150MHz core, the memory frequency is not adjusted) our Viper II crashed after a few timedemo runs, but adding a fan onto the heatsink that covered the Savage 2000 eliminated that problem. Boost level 4 (145MHz) ran perfectly fine without any added cooling.
Our Diamond Viper II sample featured 6ns SDRAM which would allow for a 166MHz memory clock (equal to that of the GeForce, but above the 155MHz rating of the board). From our experience with the memory in specific, it wouldnt be absurd to be able to hit ~170MHz with the memory. Once again, we did not have an overclocking utility capable of pushing the memory frequency, but, in the future, one should be available.
Drivers
While we secretly hoped that S3 would get their act together with the Savage 2000s drivers, we did expect them to have some problems. The drivers themselves are much better than we expected, but they do have their bugs. The drivers we used were the latest available and were dated 11/11/99, and they will be the shipping drivers.
A problem we have noticed in virtually every product from S3 since the Savage 3D is the incredible tearing effect when V-Sync is turned off. The problem is present with the Savage 2000s drivers, but seems to be worst when in a games menu or in timedemo mode. During normal gameplay, the tearing isnt too bad but it is definitely present.
The board ships in AGP 1X/2X mode, like the Viper V770 Ultra, and, in order to enable AGP 4X, the three jumpers on the Diamonds Viper II must be capped (they ship in the open position). This will, of course, vary from board to board, but since the Diamond board is the only available Savage 2000 board on the market we decided to include this note.
The shipping drivers are DirectX 6.0 drivers and thus wont feature hardware T&L for Direct3D games. Luckily there are no currently available D3D titles that take advantage of hardware T&L, so you dont have to worry too much there. While we were hoping that hardware T&L would be enabled in OpenGL, where it would be taken advantage of in Quake 3 (at least the hardware lighting part of S3TL), the shipping drivers do not take advantage of the Savage 2000s Hardware T&L (S3TL).
We have taken a look at their DirectX 7.0 drivers and they are coming along, but they are not nearly shipping quality. It looks like drivers will be another limitation of the Savage 2000.
The Test
Windows 98 SE Test System |
||||
Hardware |
||||
CPU(s) |
Intel Pentium III 733EB |
Intel Pentium III 600E | AMD Athlon 700 | |
Motherboard(s) | Intel VC820 | ABIT BF6 | ASUS K7M 1.04 | |
Memory | 128MB Samsung PC800 RDRAM |
128MB PC133 Corsair SDRAM |
||
Hard Drive | IBM Deskstar 22GXP 22GB Ultra ATA 66 HDD |
|||
CDROM | Phillips 48X |
|||
Video Card(s) | 3dfx Voodoo3 3500TV |
|||
Ethernet | Linksys LNE100TX 100Mbit PCI Ethernet Adapter |
|||
Software |
||||
Operating System |
Windows 98 SE |
|||
Video Drivers |
|
|||
|
||||
|
||||
|
4.11.01.9000-9.00.23 |
|||
Benchmarking Applications |
||||
Business |
Ziff Davis Winstone 99 |
|||
Gaming | idSoftware Quake 3 Test 1.08 (OpenGL) |
Testing at 640 x 480 with a next-generation video card provides two pieces of information: (1) relative performance of different CPUs and (2) the quality of the drivers for a particular video card. Here the Savage 2000 (Viper II) remains on the heels of the GeForce 256 (SDR) which is to be expected. The higher fill rate of the Savage 2000 should theoretically put it above the GeForce 256, but the card is beginning to show the limitations of its drivers.
The Savage 2000, in spite of its 155MHz memory clock, managed to outpace the GeForce 256 in the memory bandwidth dependent 32-bit color tests. The reason behind this is because the current Savage 2000 drivers only support a 16-bit Z-Buffer while the GeForce 256 is using a 32-bit Z-Buffer in this test. The 32-bit Z-Buffer used on the GeForce eats up some of that precious memory bandwidth while offering a small improvement in visual quality and thus the Savage 2000 comes out ahead. You can't really penalize S3 here because the sacrifice in visual quality is minimal for a decent gain in performance.
The GeForce architecture is the one limiting factor in that it only supports a 32-bit Z-buffer when running in 32-bit color modes while all of the other cards can choose between 16 and 32-bit Z-buffer modes.
The performance standings remain the same, with the GeForce at the top by a decent margin. With some improving, the Savage 2000's drivers could put the chip on a level closer to that of the GeForce, if not faster than it. The 32-bit color performance of the Savage 2000 is once again considerably higher than the GeForce because of the GeForce's inability to run using a 16-bit Z-buffer in 32-bit color modes.
Once again, the standings remain the same, even at 1024 x 768, with the Savage 2000 noticeably slower than the GeForce 256 in 16-bit color. In fact, the Savage 2000 is only about 5 fps faster than the G400MAX, a "previous generation" card. The 32-bit performance of the Savage 2000 is still above the competition but keep those two scores in mind as you watch the performance of the Savage 2000 on the other three CPUs we tested on. It seems like we're seeing the beginnings of the limits of the Savage 2000. Not a very refreshing thought. However, the performance here is respectable.
Resetting the resolution to 640 x 480, this time on the "slower" Pentium III 600E on a AGP 2X BX platform results in a similar conclusion to our previous one: with better drivers the Savage 2000 should be able to surpass the GeForce 256 in performance. Whether or not that will happen is another question, but the performance here is respectable in that the Savage 2000 is faster than the rest of the cards but it is disappointing because the chip still falls behind the GeForce in performance.
Once the resolution increases, the Savage 2000 drops to well below the performance of the GeForce 256 in 16-bit color. The Savage 2000 pulls ahead once again in 32-bit color because of the greater available memory bandwidth, courtesy of its use of only a 16-bit Z-buffer in the test versus the GeForce's 32-bit Z.
At 1024 x 768, the Savage 2000 brings forth the same scores with a Pentium III 600E that it did with the 733. What does this mean? When an increase in CPU speed results in no increase in gaming performance the usual cause is that the graphics card is already hitting its peak performance. In this case we'll hope that the Savage 2000 isn't already hitting its performance limits and this will be corrected by updated drivers. But at the same time, remember that the Savage 3D and Savage 4 both exhibited a very similar trend in their performance where they maxed out long before they theoretically should have.
The "slower" Pentium III 450 CPU brings the scores of the 9 test cards very close to one another, more specifically, within about a 20 fps range. The Savage 2000 is still faster than the rest of the competition but it continues to take a second place to the GeForce 256.
This test is the first at 800 x 600 where the Savage 2000 did not outperform the GeForce 256 in the 32-bit color test. It comes close but barely makes it. The general breakdown of performance here doesn't change much from the previous tests, but the range of frame rates increases from the ~20fps found at 640 x 480 to around 30fps.
The Savage 2000 isn't able to reach its previous limit of 60 fps at 1024 x 768 x 16-bit when set up with the Pentium III 450, which is pretty disappointing considering the Matrox G400MAX and TNT2 Ultra are less than 10 fps away from the Savage 2000 in 16-bit performance. The only savior for the Savage 2000 here is its 32-bit performance, which is greater than all of the competition.
The performance of the Savage 2000 with the Athlon 700 mimics its performance on the Pentium III 733, close to the GeForce 256, but just not close enough.
Yet again, the increase in resolution pushes the Savage 2000 back down virtually to the level of a previous generation product, being only a few fps faster than the G400MAX. The only saving quality is its 32-bit color performance using a 16-bit Z-buffer. Keep in mind that Matrox's G400 drivers don't force a 32-bit Z either and the Savage 2000 still outpaces it by over 10 fps.
Here we see that same 60/55.4 fps limitation of the Savage 2000. Let's hope, for S3's sake, that this is an issue with immature drivers and not a limitation of the chip itself.
If 640 x 480 is an indication of how well the drivers of a particular video card were written, then the Savage 2000 has by far the worst set of Direct3D drivers present among these nine cards. The higher fill rate of the Savage 2000 doesn't seem to matter at all as the drivers hold the card back to a meager 65fps. It seems like S3 focused on their OpenGL ICD too much and let their Direct3D performance suffer as a result.
Upping the resolution to 800 x 600 doesn't help prove the Savage 2000's performance level as the drivers are still a major limitation. The 32-bit performance of the card is pretty high, but unfortunately the full potential of the card is not illustrated here.
At 1024 x 768, where fill rate and raw power become more evident and drivers less of a limitation the Savage 2000 pulls ahead of the first half of the competition only to be put to rest by the G400MAX. The 32-bit performance of the Savage 2000 is still superior to that of the GeForce although it takes a backseat to the 200MHz memory bus of the G400MAX and its resulting stellar 32-bit performance.
Once again, the drivers are the death of the Savage 2000 in the 640 x 480 tests. The performance isn't even worth analyzing.
The 32-bit performance is getting more competitive here, but still not a "next-generation" level of performance from the Savage 2000.
Again, with drivers as less of a limitation, the Savage 2000 pulls ahead of the first half of the competition. The 32-bit performance, this time around, is the fastest out of the bunch, even outpacing that of the G400MAX. It seems like the 32-bit performance of the Savage 2000 could be a definite strength; unfortunately, it is masked by the poor performance of its immature drivers.
Look familiar?
This time, with the Pentium III 450, the Savage 2000 isn't even able to pull up its performance rank at all. Very disappointing and unfortunately we won't see a change until S3 does something with their drivers. Keep in mind that these are shipping drivers.
Final Words
If the Savage 2000 were months away and this was the current level of performance the product was at, then the solution would be promising. But the reality of the matter is that in less than a week, you'll be able to purchase this very same product on the Diamond Viper II for around $200 and you will be given this level of performance. In OpenGL, the performance isn't bad at all, although it could definitely be improved. Under Direct3D, the performance is truly lack luster and is indicative of poorly written drivers, a problem that has plagued S3 ever since the release of their Savage 3D in 1998.
S3 has really tried hard to make the Savage 2000 a success and in time we're sure that they will be able to improve on the problems we encountered during our testing, but at this time we simply cannot recommend the solution until the drivers have improved.
On the bright side, if S3 does get their act together and produces some better drivers, there are a few things to look forward to with the Savage 2000. The 32-bit performance of the chip is undeniably quite competitive, as is the performance of its OpenGL ICD. In theory the Savage 2000 should be able to outperform the GeForce due to its faster raw fill rate, it would be nice to actually see that theory represented in the benchmarks with better drivers.
Overall, the performance of the card can definitely be improved with some better drivers, and enabling S3TL (hardware T&L) in the drivers will yield another performance boost that should make the Savage 2000 a much more competitive solution. Until then, keep an eye on the Savage 2000 because it could definitely become an affordable GeForce alternative, but for now, it's not something you'll want to go out and purchase.