Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : 3DFX -- Ignore unavailable to you. Want to Upgrade?

To: Michael G. Potter who wrote (10949)	3/2/1999 5:07:00 PM
From: Synapsid	Respond to of 16960

Yeah, so far S3 has been doing a good job of obfuscating this fact and slapping "128-bit" all over it (which of course refers to some datapath in the chip - which is very arbitrary). Also, from a post on the S3 Yahoo thread, it appeared that the Savage4 only supports AGPx2 texturing and supports AGPx4 for I/O only, just like 3Dfx chips support AGPx1/2 (and the original Savage3D only supported AGPx1 texturing) -- this is highly speculative on my part. However one could argue that real world performance is more fundamental, and this will always ultimately reflect metrics such as AGP texturing and memory bandwidth. Of course, 3Dfx is at least as big an offender as anyone ("32-bit rendering" etc), although they haven't quite got away with it even in the popular press. Regarding S3's Microsoft-endorsed texture compression, anyone is free to implement it in hardware (only hardware implementions benefit) but I think it is not unlikely that it fits S3's architecture very well, while being a pain in the ass to implement into other architectures (such as NVIDIA's and 3Dfx's). I remember something about a "tile-based" architecture because pixels are compressed into 4x4 pixel rectangles (4 scanlines) as opposed to scanline-based.