PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : GF4Ti Aniso-"Bug": Neue(re) Infos


nggalai
2002-08-21, 14:43:49
Hi there,

auf B3D kam in einer Diskussion zum Thema AF auf der Radeon9700 (hier (http://www.beyond3d.com/forum/viewtopic.php?t=2143&postdays=0&postorder=asc&start=20)) auch wieder die Sache mit dem GF4Ti Performance-Einbruch bei aktiviertem AF auf. Hier aus zwei der interessantesten Postings, als Diskussionsgrundlage:

Posted by ERP
> Yes, it appears that when anisotropic filtering is enabled, the
> GeForce4 operates as a 4x1 card (four pixel pipelines, one texture
> per pipe).

This isn't exactly what happens.

There are limits per clock on the number of texels that can be read into the cache along with the number of texels the pipelines can sample from the cache, when aniso is forced alond with multitexturing it is fairly likely that the later of these two constraints will be violated so it takes 2 or more clocks to read the texture sample.

This is one of the issues with forcing aniso in the driver (it forces the filter mode on all the texture stages), If the application enables aniso rather than it being forced in the driver then different sampling criteria can be selected where they make sense on different texture stages say aniso on stage 1 and bilinear on 2, aniso on 3 and bilinear on 4 at which point the chances of being able to read the texels in a single clock are much more likely and hence the perfomance hit is much lower.

[...]

> That shouldn't affect multitexturing anisotropic fillrate tests
> (where all polygons are isotropic).

My tests are at 640x480 on NV2A and they correlate pretty well with the above description (which is parafrased from the description I was given courtesy of someone who should know what's happening).

There may be additional work done during aniso that also causes fill reduction (say different cache read behaviour), or there maybe a minimum number of samples it takes. But alternating sample modes Aniso/bilinear on the texture stages will benchmark at WELL over 50% fillrate so it's certainly not just running like a 4x1 pipeline.


Die > kamen von Chalnoth; ERP hat als X-Box-Entwickler direkte Kontakte zu NV.

Meinungen? ERPs Erklärungsansatz klingt für mich vernünftig; und sein Hinweis zum Thema in-game anisotropes Filtering vs/ forced AF decken sich mit den Aussagen von Microsoft zum Thema, AFAIR.

ta,
-Sascha.rb

tEd
2002-08-21, 15:34:58
ab den 30.xx treibern kann man diese einstellungen im neuen rivatuner nun auch von hand machen.

im übrigen hat digit-life einen artikel darüber
http://www.digit-life.com/articles2/gf4/gf4ti4200-3.html

aths
2002-08-21, 17:59:04
Ich halte die Erklärung mit dem Cache für unzureichend. M.E. liegt die Ursache eindeutig in der Füllrate, also dass NV25 bei AF seine 2. TMU nicht nutzt.

But alternating sample modes Aniso/bilinear on the texture stages will benchmark at WELL over 50% fillrate so it's certainly not just running like a 4x1 pipeline. Das kann ich nicht bestätigen. Sobald irgendeine TMU AF filtert, sind maximal 50% der Pixelfüllrate drin, und die Texelfüllrate entspricht leider auch bei MT der Pixelfüllrate.

Börk
2002-08-22, 21:07:52
Originally posted by aths
Ich halte die Erklärung mit dem Cache für unzureichend. M.E. liegt die Ursache eindeutig in der Füllrate, also dass NV25 bei AF seine 2. TMU nicht nutzt.
Das kann ich nicht bestätigen. Sobald irgendeine TMU AF filtert, sind maximal 50% der Pixelfüllrate drin, und die Texelfüllrate entspricht leider auch bei MT der Pixelfüllrate.

Ja sieht man ganz deutlich beim 3dMurks. Single und Multi Texturing sind ziemlich gleich!