S3 Savage, MeTaL API

M

msxyz

Newcomer
While on a trip down memory lane, I bought off eBay a S3 Savage4 apparently manufactured by IBM and with a DVI connector (!) instead of the usual VGA. I happened to own a Savage board back in the days: it was a cheap, no brand adapter with a S4 Pro, which I remember fondly for the 'high resolution' texture pack that was available for Unreal Tournament.

While I'm waiting for this card to arrive, I dug out a working Socket 5 motherboard and I've built an improvised retro PC to test it. I'm installing a few games of the period, mostly based on the Unreal or Quake 3 engine, which this graphic processor really seems to handle at best.

I encountered a few games (mostly based on Unreal engine) which use the proprietary API called S3 MeTaL; I tried to Google some info on this API, but I didn't found anything useful; it was the API Savage owners had to use to see high res textures in UT (though it worked with OpenGL too) but I couldn't learn anything else. Was it another kind of OpenGL rip-off (like miniGL) to push developers to support specific cards?

Also, does anybody have info on this API, development documentations or a link to something remotely useful to learn a bit more about this obscure API? I think all the Savage boards (3D, 4 and 2000) supported this, so it should have exposed functions on par with DirectX6 or OpenGL 1.2, maybe a bit more considering it was built around the Savage processor.
 
thers no real reason to own one s3tc was later supported by all the other cards via Microsoft's DirectX 6.0 and OpenGL 1.3
although early geforces suffered from banding, but iirc rivatuner had an option to convert to dxt5
 
From what I remember, one of the biggest benefits from S3 MeTaL was in the Unreal-engine games on Savage 2000 since MeTaL could render the 3 layers of textures in one pass on Savage 2000.
 
I tried out UT99 with Metal and S3TC textures on Savage 2000. It runs very well. But if you enable the detail textures there is some stuttering.


And I did make a video of it too. ;) A couple of years ago I bought a VGA/DVI capture card and went nuts with my old card collection.
 
Davros said:
thers no real reason to own one s3tc was later supported by all the other cards via Microsoft's DirectX 6.0 and OpenGL 1.3
although early geforces suffered from banding, but iirc rivatuner had an option to convert to dxt5
Click to expand...
GeForce 1/2/3 suffered from a hardware bug (or was it a hack to circumvent s3 patent? I think s3 sued Nvidia back in the day over due royalties for implementing s3tc into NV1x) that affected specifically DXT1 textures. Certain NVidia drivers included a way to automatically convert all DXT1 textures into DXT3/5 but at the price of lost efficiency: a DXT3 texture takes twice the memory space of a DXT1 one, for the same size, because of the additional 4bpp alpha channel (DXT1 only allows 1 bit for masking)

swaaye said:
Useful reference for determining which Metal version to get. The links are broken unfortunately.
http://www.savagenews.com/drivers/s3/s3metal.php
I think the more interesting S3TC moments are the Unreal 1 and Quake 2 demos. More interesting curiosities anyway. The texture resolution in these is sometimes just incredible even today. And this is on an 8MB card.

http://hyper.dnsalias.net/files-demos.htm
http://www.hwfiles.it/download/scheda/739/quake-2-mappa-mondm2/

Click to expand...
Thanks. I think VIAArena still has some useful drivers to download or at least it used to. All Epic/Unreal games of the period included detail texturing which made the surfaces look more detailed than they appeared to be even with the default 256x256 textures. A shame this 'trick' isn't used more often. Nowadays we got normal maps everywhere in games but, yet, many surfaces are still a blurred mess when seen up close.
OpenGL guy said:
From what I remember, one of the biggest benefits from S3 MeTaL was in the Unreal-engine games on Savage 2000 since MeTaL could render the 3 layers of textures in one pass on Savage 2000.
Click to expand...
Wasn't that feature (quad texturing) also exposed in DirectX6 / OpenGL? Not many games used more than two textures per single pass and that's also part of the reason why the first Radeon was somehow under appreciated (now to mention that 3 textures are probably more useful once arithmetic operations like madd and lerp are available, which the Radeon supported but only starting from DirectX8)

swaaye said:
I tried out UT99 with Metal and S3TC textures on Savage 2000. It runs very well. But if you enable the detail textures there is some stuttering.

And I did make a video of it too. ;) A couple of years ago I bought a VGA/DVI capture card and went nuts with my old card collection.
Click to expand...
I wich I could have time for doing something like iXbit labs did 10 years ago, testing something like 100 video cards with many games to build the ONE benchmark reference to rule them all. :)

Thanks for the response guys; I still miss one thing to satisfy my curiosity: any doc, guide, reference explaining a bit in detail the MeTaL API, the calls, the functions would be appreciated. I have something similar for Glide and, of course, a vast reference for all thing DirectX starting from version 5 and OpenGL
 
msxyz said:
Wasn't that feature (quad texturing) also exposed in DirectX6 / OpenGL? Not many games used more than two textures per single pass and that's also part of the reason why the first Radeon was somehow under appreciated (now to mention that 3 textures are probably more useful once arithmetic operations like madd and lerp are available, which the Radeon supported but only starting from DirectX8)
Click to expand...
Yes, much to the dismay of the D3D team, quad texturing was exposed in the API. The issue is that the texture stages were not fully functional. I.e. stage 0 and 2 had all the different operations available, but 1 and 3 did not. That was fine for dual texturing, in which case you could process two pixels per clock, but was hell for quad texturing.
 
OpenGL guy said:
Yes, much to the dismay of the D3D team, quad texturing was exposed in the API. The issue is that the texture stages were not fully functional. I.e. stage 0 and 2 had all the different operations available, but 1 and 3 did not. That was fine for dual texturing, in which case you could process two pixels per clock, but was hell for quad texturing.
Click to expand...
Interesting. 'much to the dismay of the D3D team' and probably to any programmer who planned using quad texturing, unaware of the limits! :D

I never owned a Savage2000 (maybe one day I'll give in to nostalgia and search for a board on eBay) but I remember it was a strong performer with all the games of the period, especially using 32 bit color. If only S3 didn't insist on marketing as a T&L part, who knows... Another error was purchasing Diamond to cut out the OEM market, just like 3dfx did with STB! In both instances, the decision to compete in the retail market directly backfired on them and only helped NVidia to gain the prominence it still has today.

Speaking of T&L, since it appears you're knowledgeable, do you know what went wrong with the Savage 2000 T&L functionality?

Stiletto said:
For what it's worth, I think someday when we have all the information on the API it will turn out to effectively be a custom OpenGL extension.
Click to expand...
If that's the case, why S3 didn't expose it just like vendors usually do with OGL proprietary extension? Even S3 had some of these; one that still survives to this day is GL_S3_S3TC and many games based on the Quake III engine check for its presence (probably all those made before theGL_ARB_TEXTURE_COMPRESSION cap became popular/supported).

At any rate, if anyone still has a copy of the MeTaL SDK laying around in an old backup disc, I'll be glad to take a look into it! :smile:
 
msxyz said:
Interesting. 'much to the dismay of the D3D team' and probably to any programmer who planned using quad texturing, unaware of the limits! :D
Click to expand...
It wasn't really a problem for developers as the result had to be correct and there was no way to expose the odd functionality of the texture stages. D3D had a method where the application could query how many passes a particular state would take, but I don't recall that being helpful.

Speaking of T&L, since it appears you're knowledgeable, do you know what went wrong with the Savage 2000 T&L functionality?
Click to expand...
S3 had T&L, ATi had TCL... ;) There was a bug unfortunately.
 
msxyz said:
I never owned a Savage2000 (maybe one day I'll give in to nostalgia and search for a board on eBay) but I remember it was a strong performer with all the games of the period, especially using 32 bit color.
Click to expand...
I was fascinated with Savage 2000 too and so bought a Viper II to toy with. It's quirky. The drivers are awful (S3 standard) and the Viper II seems quite picky about the motherboard it's on. On a VIA MVP3 board, there was display corruption during boot and I couldn't get the drivers to work (locked up). On a 440BX board it seemed stable but when I quit a 3D app the GUI acceleration was often non-functional (extremely slow desktop).

I toyed with the T&L in Quake3 too. It can be enabled for OpenGL with a registry setting. There are frequent flashes of geometry corruption with it. It's also slower, at least on a PIII 1000.
http://www.youtube.com/watch?v=0Lupw__u9zY
 
OpenGL guy said:
S3 had T&L, ATi had TCL... ;) There was a bug unfortunately.
Click to expand...
Ouch! So the geometry corruption seen in several screenshots is the product of the hardware not culling undesired triangles correctly. I wonder why they never fixed it in a subsequent hardware respin. I understand that S3 rushed the Savage 2000 out of the door to compete with the GeForce. But was it, at the time, so crash strapped that it couldn't afford a new revise of the chip? It showed great potential and probably it would have been a capable contender against GeForce 2MX (driver issues notwithstanding).

swaaye said:
I was fascinated with Savage 2000 too and so bought a Viper II to toy with. It's quirky. The drivers are awful (S3 standard) and the Viper II seems quite picky about the motherboard it's on. On a VIA MVP3 board, there was display corruption during boot and I couldn't get the drivers to work (locked up). On a 440BX board it seemed stable but when I quit a 3D app the GUI acceleration was often non-functional (extremely slow desktop).

I toyed with the T&L in Quake3 too. It can be enabled for OpenGL with a registry setting. There are frequent flashes of geometry corruption with it. It's also slower, at least on a PIII 1000.
http://www.youtube.com/watch?v=0Lupw__u9zY
Click to expand...
I remember that the Savage4 I had at the time didn't like the MVP3 that was in my PC. The main board didn't last long either, so it could have been just a problem with a defective chip on it. I remember that I had to try several settings in the BIOS before the system could be defined as 'stable'.

The motherboard I'm currently using (bought after the one using the MVP3 died) has an ALI Aladdin V chipset and was rock solid.
 
Some juicy documents I've found: :D I've re-uploaded them if anyone is interested (link lasts 7 days):

http://www.fileconvoy.com/dfl.php?id=gbd90fde610f4f7b39993408200d2127f4528d7c3e

The .zip contains the Savage4 registers guide and hardware manual. The register guide is very interesting because it exposes the hardware capabilities in full detail: the 3D engine interface is described starting from page 187.

I gave a brief look at the register commands. There are two texture ports although it says nothing of the internal arrangement (1x2 or 1x1 with loopback), two programmable blending registers (I'm still trying to figure out the general equation used in the combiner) and the rest is just the typical DirectX6/OpenGL fixed function pipeline stuff.

There are some references to anti aliasing being supported (2x and 4x) in one register (Destination control register) of the 3D processor... No such references elsewhere (ie in the DAC control registers), leading me to believe this function was planned bu then left out.

I hope someone will appreciate this piece of historical info as I have :)
 
Have you considered developing a wrapper that logs MeTaL calls? Perhaps if a MeTaL API SDK cannot be acquired, maybe it can be reverse-engineered...
 
Stiletto said:
Have you considered developing a wrapper that logs MeTaL calls? Perhaps if a MeTaL API SDK cannot be acquired, maybe it can be reverse-engineered...
Click to expand...
That's beyond my capabilities!

Besides, with the hardware manual I think I have a better idea of what the chip could do. The HW interface seems straightforward enough. I'm still left to wonder how much the MeTaL API exposed of all this.

BTW, the board arrived but I didn't have the time to try it yet. I think it will have to wait till after the holidays. Oh, in the meantime, I found a great deal on a Savage2000; so tempting I couldn't resist... ;)
 
You must log in or register to reply here.

Similar threads

S
SDL_Gpu API, SDL 3.0 ... New cross-platform graphics API.
Replies
1
Views
1K
Lurkmass
L
T
FuryGPU - A full capable GPU implemented on FPGA
Replies
0
Views
973
TopSpoiler
T
D
The Silent Hand of Driver "Optimization" (spinoff)
2
Replies
31
Views
2K
DavidGraham
D
S
WebGPU
Replies
9
Views
3K
Scott_Arm
S
D
DX12, DX12U, DXR, API bias, and API evolution ..
2
Replies
37
Views
6K
Lurkmass
L
Back
Top