4. How can we solve the timing difference between T&L and render core? I mean T&L has a rather specific amount of math and thus cycles while  rendering is dependent on the size of the polygon (more or less cycles needed). Where would you locate the buffer to solve this?

Well, this is a very implementation-specific question. I do not know the specifics of how GeForce or Savage 2000 have dealt with this issue. But it is a very real one that needs to be solved in an appropriate manner, otherwise you could easily see a dramatic difference between "peak" and "sustained" overall performance.

5. More fill-rate requires more bandwidth. How do you plan to tackle this
increasing problem?

Well, again you're getting into very implementation-specific issues. Different hardware vendors are solving this problem in a variety of ways. From pixel caches to chunking-style architectures to embedded memory, everyone has a little different idea on how to deal with it. How you do it really is irrelevant - it's the sustainable performance that results that users care about.

6. S3TC is finally seeing some support, years after it was introduced, how long do you expect that it will take to see the first killer app that needs T&l... after all Quake3 is only designed for about 10.000 tri/sec...

Well, like any new technology, it will take some time to see games actually take advantage of a new feature. One certain problem with hardware T&L is that developers still have to worry about their games running well on older hardware. So, the advent of hardware T&L has actually widened the gap between the minimum set of hardware that a developer has to support and the top-of-the-line 3D accelerator. This makes it even more difficult on the developers, and I think as a result will slow the acceptance of hardware T&L used to its full potential.

One big misconception is that games which are written with OpenGL will automatically get faster than using hardware T&L. The reality is that OpenGL is a very broad, full-featured API, and it is very dependent on how the game is written and which routines of OpenGL are used as to whether that game will see performance benefit of a hardware T&L accelerator. Games must be written in certain ways even with OpenGL to see substantial performance improvements, so this will require lots of evangelism to make happen. And obviously, there are no DirectX titles which can take advantage of hardware T&L until developers start to use DirectX 7. So, as you point out, it's going to take some time before we really see broad support for hardware T&L.

This is exactly the reason we're so excited about our T-Buffer technology with full-scene spatial anti-aliasing. It requires NO evangelism to the development community. A user can buy a T-Buffer enabled 3dfx 3D accelerator and immediately play existing games with dramatically improved visuals. No waiting around for a trickle of titles which support some new features. When the first T-Buffer enabled product is launched for this Christmas, users will have over 500 titles to choose from which can take advantage of full-scene spatial anti-aliasing. That is a very compelling features which users are very excited about.