FXT1 in D3D?

[Grand Admiral Thrawn]

Recently i compared the performance of "Sacred" between a v5 5500 and v5 6000, and the 6000 is able to display the minimap, and to support smooth gameplay at full zoom level while not within a city. The 5500 was extremely sluggish here, looked like it didn't have enough texture memory left to support the game at maximum zoom.

My idea: Couldn't FXT1 be forced in Direct3D? That would GREATLY help with a few newer games that make use of rather large textures. Maybe games like sacred could be played smoothly with FXT1 forced, and even 2xFSAA might get possible.

On top of that, it'll not only do a lot for v5 6000 owners, but also for those 5500 cards.

Is this possible?

[dborca]

There is no difference between 5k5 and 6k. Both of them have 32MB memory. The memory is not "shared" between chips. If you heard otherwise, then ask your money back: you were lied to.

Next, in the war between FXT1 and S3TC, guess who's the loser? You guessed: FXT1. And you know why? FXT1 has better quality but it costs dearly in terms of the compressor speed. FXT1 needs fancy analyze techniques in order to use its full capability (the 4-in-1 encoding scheme). Without this, it's only a castrated S3TC.

So, the speed gained by the smaller amount of data being sent to the chip is overwhelmed by the complexity of the run-time FXT1 encoder.

nVidia gave written permission to the Mesa project to implement FXT1, and I am (re)coding the algorithm. No need to say it's giving me nightmares.

My question is: why not use S3TC instead? The Napalm chip can handle DXTC and since you're asking this for DyrektEks... well, it's free.

[Grand Admiral Thrawn]

I however don't know how to force DXTC. There is no driver option for this, so if a game doesn't make use of DXTC natively, it cannot be enabled (i guess)?

For the memory: 32MB of memory per chip, yes, but the framebuffer is split up between the chips, no? That would mean, on a 4-way SLI setup, each chip would get a quarter of the total framebuffer, while on a 2-way SLI setup, each chip will get a half of the total framebuffer.

So i'd say, the more chips you use, the lower the memory load per chip is, and the more texture memory would be available per chip. As far as I know, only textures need to be duplicated for each chip, not framebuffer/pixel data.

Am I correct or wrong? That could explain the Sacred behaviour. Still, being able to force DXTC (if not FXT1) would help.

Thanks.

[SuperFurryFurryThing]

On all of the VSA100 cards the texture memory available depends on the screen resolution and pixel depth, and number of buffers in the flipping chain. The number of processors has very little effect, as it only reduces it very slightly due to alignment issues. The amount of texture memory actually decreases with increasing number of chips for alignment reasons, although not by a significantr amount. Sacred is probably faster on a V5 6K becuase the V5 6K draws the triangles faster.

SFFT

[roflkopp]

Uh, i asked this question already several times, and i completely agree with GAT...

Next, in the war between FXT1 and S3TC, guess who's the loser? You guessed: FXT1. And you know why? FXT1 has better quality but it costs dearly in terms of the compressor speed. FXT1 needs fancy analyze techniques in order to use its full capability (the 4-in-1 encoding scheme). Without this, it's only a castrated S3TC.

So, the speed gained by the smaller amount of data being sent to the chip is overwhelmed by the complexity of the run-time FXT1 encoder.

I think, this won't be a problem if the textures would be saved in a swap file.

I however don't know how to force DXTC. There is no driver option for this, so if a game doesn't make use of DXTC natively, it cannot be enabled (i guess)?

You are right. So we hope that our driverwriters implement an option to force Texturecompression.

[Raff3DC]

WickedGL can do this too. Well, I'm completely unfamiliar with driver programming, but I can imagine that it's possible. How big would the effort be to realize this?

I agree with Thrawn and roflkopp: It would give the "good old" VSA-100 cards a really big boost. A worthwhile implementation that every voodoo user would love very much. Please think about it. =)

A test with one game - like the VRAM-eating UT2004 with it's "fat" textures - would be nice for a test.

Greetings from Germany,
Raff

[Dekal]

First, i know nothing about programming, too. But wouldn't it be possible to drastically increase video performance with more buffers/pre-buffers before displaying the processed graphic? I have seen great increase when switching from 0 Pending Buffers to 1 Pending Buffers and would suggest to set it to min. 1 Pending Buffers by default when installing driver whitout 3dfx-tools or v.control or another tool, if possible. Sorry for my bad question, but can that T-Buffer utilized to boost 3D-performance, instead of using it for better quality? Maybe it is one of that hidden performance booster in that good old voodoo5 at least.

[roflkopp]

The problem is, that - nowadays - Voodoos are mainly limited by their amount of memory. More buffers utilize more memory and so some games may be faster with more pending buffers (less fps drops) but other slower...

[Dekal]

I know that the memory is very limited but this are/would be small buffers for a great performance boost!

[Grand Admiral Thrawn]

Again, i can only repeat myself. Please integrate an option into the v4/5 drivers to force DXTC in D3D. It would do a lot for some games. Most of us already experienced what a pain it can be to play a game with hires Textures, when that game has to swap them to the main memory. This renders a game on v4/5 unplayable! If FXT1's 4-in-1 encoding is forceable too, all the better! In some scenarios it might just be the better solution, sure has to be better than swapping textures to the system memory..

Thank you very much.