Tzeentch
2002-07-02, 12:29:25
Quelle: http://www.nvnews.net/forum/showthread.php?&threadid=16084
NV25 GPUs do have some AF related issues. It looks like fillrate drops drastically when more two (or more) textures are simultaneously filtered with AF. In this case the efficiency of multitexturing is equal to zero (i.e. multipass rendering performance is equal to singlepass multitexturing).
This was already proved by 3DMark/SS fillrate tests. I've also created my own test D3D application to ensure that is' not the application's fault. I just rendered two isotropic textures in both single and multitexturing modes. The performance reduces significally (equal to multipass rendering) when AF is used for both textures, but it is MUCH higher when I disable AF for the second texturing stage. Furthermore, the GPU must _not_ use AF for isotropic textures at all, but NV25 do it (NV20 don't). I'm afraid that it's just a hardware feature (bug?) of this GPU and it will never be fixed by NVIDIA in new drivers.
Don't tell me that it will be fixed coz NV already fixed OpenGL driver. They didn't fixed anything, AF was just optimized for all NVIDIA GPUs (and it's very said that they did it after discovering the problem only).
The easiest way to work around this problem (NVIDIA, listen ) is to allow us to force AF on per-stage level. There is no need to use AF for all texturing stages (or texture units in OGL therminology) in the most of currently existing games. Why to filter secondary textures (usually light/reflection maps and so on)?! It's just a waste of fillrate, the difference in IQ will be hardly noticable.
I assume that they already did such optimization in the OpenGL 28.90+, and there are some facts that confirm it:
1. Both anisotropy modes (slow/quality and fast) give the same performance in singletexturing mode, fast mode gives boost in conjunction with multitexturing only.
2. IQ differences in Q3 are noticable (but it was very difficult to find it ) on the lightmaps only.
3. It looks like they've experimented with D3D driver too - it contains encrypted D3D registry entry, which allows to limit the maximum degree of anisotropy for specified texturing stages for NV25 only.
All this stuff allows me to assume that in fast mode they simplify filtering algorithm (disable anisotropy at all?) on some textures (far from camra?), filtered by non-primary texturing unit.
__________________
Alexey Nicolaychuk aka Unwinder, RivaTuner/S3TCFixPack/SoftQuadro programmer
Wäre ziemlich traurig, wenn er damit Recht behalten sollte. Simultanes anisotropisches Filtern mehrerer Texturen ist ja ein nicht gerade unwichtiges Feature.
Das auf Kosten der Bildqualität, mit einem simplen Workaround im Treiber, versucht wird die Performance zu steigern, um einen derartigen Schwachpunkt zu kaschieren, ist schon enttäuschend. Zwar sind derartige Methoden normal in der Branche, aber für einen Chip der u.a. aus dem Bedürfnis die Schwächen des GF3 zu beseitigen, geboren wurde (was ja auch weitestgehend gelungen ist), ist sowas schon ein ziemliches Armutszeugnis.
Hat jemand einen Link zu Benchmarkergebnissen von gleichgetakteten GF3 & GF4 Karten für mich, die gerade diese Schwäche verdeutlicht? Sein Q3-Ergebnis in nur einer Auflösung, ist ja nicht allzu aussagekräftig.
Naja, sowas zügelt dann doch ein wenig meine Euphorie auf die GF4-Karte, die ich mir diese Woche kaufen wollte. :(
Bleibt einem vorerst wohl nichts anderes, als sich an das Fünkchen Hoffnung zu klammern, daß er Unrecht hat, und Nvidia dieses Problem mit einem Treiber oder einem Microcodefix wirklich löst.
NV25 GPUs do have some AF related issues. It looks like fillrate drops drastically when more two (or more) textures are simultaneously filtered with AF. In this case the efficiency of multitexturing is equal to zero (i.e. multipass rendering performance is equal to singlepass multitexturing).
This was already proved by 3DMark/SS fillrate tests. I've also created my own test D3D application to ensure that is' not the application's fault. I just rendered two isotropic textures in both single and multitexturing modes. The performance reduces significally (equal to multipass rendering) when AF is used for both textures, but it is MUCH higher when I disable AF for the second texturing stage. Furthermore, the GPU must _not_ use AF for isotropic textures at all, but NV25 do it (NV20 don't). I'm afraid that it's just a hardware feature (bug?) of this GPU and it will never be fixed by NVIDIA in new drivers.
Don't tell me that it will be fixed coz NV already fixed OpenGL driver. They didn't fixed anything, AF was just optimized for all NVIDIA GPUs (and it's very said that they did it after discovering the problem only).
The easiest way to work around this problem (NVIDIA, listen ) is to allow us to force AF on per-stage level. There is no need to use AF for all texturing stages (or texture units in OGL therminology) in the most of currently existing games. Why to filter secondary textures (usually light/reflection maps and so on)?! It's just a waste of fillrate, the difference in IQ will be hardly noticable.
I assume that they already did such optimization in the OpenGL 28.90+, and there are some facts that confirm it:
1. Both anisotropy modes (slow/quality and fast) give the same performance in singletexturing mode, fast mode gives boost in conjunction with multitexturing only.
2. IQ differences in Q3 are noticable (but it was very difficult to find it ) on the lightmaps only.
3. It looks like they've experimented with D3D driver too - it contains encrypted D3D registry entry, which allows to limit the maximum degree of anisotropy for specified texturing stages for NV25 only.
All this stuff allows me to assume that in fast mode they simplify filtering algorithm (disable anisotropy at all?) on some textures (far from camra?), filtered by non-primary texturing unit.
__________________
Alexey Nicolaychuk aka Unwinder, RivaTuner/S3TCFixPack/SoftQuadro programmer
Wäre ziemlich traurig, wenn er damit Recht behalten sollte. Simultanes anisotropisches Filtern mehrerer Texturen ist ja ein nicht gerade unwichtiges Feature.
Das auf Kosten der Bildqualität, mit einem simplen Workaround im Treiber, versucht wird die Performance zu steigern, um einen derartigen Schwachpunkt zu kaschieren, ist schon enttäuschend. Zwar sind derartige Methoden normal in der Branche, aber für einen Chip der u.a. aus dem Bedürfnis die Schwächen des GF3 zu beseitigen, geboren wurde (was ja auch weitestgehend gelungen ist), ist sowas schon ein ziemliches Armutszeugnis.
Hat jemand einen Link zu Benchmarkergebnissen von gleichgetakteten GF3 & GF4 Karten für mich, die gerade diese Schwäche verdeutlicht? Sein Q3-Ergebnis in nur einer Auflösung, ist ja nicht allzu aussagekräftig.
Naja, sowas zügelt dann doch ein wenig meine Euphorie auf die GF4-Karte, die ich mir diese Woche kaufen wollte. :(
Bleibt einem vorerst wohl nichts anderes, als sich an das Fünkchen Hoffnung zu klammern, daß er Unrecht hat, und Nvidia dieses Problem mit einem Treiber oder einem Microcodefix wirklich löst.