The Talisman moniker is Microsoft marketing spin at its best. A term meant to connote protection from negative forces is now used to convey the company's intention to do harm unto others. But the problem with messing with the occult, as any "Friday, the 13th" TV show viewer knows, is that it usually backfires.

When last we looked at MS Talisman, it appeared like Microsoft was on a 3-D roll. Chip vendors like Samsung, Cirrus Logic, Fujitsu, and others had all publicly pledged Talisman hardware support. But in the short time since that article first appeared, Samsung yanked the plug on its joint effort with 3DO to produce the Media Signal Processor, a DSP-like chip. The MSP was originally at the heart of the Talisman reference board, code-named "Escalante." And then Cirrus Logic, one of the principal makers of Talisman's unique VLSI chips, suddenly pulled out of the deal.

These key silicon defections subsequently forced Microsoft to cancel its plans to roll out the Escalante board earlier this year. However, this cancellation signaled much more than just a simple shipping delay. Actually, the entire Talisman effort looked dead in the water. And what probably killed it was Microsoft's naive belief in its own invincible power. Redmond truly believed it could get four highly competitive semiconductor companies (Philips, Samsung, Cirrus Logic, and Fujitsu) all dancing in sync to its frenetic 3-D drumming.

But just when all seemed lost, a re-animated Talisman suddenly sprang back to 3-D life. Moreover, it seemed to be promising a breakthrough in 3-D hardware price/performance. For example, Trident Microsystems (Mountain View, CA) a 3-D semiconductor company, subsequently announced plans for its new Talisman chip set.

Significantly, unlike the original multi-chip implementation, the Trident Talisman was to be all on a single piece of silicon. In addition, Fujitsu, one of the primary players in the original multi-chip Talisman reference spec, has also indicated that it was throwing its hat into the single chip ring. And even Cirrus Logic has seemed to be shrugging of its Talisman malaise, giving off smoke signals of its own impending one-chip Talisman design. So once again, MS Talisman might have the power to do significant harm to others in the PC 3-D market.

Given that these industry reports are accurate, reducing Talisman to a single slice of silicon costing from $20 to $50 is no mean feat. Talisman was a highly complex system encompassing a DSP-like chip, a Polygon Object processor VLSI chip, an Image Layer Compositor VLSI chip, a Composition Buffer, a media DAC, MPEG-2 decoding, an AC3 (surround sound) audio chip, and a couple of Rambus memory devices. Moreover, instead of a bill of materials of several hundred dollars, these new one-chip Talisman boards would cost less than $100 to make.

At first blush, the newly reborn Talisman PR seemed to ring true. For example, Trident said that its new single chip implementation would implement the image-chunks-manipulated-as-objects specified by Talisman. The original Microsoft spec called for logically carving up an image into 32 x 32 bit "chunks. After the images were carved up into 32 x 32 pixel pieces, each chunked object was placed in an appropriate image layer. This technique yielded multiple image layers, with each layer possessing multiple image object chunks. Every image layer was then manipulated individually, with each object chunk described and manipulated via Microsoft's DirectDraw and Direct3D APIs. Talisman was also a time-based system. If nothing changed to an image chunk in the next pass, then nothing was rendered.

By eliminating the need to continually process the entire image, processor overhead was cut way down. Thus, Talisman sought to make 3-D image processing smarter, as opposed to applying brute force methods, such as using more MIPS, increasing bandwidth, or adding more graphics pipelines. In addition to chunking support, Trident also says that it is implementing Talisman's 3-D notions about texture compression, z-buffering bump mapping, and anisotropic filtering. As icing on the Trident/Talisman cake, 2-D acceleration, and MPEG-2 decompression are also thrown in.

But conspicuously absent in the Trident implementation is Rambus memory support. Instead we find double data rate SDRAMS and SGRAMS. This omission is a major slap in Talisman's face. Rambus was a significant element in Microsoft's original Talisman architecture. In fact, Microsoft made it the cornerstone of the system design, as the company flat out stated that conventional memory speeds were in no way going to keep up with 3-D PC graphics requirements.

MS Talisman specified the use of 4 Mbytes of shared Rambus RDRAM, and two, 600 MHz, 8-bit Rambus image data channels This unusual memory/image processor configuration yielded a throughput of 1.2 Gbyte/Sec, with the shared Rambus memory holding the data during image processing. In this way, Microsoft planned to eliminate the traditional 3-D graphics pipeline. The Talisman hardware design did not use frame buffers in the usual sense because, "instead," said Microsoft, "multiple image layers were composited together at video rates to create the video output signal."

Obviously, the Rambus-centric Talisman was radically different from a conventional 3D graphics system with its typical pipelined architecture. And since all other competing 3-D APIs presumed pipelines, this feature omission was no small deal from a market competition perspective. But Trident's lack of Rambus support is an important tip-off for something else -- Talisman's pipeline-less approach has also gone by the boards. Although Trident didn't explicitly say so, the tried and true 3-D pipeline has reappeared. We know this because in addition to supporting MS Direct3D, Trident also supports OpenGL, a competing 2-D, 3-D API which defines a graphics pipeline.

To have undergone such a drastic revamping, Talisman must have had some serious design problems. In fact, a Trident spokesperson said that "many things were badly wrong with the original architecture." And so, Trident/Talisman hardware ends up having almost nothing to do with Microsoft's original 3-D vision. Rather, the Trident/Talisman chip is simply a powerful new 3-D graphics chip, with some multimedia capabilities. This twice told, much rehashed Talisman tale is going to become increasingly common, as Microsoft has started a new multi-tier Talisman licensing plan.

For example, a licensee can pay just to get a complete description of the Talisman algorithms and driver model. At this upper level, licensees like S3 and ATI Technologies are probably just choosing those Talisman elements they consider interesting. At the deeper level, companies like Trident have licensed everything from Microsoft, including full access to the Talisman C source code simulator and the Verilog models.

What's happening, therefore, is that the 3-D semi vendors are picking over the carcass of the original Talisman design, and merely using those features which best suit their own business purposes. So what will it mean, exactly, when a 3-D vendor says it's making "Talisman" parts? It's anybody's guess. But there is no guessing that this broad brush use of the Talisman name will cause mass user confusion in the PC 3-D market. However, all this new Talisman confusion will serve one excellent business purpose. It will help rekindle Microsoft's hocus-pocus efforts at killing off all competing 3-D APIs, and in particular, Open GL (developed and openly licensed by 3-D system vendor Silicon Graphics.)

We saw that the original Talisman hardware used no graphics pipeline. But Open GL API, as do all other commercial APIs in the known 3-D universe, presume such a feature. Thus, it would have been well nigh impossible for this or any other competing API to have been supported on the original Talisman hardware. In reality, Talisman was meant to be an API buster, clearing a path for MS Direct3D. If the original Talisman hardware reference had somehow gone forward and been widely adopted by the industry, Microsoft would have effectively wiped out Open GL, and all its kinsman. So Talisman was very scary, indeed. As it is, the FUD factor created by NT and Talisman has already slowed down many low end Silicon Graphics purchase decisions.

As to why Microsoft is going to such great lengths to kill off competing 3-D APIs, you need to know some things about this market. Up until recently, the PC 3-D business was pretty evenly divided. Almost universally, third party 3-D graphics boards and applications above $1,000 featured OpenGL support (and probably Heidi, Autodesk's API). But at the lower price points -- i.e., the commodity PC board business -- other APIs, like MS Direct3D, were typically used. The lack of commodity priced Open GL support was purely a function of price/performance. OpenGL really sucks up the 3-D processing juice.

Last year, it was rare, if not impossible, to find a competent 3-D board supporting Open GL that retailed for less than $1,000. But in 1997, high performance 3-D boards with Open GL support costing less than $300 are starting to appear. For example, Diamond Technology's "Monster 3D" card uses the "Voodoo Rush" 3D accelerator chip made by 3Dfx. Offering a seamless interface to compatible 2D accelerators, the Voodoo chip set sports 45 Mpixels/sec sustained fill rate for bi-linear or tri-linear filtered textures with LOD MIP-mapping, Z-buffering, alpha-blending and fogging. Importantly, this voodoo child supports both Direct3D and the Open GL APIs. And the price? Just $199.95. Another graphics board maker using the Voodoo chip is Intergraph. This company calls its board "Intense 3D Voodoo." Unlike Diamond, the Intergraph board also does accelerated 2D graphics, as well as offers some cool features for adjusting computer text on your TV. Its price is $225. (A review of both board sets will be appearing in the next issue of 21st.)

It therefore appears that 3-D silicon processing is still nicely following Moore's Law. But just because what cost $1,000 to do in 1996 will only run you $200 in 1997, it doesn't mean that prices for high-end 3-D PC cards will now drop like a stone. It simply means that for $1,000, you get to go several times faster than last year. The need for more speed in high end image processing is in ever constant demand. In high-end PC 3-D graphics, there is definitely no free lunch.

The key to unlocking this ever increasing power of rendering engines, like Trident's or 3dfx, is encapsulated in its 3-D API. Each API set offers up a different way to access and utilize those 3-D capabilities. And beneath those APIs are the individual drivers for the various chips/boards. Thus, effective 3-D PC processing presumes capable hardware, efficient and capable API's, and a good set of low level drivers.

All three elements must be present if you are to get good 3-D performance on your PC. (Having problems getting that 3D game going? Who do you blame? The API design itself? A poorly implemented API? The 3-D chip set? Poor driver design? In wildly diverse architecture like PCs, it can be one or any combination of these factors that caused poor performance.) Regardless, it is typically the APIs which will catch the most heat. This makes sense, since from a programmer's point of view it is the API which is most "visible," and either allows or prevents him from doing what he wants to accomplish, in the most efficient way possible.

Given Microsoft's plans to capture a significant portion of the UNIX market with NT, and that SGI pretty much owns both the 3-D UNIX and high end PC 3-D markets, it's no surprise that this Mountain View company is firmly in Microsoft's API sights. (It's worth noting that Microsoft has long been an OpenGL licensee for NT and Win95.) Microsoft's business model is, and always will be, not based on operating systems per se, but rather, on its APIs. He who owns the APIs owns the applications. And he who owns the applications also happens to own the PC market. In a very real sense, the operating system is merely there to service the APIs.

Assuming that all or most of the other new Talisman chips coming on the market will also revert to using pipelines, then Microsoft's original nuke 'em API strategy will have failed completely. So once again, the 3-D market comes down to a pitched API battle between SGI's Open GL and MS Direct3D. And this time, commodity price points are no longer a clear market divider, as evidenced by the Voodoo Rush 3-D boards. This puts even more pressure on Redmond to somehow come up with a killer strategy.

So who will win this new round? That depends on your definition of what is to be won. For both SGI and Microsoft seem to have wildly different ideas about what's at stake in this new API war. (The astute reader may wonder where Intel's MMX fits in all this 3-D industry maneuvering. Short answer, nowhere. Even with the new AGP setup.

An AGP Aside

The Accelerated Graphics Port (AGP) interface from Intel is a new PC bus specification. Not to be confused with the PCI bus, the AGP has been designed specifically for dedicated use by point to point graphics controllers and components. Intel's intent is to enable high performance graphics capabilities, especially 3D, on commodity hardware PCs. The AGP is physically separated from the PCI bus, and uses a separate connector. The AGP is thus clearly ancillary to PCI. The 133MB/sec, 32-bit, 33MHz version of the PCI will continue to be the main, general purpose, system I/O bus for PCs.

The private AGP bus enables 3D applications to have special access to image data so that the monitor image can be rapidly refreshed. The AGP also provides enough storage to support z-buffering and alpha blending. Furthermore, the AGP will enable texture mapping to run faster on non-accelerated PCs. This is because via the AGP design, unlike the PCI bus, no matter how texture data is scattered, the graphics subsystem can retrieve it seamlessly. By enabling the use of main memory for z-buffering, alpha blending and texturing, Intel's hope is to offer high performance 3D graphics at "mainstream PC prices."

For graphics accelerators, the AGP offers dedicated pipelined access to main memory and faster transfer rates. Thus, the AGP provides accelerator cards with a high bandwidth, low latency connection to system memory. With more effective use of system memory, AGP-specified graphics boards do not require local texture memory, and can be provided at much lower costs. For those who may recall Intel's UMA (Unified Memory Architecture) debacle, the AGP is reassuringly different. UMA was a failed attempt by Intel to move the entire frame buffer from a graphics subsystem card to main PC memory in order to reduce cost.

Unlike UMA, the Accelerated Graphics Port architecture assumes there is still dedicated graphics frame buffer memory on a separate card. AGP main memory is only utilized for advanced 3D features, such as textures, alpha buffers, and z-buffers. The Accelerated Graphics Port specification allows for dynamic allocation (and reallocation) of main memory, making it much more flexible. This memory can be "reclaimed" by the operating system and applications after being used. This AGP design switch also eliminated the performance loss that UMA exhibited. The latter required allocation of main memory at boot-up time, thereby leaving less memory for the operating system.

Intel's AGP spec contains all the necessary electrical interfaces and bus protocol information for system OEMs and third party graphics companies to interface to this new bus. With regards API support, Microsoft has already pledged Direct3D support, and others, like OpenGL, are sure to quickly follow once these new AGP-equipped systems start appearing in large numbers, which will be at the end of 1997.

Although the new AGP intends to offer something for (most) everybody, there is one big catch. Although Intel's says the AGP could be implemented on 16 bit Pentium CPUs, Intel only intends to make the AGP spec available for use by Pentium Pro processors. Intel says the superior advanced floating point unit and faster cache algorithm of the Pro series makes it the better AGP platform choice. (Just tell that to non-Pentium Pro users.)

Lastly, be aware that there are up to eight different ways for a computer maker/graphics card maker to implement the AGP spec. The maxed out spec does AGP texturing, as opposed to local texturing. In the former, all it take is one step to have textures executed from system memory; as opposed to the latter's two step dance that executes textures from graphics memory. In addition, a full boot AGP implementation, called 2x, can haul your 3D ashes at 133 MHz. But in AGP's 1x mode, the computer's bus dawdles along at 66 MHz. 2X AGP offers, according to some graphics board vendors, 75% higher performance than local texturing.

To make Intel's AGP work, the systems vendor has to incorporate Intel's 440LX chipset and a graphics controller in the hardware. The AGP engine can either go on the computer's mother board itself, or on the add-in graphics card. But in the near term, you will most likely find the AGP engine on the add-in graphics card. Or at least until Intel ramps up production of its own AGP-equipped PC motherboard and gets them into the hands of a zillion VARs and OEMs.

Naturally, you need special software drivers to make AGP fly. But Microsoft wont have those until Win98 arrives. In the meanwhile, the graphics board companies are shipping their own in-house drivers with their AGP enabled cards.

So let's see, we have 8 ways to do it, and a spaghetti bowl of non-uniform AGP drivers -- which the various 3D applications must support if they are to dance to that particular card's AGP tune. And oh yeh, you might want to check out if that AGP vendor implemented all the pipeline and sideband protocols that are meant to improve the spec's sustained bandwidth.

When you go shopping for that new AGP PC, maybe you should keep some of this stuff in mind. Of course, the clerk at your local computer store will have all the answers to your burning AGP questions. Now back to our main story.

Before we make a call on who will win what, when, in this 3D battle, a more thorough looksee at OpenGL is in order.

Long synonymous with high performance 3-D image processing systems, SGI realized several years ago that if the company was not going to be marginalized by ever more powerful PCs, then it had to do something to preserve its market franchise. Hence, the 2-D and 3-D OpenGL API, which came into being when SGI decided to "open" up its powerful software system to third parties. OpenGL defines a highly portable architecture for interactive 3D visualization.

Somewhat confusingly, because of its large feature set, OpenGL is often called a high-end API. In truth, OpenGL is actually lower-level than Microsoft's Direct3D Immediate Mode API. For like Microsoft's HAL (Hardware Abstraction Layer, above which Direct3D sits), OpenGL sits right above the hardware. But unlike HAL, OpenGL is used directly by applications. Therefore, well done implementations of OpenGL should have, according to SGI, lower overhead than Direct 3D implementations.

Lastly, the OpenGL license mandates that all of the spec be implemented, thus assuring a strong measure of cross platform consistency. In contrast, Direct3D licensees have the option of implementing just subsets of the API. (Such feature subsetting is again being done by Microsoft with Talisman.) Supposedly, Microsoft's HEL (Hardware Emulation Layer) is meant to deal with this issue, by providing the functionality that various HALs lack (but at much lower performance.)

However, even a HEL implementation can be lacking some functionality as specified by the Direct3D API. For example, a number of Direct3D functions were not supported in the DirectX 2 SDK (Software Developer's Kit). Consequently, claims SGI, many applications were exposed directly to the limitations of the individual HALs, with often miserable performance results.

As already noted, OpenGL defines the graphics pipeline. And key to OpenGL's popularity is its portability and easy scalability. Unlike Direct 3D which is dependent on other Windows system-specific APIs to provide 3-D graphics services, OpenGL runs on everything from sub $200 PC boards to multimillion dollar UNIX clusters. All UNIX workstation vendors have adopted OpenGL, as have Microsoft for NT and Win95 (it ships with every MS copy), by IBM for OS/2, and even by Apple for its Macintosh. In addition, says SGI, a majority of third party 3-D hardware vendors support OpenGL.

In the high-end 3-D PC market space, OpenGL claims to have 58% market share, with MS DirectX lagging way behind, at a mere 7%. Also, according to SGI, its OpenGL is the only 3-D software system that spans all significant market segments, from Games, to 3-D web, to CAD, to content creation/modeling to visualization/simulation. In comparison, SGI says that MS Direct3D is mostly relegated to the games market, with some encroachment onto the 3D web space. To ensure it's "open-ness."

OpenGL is administered by the ARB (Architecture Review Board.) The ARB is comprised of Digital, Evans & Sutherland, Hewlett Packard, IBM, Intel, SGI, Sun Micro, and Microsoft. For ARB members, indeed for all Open GL licensees, it is relatively easy to extend the capabilities of OpenGL because it is the lowest-level 3D graphics API in the system.

Fortunately, the OpenGL extension mechanism minimizes syntactic and semantic conflicts between vendors, so any one OpenGL licensee can extend OpenGL. In fact, extensions to OpenGL 1.0 were validated by customers, and the most useful ones were folded into the OpenGL 1.1 specification. In contrast, SGI says that extending Direct3D is inherently more difficult because Direct3D is layered on the HAL and HEL. SGI further notes that these interfaces are controlled exclusively by Microsoft, and therefore hardware vendors cannot expose new Direct 3D functionality without Microsoft's consent and participation.

Just recently, SGI announced several major enhancements to OpenGL. On the critical PC side of things, OpenGL has long had a bad rap for poor performance on systems without specialized 3-D chips. To remedy this, SGI just developed the "Cosmo" Open GL for PCs that do not have dedicated graphics hardware. To insure compatibility, Cosmo OpenGL is complementary to Microsoft's own OpenGL implementation.

Next, SGI announced OpenGL Optimizer, designed to improve the rendering, interactivity, and quality of large CAD/CAM/CAE data sets. It is claimed that this new feature will provide anywhere from 2X to 10X performance improvements, as well as allow OpenGL applications to interact with truly monstrous data sets. Initially, this enhancement was just for SGI's own systems, but the company has now offered Optimizer to a new industry consortium seeking to define a standard CAD/CAM/CAE API.

And not to be outdone by Microsoft in the object-oriented image processing arena, SGI announced earlier this year that the ARB members have approved the release of the OpenGL scene graph toolkit. A high-level object-oriented API under development by SGI, this tool kit will be available later this year, and will supposedly make it much easier for developers to create and manage complex 3D images. Finally, SGI says that OpenGL Java bindings will soon be available.

The SGI-developed toolkit is a system graphics resource manager, and also supplies essential functions from existing toolkits, while allowing applications to make calls at the basic OpenGL level. As systems management is handled automatically by the API, complex new functions can be buried in new types of chips and accelerator cards. Thus, the developer does not have to worry about how best to use the new features, as the toolkit API masks underlying systems complexity. In turn, the toolkit allows the chip and card vendors to greatly differentiate their image processing products from one another, and without confusing or alienating their graphics software developers.

This differentiation-yet-all-is-similar story is perhaps the strongest marketing pitch being made by SGI against Microsoft's Direct3D API. This is why Trident was able to offer both DirectX and OpenGL support, even though the chip's design was constrained by Microsoft's Talisman specs. Even without the new toolkit, OpenGL has always offered such systems differentiation/uniformity, but now it will come at a much simplified object management level.

When asked about integrating DirectX with OpenGL, SGI said that as a rendering technology, the OpenGL API is carefully architected so that it can be integrated with any Windowing API quite cleanly. For this reason, OpenGL can be integrated with other DirectX APIs to the same extent that Direct3D can be. SGI also noted that one integration issue on Windows currently is the ability to use DirectDraw images as texture maps in OpenGL.

Microsoft has done DirectDraw bindings for OpenGL but, says SGI, seems unenthusiastic about releasing them. SGI's stance on this matter is that if Microsoft doesn't soon release DirectDraw bindings for OpenGL, then someone else probably will. The DirectDraw interfaces are public, so anyone can do them. (But SGI also acknowledge that this will take some work to get this done right, especially to get it to work right with hardware acceleration.)

SGI also went on to say that DirectDraw surfaces can be bound as OpenGL textures. The company states that there are a couple of ways to go about this. This could be done by extending OpenGL (which is very easy). Or, once there are DirectDraw bindings for OpenGL, you can simply copy from a DirectDraw surface to texture memory. (OpenGL 1.1 has a CopyTexImage command that allows you to copy from a drawing surface into texture memory). SGI used the latter approach to do video textures. First the drawing surface is bound to a video source, then the contents of the drawing surface are copied to texture memory to be used during rendering.

By and large, non-3D savvy PC users have been mostly unawares of all these seemingly esoteric issues. But not so PC gamers. Enormous flame wars have periodically erupted as each side's partisans claim their API religion to be the only true one. As it happened, a large bombshell was dropped on the 3-D battlefield when Id Software, the creators of "Quake," announced that their hugely popular game would be supporting OpenGL.

This QuakeGL announcement caught many veteran gamers completely off-guard, as it had almost become accepted market wisdom that OpenGL was just for big buck high-end 3-D systems. (Actually, if they had done their homework rather than always playing games, they would have known that the awesome, $200 Nintendo 64, which employs specialized MIPS chips from SGI, also uses an OpenGL variant.)

In some game developer quarters, there is a growing assertion that Direct3D's Immediate Mode should be scuttled by Microsoft in favor of OpenGL. (Direct3D's Retained Mode just doesn't cut it for game developers as they need much more control than this mode delivers.) E.g., the article by Chris Hecker in the April-May '97 issue of Game Developer, "An Open Letter to Microsoft: Do The Right Thing for the 3D Game Industry." Hecker made an excellent argument that Direct3D Immediate Mode never would catch up with the speed and sophistication of OpenGL, and that Microsoft should lets its own internal OpenGL advocates off the corporate message leash. In other words, the OpenGL vs. Direct3D debate has split ranks even within Microsoft.

But despite Hecker's articulate and persuasive argument, and the repressed desires of some on the Redmond campus, it's a snowball's chance in Hades that Microsoft will ever back off from Direct3D. MS only makes tactical retreats, never strategic ones. And Direct3D, make no mistake, is strategic to Microsoft's future. How, you might well ask, can that be, as we are only talking about games, for God's sake? Wrong. We are talking about much, much more than that.

And what is this enormous thing? In a word, HDTV. All digital, terrestrial broadcast television will be here in 1998, as legally mandated by your FCC. ( See "HDTV Wars) This new consumer electronics development, which will shortly obsolete every TV set in America, will offer stunning pictures. At their highest resolution, they will be more than two times better than even a DVD. HDTV also offers an opportunity for a whole new industry devoted to broadcast digital services to come about.

Indeed, HDTV, when you stop to think about it, is the ultimate 3-D market. The folks in Redmond already know this. Microsoft is actively pitching DirectX/Direct3D and NT at the professional broadcast-video and animation markets, long SGI UNIX strongholds. Microsoft is also making DirectX deals with Avid, a major player in the professional video development arena. (Microsoft even plans to have DirectX running on video arcade games, set-top boxes, and hand-held DVD players.)

Microsoft is therefore well on its merry way with its usual business strategy of embrace, extend, and lock-in. And the marketing dance goes like this: First the producers of video and animation content get locked into the MS ActiveX APIs. Next, Microsoft will port these APIs to as many different HDTV platforms as possible, including PC TVs. And finally, when the new DirectX-enabled multimedia content is HDTV broadcast, it will go looking for the appropriate MS API hooks. But if those MS APIs aren't there on the HDTV set, then hello big blue screen. Once thousands of MS API-bound services and applications are flying over the HDTV airwaves, Microsoft will end up owning what may become a trillion dollar market by mid-21st century.

So where is SGI, the premiere 3-D systems and OpenGL vendor to the TV post video production industry, in all this? Amazingly, nowhere. In fact, when SGI was queried on how it intended for OpenGL to respond to Microsoft's grand HDTV strategy, it was stunned into embarrassed silence. They had never even considered the possibility of OpenGL being on HDTV consumer sets. Once again, Microsoft may win yet another major war; not because of any special technology or unique business acumen, but because of the plodding slowness of its competitors.

And if the prospect of an HDTV sweep still doesn't sway your business thinking, then consider the fact that Microsoft has openly stated that 3-D image processing will soon be an integral part of the PC desktop interface. And that means, of course, that application developers of all non-3-D stripes will soon have to sit up and take notice.

No doubt about it, low cost, high quality 3-D is about to go hugely mainstream, and sooner than most users realize.

Thus, there is no way that Microsoft is going to relinquish its Direct3D ball to OpenGL. Microsoft will, in its typical fashion, grind and grind away at it; patching it up there, adding a bit there, and making much PR everywhere, until Direct3D looks good to almost everybody, even if its good looks turn out to be mostly superficial. (Or, as John Carmack of Id Software succinctly stated, it simply "sucks less.") And although Talisman has undergone significant brain surgery since it first appeared, there will be enough confusingly labeled "Talisman" chips out there to restore it to smart weapon status. Even just a little 3-D FUD can go a long way in Microsoft's highly capable marketing hands.

Direct3D and Talisman are both long term, critically important strategic weapons in Microsoft's marketing arsenal. Expect Direct3D to quickly gain share in the PC games market, while the high end graphics software makers continue to support OpenGL. The question is, will OpenGL backers ultimately roll over, and allow these MS nukes to be used as first strike weapons?

Certainly, SGI is now at DefCon 3(D). Intel's next-generation chipsets and CPUs will continue to push the price/performance curve for 3D in a big way, especially with their continued emphasis on floating point performance. One 3D graphics company just floated an internal memo that computed "cost-per-unit-score" value for a variety of 3D workstations (UNIX and NT), and when measured this way, every SGI machine came out at the bottom. (The 3Dfx 4400-100SB came out on top.) So if you care how much it costs you to do 3D, SGI is in a world of hurt. And this is just the beginning for PC 3D - -there's lots of room for improvement.

You don't need 3-D glasses to see that the real war games have only just begun.

(Special thanks to Michael Crowe who provided some great feedback/suggestions for this article.)

Copyright 1997, Franco Vitaliano, All Rights Reserved