Someone explain these Xabre results

ET

Regular
I checked the Soltek Xabre 600 review on Digit Life (http://www.digit-life.com/articles2/xabre/soltek-xabre600.html). If you look at the results of the RightMark3D pixel filling, which they use to "prove" that the Xabre has two pipelines, you can see some very strange results:

Looking at the first test (although the second is the same), the single texture pixel rate is 591, while the 2 texture texel rate is 1551, which means a pixel rate of 775 -- which is in line with the 0 texture pixel fill rate. And can't be achieved by 2 pipelines (correct me if I'm wrong).
 
I seem to recall indications of some sort of rather aggressive "color compression" effect for some of the Xabre's "speed enhancements" that might explain some results.
I think some of the images I remember are ugly enough to be the result of, for example, outputting the same calculation result for 2 horizontally adjacent pixels if they are on the same polygon and sample the same texture coordinate, instead of independently calculating lighting interaction, or, perhaps a bit more sophisticated, outputting a simple blend of independently calculated outputs between two screen positions on the same polygon instead of calculating the result independently (could "enhance" shader throughput significantly). Even fits with the low quality shader outputs I also seem to recall in some instances.
 
Re

Geforce 4 Ti 4200 :
test-gf4.jpg


Xabre 200 - Driver 6.14.1.1300 :
test-xabre-new.jpg


Sorry but I don't see too much difference between the two, the xabre doesn't look as ugly as you portray it
 
demalion said:
I seem to recall indications of some sort of rather aggressive "color compression" effect for some of the Xabre's "speed enhancements" that might explain some results.

I don't recal this, though I recal that Xabre uses something SiS calls "Turbo Texturing" which was used in the elder SiS315 chip too. if I still recal right, Turbo Texturing basically uses only 2 texture samples per texel in bilinear, instead of four. this causes quality drop that is cleary visible when benchmarking with default settings. Of Course you can turn Turbo Texturing off (don't know situation now, but it used to be controlled by registry key.)

still, "Turbo Texturing" really doesn't explain at all this pixel fillrate problem. except if they did benches with different settings, but I doubt that...
 
Sorry but I don't see too much difference between the two, the xabre doesn't look as ugly as you portray it.

I can't either on 200x150 sized images :rolleyes:
 
What images? They don't seem to work for me at the moment. Also, was this with the default speed boosters on or off? The Xabre looks quite a bit better with certain Turbo options turned off, and I was presuming the results were at default settings.


In any case, an alternate theory is that the texture sampling is limited so that 2 sets of texturing units are shared among 4 pixel output pipelines...which would be a new creative meaning of "4x2" as well...which causes it to act like 2x4 quite often, but better than 2x4 at other times (how much magnification does the Rightmark3D fillrate tests exhibit?).

Actually, didn't someone (Wavey?) propose such an explanation already?
 
If you read our Xabre review there was some suckage in the drivers. It seems like they do thing 'properly' at 640x480 for WHQL purposes, but any other resolution it falls back to mip-mip tweaks and other suckage. OpenGL quality as permanently sucky.
 
DaveBaumann said:
If you read our Xabre review there was some suckage in the drivers. It seems like they do thing 'properly' at 640x480 for WHQL purposes....

Are you saying that WHQL tests are only carried out at 640x480? :oops:
 
WHQL is about system stability (mostly), not performance.

The only thing microsoft really cares about it making sure any particular product doesn't screw up the system and make microsoft look bad.
 
RussSchultz said:
WHQL is about system stability (mostly), not performance.

Right, and testing only at one resolution, where drivers can do something else entirely at some other resolution, is not a good way to test stability. That's the reason for my surprise.

Certainly, you can't test EVERY single situation, but if tests are limited to 640x480, that strikes me as very odd and short-sighted.
 
Back
Top