ATIs Filtertricks

Original erstellt von GRAKA0815
Wobei man nicht vergessen sollte, dass FP24 ein ATI-Hauseigener Standard ist und kein allgemeiner Standard wie es FP32, FP16 ..................... ist!

afaik ist die offizielle mindestanforderung für einen vollwertigen DX9 Shader 24Bit Genauigkeit im FP-Format...
Wenn ein Spiel 32Bit als Optimum nutzen kann, dann gibts bei 24Bit eben leichte IQ-Unterschiede...
Wie aber aths bereits gesagt hat - 24Bit ist oft schon übertrieben genau, 32Bit auf jeden Fall...
 
Original erstellt von GRAKA0815
Wobei man nicht vergessen sollte, dass FP24 ein ATI-Hauseigener Standard ist und kein allgemeiner Standard wie es FP32, FP16 ..................... ist!
FP16 ist auch kein allgemeingültiger Standard, bei FP32 wird zwar die von der IEEE standardisierte Aufteilung eingehalten, aber der IEEE-Standard stellt weitere Anforderungen, welche von FP32 nicht erfüllt werden.


Original erstellt von Riptor
Diverse Probleme lassen sich eben durch Screenshots eher erklären, wenn man durch die Theorie nicht durchsteigt und man kann mittlerweile in einigen Foren erkennen, dass einiges recht bescheiden verstanden wird, Stichsatz "Radikale Vereinfachung der komplexen Thematik". :D
Das Umgekehrte gilt leider auch. Man zeigt was auf einem Screenshot, der Leser sieht es und glaubt, es zu verstehen. Aber ohne es wirklich zu verstehen. Ich habe es bei meinen Artikeln schon häufiger erlebt (kann also auch an meinem mangelhaftem Ausdruck liegen), dass Leser denkt er hätte es gerafft, später in Foren-Diskussionen stellt sich raus, dass dem leider nicht so ist.


Original erstellt von GRAKA0815
Wenn aber jetzt auch noch Hersteller hinzu kommen, die eigene Standards ins Spiel bringen, wird das alles nicht,
1.) langsam für die Programmierer der Software zuviel? An was sollen die sich halten? An alles?
2.) Da ich nicht glaube, dass die sich an alles halten werden/können/müssen, sehe ich da so ein paar probleme.
Ich nicht. Denn Shader werden mehr und mehr in Hochsprachen geschrieben. Die erforderliche Mindestgenauigkeit kann teilweise schon "maschinell" abgeschätzt werden, zur Not muss der Programmierer selbst was festlegen. Wie genau die HW dann konkret rechnet kann ihm doch egal sein, so lange das Ergebnis genau genug ist.
Original erstellt von GRAKA0815
Wenn ein Spiel nun in FP32 rechnen möchte, die Graka aber max. FP24 unterstützt, was dann?
In DirectX kann man FP32 nicht "anfordern".
Original erstellt von GRAKA0815
Umgegehrt, wenn ein Spiel max. in FP24 rechnet, die Graka aber nur FP16 und FP32 anbietet, was dann?
Das Spiel selbst rechnet das ja nicht, nur die Graka. Wenn das Spiel FP24 verlangt, und die Graka nur FP16 oder FP32 hat, sollte sie FP32 nehmen.
Original erstellt von GRAKA0815
Kann es sein, dass dann eben Softwareseitig umgerechnet werden muß?
Nein. Das ist alles Graka-Intern. Die Vertex-Daten gehen von der CPU immer im FP32-Format weg (und werden auch *immer* von der Graka durchgehend mit FP32 behandelt) und die Texturdaten liegenbestenfalls im 8-8-8-8 Format vor. (8 Bit pro Kanal. Jede uralt-Graka rechnet intern genau genug, um mindestens das auszunutzen.)
Original erstellt von GRAKA0815
Auf wessen Leistung geht das dann? Oder leidet dann aufgrund dessen die BQ weil ich dann "nur" in FP16 rechne?:confused_alt:
Wenn FP24 mit Grund gefordert wird, nämlich weil die Genauigkeit notwendig ist, aber die Graka einfach FP16 nimmt, kann das in visuellen Artefakten resultieren.

Original erstellt von Riptor
FP16 oder gar FP12 ist aber durchaus ausreichend,
Es gibt kein FP12, nur FX12 :)

Original erstellt von Crazy_Bon
Ich ging davon aus, dass das trilineares Filtering korrekt sei auf ATi-Karten, so hatte es in meiner Erinnerung aus einem Artikel von 3Dcenter.
http://www.3dcenter.de/artikel/2003/10-26_b.php Oops, den Artikel hast du ja selbst verfasst. ;)
Bitte lesen:
Original erstellt von aths
Das ist so erst mal weiterhin richtig. TF nutzt im Moment noch BF (früher oder später wird es wohl HW geben, die TF mit einer MIP-Textur macht) aber das BF für TF ist zoom-mäßig in einem Rahmen, dass ATIs BF noch als genügend korrekt angesehen werden kann. Die 5 Bit LOD-Fraction beim TF sind zumindest für Direct3D ausreichend. Ich kann hier zwar sagen, dass andere besser filtern (was auch wünschenswert ist!) aber ATI korrektes TF nicht absprechen.

Original erstellt von TheShaft
Wie aber aths bereits gesagt hat - 24Bit ist oft schon übertrieben genau, 32Bit auf jeden Fall...
Rrr, bitte unterscheiden! Für Farben ist FP24 oftmals "übertrieben genau", FP32 erst recht. Für Textur-Koordinaten ist FP24-Genauigkeit nur noch ausreichend, nicht mehr übertrieben genau.

Original erstellt von Crazy_Bon
Kann die GF4Ti auch bis maximal FP24 rechnen? Zumindenst lässt es keine höhere Einstellung zu in 3DMurks2K1.
Die GF4 rechnet nichts mit FP24. Farben werden mit FX9 verrechnet, Textur-Koordinaten mit FP32.

NEIN!!!
devil.gif
Mit FP24 ist man Transistorcount-mäßig im Vorteil, aber nicht Geschwindigkeitsmäßig.
 
Zuletzt bearbeitet:
Original erstellt von aths
NEIN!!!
devil.gif
Mit FP24 ist man Transistorcount-mäßig im Vorteil, aber nicht Geschwindigkeitsmäßig.

Und das kann wohin führen.... ?
 
Original erstellt von aths
Das Umgekehrte gilt leider auch. Man zeigt was auf einem Screenshot, der Leser sieht es und glaubt, es zu verstehen. Aber ohne es wirklich zu verstehen. Ich habe es bei meinen Artikeln schon häufiger erlebt (kann also auch an meinem mangelhaftem Ausdruck liegen), dass Leser denkt er hätte es gerafft, später in Foren-Diskussionen stellt sich raus, dass dem leider nicht so ist.

Gut, das ist eventuell auch der Fall. Nicht jeder bringt eben die Fähigkeit mit, diese Sachverhalte richtig zu verstehen, deswegen dachte ich, dass Bilder dies vielleicht besser machen.

Es gibt kein FP12, nur FX12 :)

Klar, stimmt. ;)

NEIN!!!
devil.gif
Mit FP24 ist man Transistorcount-mäßig im Vorteil, aber nicht Geschwindigkeitsmäßig.

Warum eigentlich?
 
Original erstellt von Riptor
Warum eigentlich?

Wegen der

Original erstellt von aths
[...]Kausalitätsketten[...]

denn:
Gesparte Transistoren an der einen Stelle kann man entweder sinnvoll an anderer Stelle einsetzen oder man hat dadurch weniger Wärmeentwicklung und taktet höher.

Der Verzicht u.a. auf TruForm-Hardware, DVD-Hardware, weitgehend winkelunabhängiges AF und FP32 war es möglich, einen zweiten 4xSIMD Pixelprozessor einzubauen, der natürlich der Performance zugute kommt.
 
Original erstellt von Carsten
Der Verzicht u.a. auf TruForm-Hardware, DVD-Hardware, weitgehend winkelunabhängiges AF und FP32 war es möglich, einen zweiten 4xSIMD Pixelprozessor einzubauen, der natürlich der Performance zugute kommt.

:confused_alt: Sorry, wenn ich mich jetzt wirklich DUMM anstelle, aber du meinst, die Performance steigt dann? Und warum verneint dann aths? :confused_alt: Bitte nicht schlagen, stehe aber gerade auffem Schlauch...
 
Was aths (IMO) meint, ist, daß nicht der Verzicht auf drei Bit an Präzision direkt zu einem Geschwindigkeitsgewinn führt. Die Hardware an sich ist eben auf diese und jene Berechnungen ausgelegt. Die Zeit, die dafür verbraucht wird, ist quasi dieselbe.

Nur sind durch diese Einsparungen an Transistorzahl eben woanders Transistoren "frei". Und wenn man nun genug davon einspart, kann man mehr Pipelines einbauen.

Und daß ein Chip mit 8 (Shader-)Pipes schneller ist, als einer mit 4 (Shader-)Pipes, ist doch klar.

Stell's dir vielleicht so vor:
Du musst 2x2 runde Steinkugeln von je 30kg Gewicht eine Treppe hochschaffen. An zweien dieser Kugeln sind Griffe dran.

Die Griffe selber machen sie nicht leichter, aber du kannst zwei auf einmal nehmen und schaffst die Aufgabe in der halben Zeit.
(ja ich weiß: blödes Beispiel, aber es ist schon spät...)
 
Original erstellt von Carsten
Der Verzicht u.a. auf TruForm-Hardware, DVD-Hardware, weitgehend winkelunabhängiges AF und FP32 war es möglich, einen zweiten 4xSIMD Pixelprozessor einzubauen, der natürlich der Performance zugute kommt.
NV35 kann auch pro Takt 8 arithmetische PS.2.0-Ops ausführen.

NV35 hat afaik mehr Transistoren als R350, (ebenso hat NV30 mehr als R300) aber NV kann die GPUs trotzdem höher takten. Es gibt keinen direkten Zusammenhang zwischen Transistor-Count und Taktbarkeit. (Der genutzte Produktions-Prozess spielt eine entscheidene Rolle, natürlich sind auch die Optimierungskünste der Entwickler gefragt.) Offensichtlich war bei ATI Priorität, Transistoren zu sparen, wo es nur geht. Wohl nicht ohne Grund. Mit besseren Filtern wären diese für den 0.15-er Prozess erstaunliche Taktrate wahrscheinlich nicht zu bekommen gewesen. Andererseits sind die Karten ohnehin so brutal schnell, könnte man da nicht 10, ja sogar 15% Geschwindigkeit opfern, wenn man im Gegenzug perfekte iso- und anisotrope Filter bekäme?

Original erstellt von Carsten
Und daß ein Chip mit 8 (Shader-)Pipes schneller ist, als einer mit 4 (Shader-)Pipes, ist doch klar.
Sorry, aber das ist gar nicht klar :) Mit 8x1 ist man gegenüber 4x2 dann im Vorteil, wenn bilineares Single-Texturing genutzt wird. Für die Pixelshader-Leistung ist wichtig, wieviele Anweisungen pro Takt verarbeitet werden. R300 kann pro Takt 8 Texture-Ops und 8 arithmetische Ops verarbeiten. Normalerweise ist der arithmetische Teil deutlich länger, die Arithmetik-Power ist das, was zählt. NV35 kann ja pro Takt 8 Texture-Ops und 4 arithmetische, oder 0 Texture-Ops und 8 arithmetische Ops verarbeiten. Die Nachteile bezüglich sind wie gesagt nicht so wichtig (das reißt der Takt mehr als raus.) Die Gründe für ATIs Geschwindigkeitsvorteile sind darin zu suchen, dass sie ihre Pipes deutlich besser auslasten können, während die FXe "Blasen", also Leertakte durch die Pipe schieben. Nvidias supertolle Ideen brachten eine superlange Pipe mit superkomplizierten Optimierungsregeln. ATIs HW profitiert sozusagen davon, dass sie gegenüber CineFX ziemlich "simpel" ist, also auch leicht zu verstehen und man kann leicht auf sie optimieren.

Dass das "Granulat" bei 8x1 ggü. 4x2 etwas feiner ist (also 1 PS-Stage vs. 2 PS-Stages pro Pipe) spielt angesichts der Shaderlängen eigentlich keine Rolle.
 
Zuletzt bearbeitet:
Original erstellt von aths
NV35 kann auch pro Takt 8 arithmetische PS.2.0-Ops ausführen.

Ja, bis zu acht. Die R300 Chips können das neben ihren acht Texturinstruktionen auch noch und unter besonderen Umständen, die ich aber nicht kenne, sollen sie ja bis zu 24 Operationen pro Takt (also drei pro Shaderpipe und Takt) hinbekommen.


Original erstellt von aths
NV35 hat afaik mehr Transistoren als R350, (ebenso hat NV30 mehr als R300) aber NV kann die GPUs trotzdem höher takten. Es gibt keinen direkten Zusammenhang zwischen Transistor-Count und Taktbarkeit. (Der genutzte Produktions-Prozess spielt eine entscheidene Rolle, natürlich sind auch die Optimierungskünste der Entwickler gefragt.) Offensichtlich war bei ATI Priorität, Transistoren zu sparen, wo es nur geht. Wohl nicht ohne Grund. Mit besseren Filtern wären diese für den 0.15-er Prozess erstaunliche Taktrate wahrscheinlich nicht zu bekommen gewesen. Andererseits sind die Karten ohnehin so brutal schnell, könnte man da nicht 10, ja sogar 15% Geschwindigkeit opfern, wenn man im Gegenzug perfekte iso- und anisotrope Filter bekäme?

Erbsenzähler. Vergleiche machen natürlich nur Sinn, wenn man von ansonsten identischen Umständen ausgeht.
Und 10-15% würden den R3xx die Kronen in etlichen der ansonsten sehr knappen <DX9-Benches kosten und damit wäre das Primärziel des Chips klar verfehlt gewesen.

Original erstellt von aths
Sorry, aber das ist gar nicht klar :)

Docj, das ist es. Wenn man im Worst-Case so 'gut' ist, wie das Gegenüber im Optimalfall, dann ist die Entscheidung zu 8x1 ggü. 4x2 eine win-loss Situation, besser geht es nicht.

Original erstellt von aths
Mit 8x1 ist man gegenüber 4x2 dann im Vorteil, wenn bilineares Single-Texturing genutzt wird. Für die Pixelshader-Leistung ist wichtig, wieviele Anweisungen pro Takt verarbeitet werden. R300 kann pro Takt 8 Texture-Ops und 8 arithmetische Ops verarbeiten. Normalerweise ist der arithmetische Teil deutlich länger, die Arithmetik-Power ist das, was zählt. NV35 kann ja pro Takt 8 Texture-Ops und 4 arithmetische, oder 0 Texture-Ops und 8 arithmetische Ops verarbeiten. Die Nachteile bezüglich sind wie gesagt nicht so wichtig (das reißt der Takt mehr als raus.) Die Gründe für ATIs Geschwindigkeitsvorteile sind darin zu suchen, dass sie ihre Pipes deutlich besser auslasten können, während die FXe "Blasen", also Leertakte durch die Pipe schieben. Nvidias supertolle Ideen brachten eine superlange Pipe mit superkomplizierten Optimierungsregeln. ATIs HW profitiert sozusagen davon, dass sie gegenüber CineFX ziemlich "simpel" ist, also auch leicht zu verstehen und man kann leicht auf sie optimieren.

Deswegen simplifizierte ich auch, indem ich schrieb: "(Shader-)Pipelines" und nicht "Pixelpipelines".

Original erstellt von aths
Dass das "Granulat" bei 8x1 ggü. 4x2 etwas feiner ist (also 1 PS-Stage vs. 2 PS-Stages pro Pipe) spielt angesichts der Shaderlängen eigentlich keine Rolle.

Die Granularität kommt bei konventionellen ST- oder MT-Situationen aber wieder dem 8x1-Design zugute, während es bei bis zu 24 Shader-Ops pro Takt offensichtlich auch der Geschwindigkeit nicht abträglich ist.
 
Original erstellt von Carsten
Ja, bis zu acht. Die R300 Chips können das neben ihren acht Texturinstruktionen auch noch und unter besonderen Umständen, die ich aber nicht kenne, sollen sie ja bis zu 24 Operationen pro Takt (also drei pro Shaderpipe und Takt) hinbekommen.
Kommen bestimmte arithmetische Ops hintereinandern, können doppelt so viele Ops so viele pro Takt ausgeführt werden, also 16. (Plus 8 Texture-Ops = 24.) Mehr arithmetische Ops pro Takt beherrscht die FX prinzipiell auch. Das geht, weil die arithmetische Stage auch komplizierte Ops in einem Takt berechnen können soll (der Sinus dauert beim R350 nichtsdestotrotz mehrere Takte.) Man kann die einzelnen rechnenden Units in bestimmten Fälle auf zwei Befehle aufteilen, so dass man auf die doppelte arithmetische Power kommt. Beim NV30 (und NV35) teilen sich Texture-Op-Stages und arithmetische Stages ja Rechenunits, doch zwei "zusammengefasste Texture-Ops" für eine arithmetische Op sind nicht so mächtig, dass sie zwei arithmetische Ops ausführen können, das gilt lediglich für die "normalen" reinen arithmetischen Units bei CineFX2. Letztlich ver-eins-komma-fünf-facht sich dann die arithmetische Leistung.
Original erstellt von Carsten
Erbsenzähler. Vergleiche machen natürlich nur Sinn, wenn man von ansonsten identischen Umständen ausgeht.
Sie sind ja nicht identisch :) Deshalb möchte ich ja die Kausalität gewahrt wissen. "Identische" Umstände sind ohnehin praktisch nicht zu gewährleisten. Ein Mehr an Transistoren macht die GPU nicht zwangsläufig langsamer, bekanntlich bekam Kyro2 ca. 3 Mio Transistoren mehr, bei identischem Featureset, um den Chip höher zu takten. Man könnte u. U. zusätzliche Transistoren für's Filtern durch weitere Transistoren ausgleichen, um den Takt zu erhalten. Aber ok, das ist bei den heutigen Transistor-Monstern wahrscheinlich impraktikabel.

Was meinst du mit "Und das kann wohin führen.... ?" Riptor schiebt scheinbar (vielleicht irre hier) die R350-PS.2.0-Geschwindigkeits-Vorteile vor allem auf "FP24 statt FP32", anstatt auf die tatsächlichen Umstände. Dass FP32-Logik mehr Transistoren kostet und sich das dadurch auch irgendwo auf den Speed auswirken wird, ist klar, aber weil die konkreten Umstände alles andere als "identisch" sind, ist es imo nicht sinnvoll, über den Transistorcount so zu reden als sei er der Hauptverantwortliche für die erreichbare Taktrate.

Insofern kann ich angesichts der Tatsache, dass die Umstände alles andere als gleich sind, deine Einlassung auf meiner Bemerkung zu Riptor hin nicht so recht verstehen. Könntest die Hintergedanken ausführen, anstatt den Vorwurf der Erbenszählerei zu bringen...?

Riptor scheint von einem seriellen Rechenwerk auszugehen, was aber falsch ist. Selbst wenn die Durchlaufzeit sich erhöht, was beim Shaderwechsel dann auch zusätzliche Latenzen bedeutet, also die Leistung senkt, einmal geladen macht die Pipe pro Takt eine bestimmte Anzahl an Ops in voller Breite, FP32 kostet ggü. FP24 dann natürlich mehr Transistoren. Das mit den Latenzen ist aber auch so'ne Sache — CineFX kann die Latenzen von Dependend Reads sehr gut in der Pipe "verstecken", wodurch diese aber wieder anfälliger wird, wenn bestimmte Optimerungs-Regeln verletzt werden.


Original erstellt von Carsten
Und 10-15% würden den R3xx die Kronen in etlichen der ansonsten sehr knappen <DX9-Benches kosten und damit wäre das Primärziel des Chips klar verfehlt gewesen.
Das ist nicht der Ansatz für den Artikel. <DX9-Benches, da sind die Frameraten imo bereits so hoch, dass 10-15% so entscheidend nicht mehr sind, wenn man die Spiele-Praxis im Auge hat. Du weißt, dass ich hinterfrage, was für den Kunden sinnvoll wäre, und nicht, mit welcher Methode das Unternehmen die größte Stückzahl absetzt. Ist imo ganz in der Tradition von 3DC, und ich bin froh, dass Leo mir eine Plattform für meine vielleicht noch etwas weiter "abgehobene" Sicht der Dinge gibt. Das muss imo auch mal sein, in der ziemlich vom Kommerz geprägten Web-Landschaft.

Falls mein Ansatz, hohe Genauigkeitsanforderungen an die HW zu stellen, die über bloße Spieletauglichkeit hinaus gehen, als zu perfektionistisch gesehen wird, sehe ich das gar nicht mal als schlimmen Vorwurf. Letztlich schwang im Artikel, wenn auch nicht direkt ausgesprochen, mit, dass die R300-Schiene eine (gute!) HW für hier und jetzt ist, in dieser Form aber nicht zukunftstauglich ist. Darüber zog ich keine Bewertung, also kein Urteil, ob man lieber schnelle hier+jetzt oder langsamere morgen+irgendwann Hardware nehmen sollte. Natürlich stellte ich mehr oder minder direkt die Forderung nach besseren Filtern. Das AF bleibt imo für das Jahr 2003 unangemessen, von den im Artikel als erste gezeigten Artefakten beim BF ganz zu schweigen. Jedenfalls interessiert es mich jedenfalls herzlich wenig, welche Primärziele ATI mit diesem Chip hatte. Sucht man sich für alles den richtigen Kontext, ist die FX 5200 plötzlich ein toller Chip, zumal NVs die damit verknüpften Primärziele offenbar erreicht... das ist mein Ansatz nicht, wie du weißt.

Original erstellt von Carsten
Docj, das ist es. Wenn man im Worst-Case so 'gut' ist, wie das Gegenüber im Optimalfall, dann ist die Entscheidung zu 8x1 ggü. 4x2 eine win-loss Situation, besser geht es nicht.
Ist es praktisch (bei den relevanten Shader-Längen) nicht wirklich. Letztlich spart man z.B., you get it :), Transistoren.
Original erstellt von Carsten
Deswegen simplifizierte ich auch, indem ich schrieb: "(Shader-)Pipelines" und nicht "Pixelpipelines".
Es ist ziemlich Wurst, ob man 8 Shader-Pipes mit 1 PS-Stage, oder 4 Pipes mit 2 Stages hat (ebenfalls simplifizierend ausgedrückt.) Das 8x1-Design hat Vorteile, die sind aber nicht Welt bewegend. R300s 8x1 ist ggü. dem 4x2 vom NV30 klar im Vorteil, weil NV30 pro Takt nur 4 arithmetische 2.0-Shaderops (statt 8, wie R300) berechnen kann, aber fast gar nicht, weil die TMUs zu 4x2 angeordnet sind.
Original erstellt von Carsten
Die Granularität kommt bei konventionellen ST- oder MT-Situationen aber wieder dem 8x1-Design zugute, während es bei bis zu 24 Shader-Ops pro Takt offensichtlich auch der Geschwindigkeit nicht abträglich ist.
Wie gesagt, die "24" Ops gelten nur unter bestimmten Umständen. In der Regel ist der arithmetische Block länger als der Sampling-Block, demzufolge zählt die arithmetische Power eher. NV35 kann unter Sonder-Umständen 8 Texture-Ops und 8 arithmetische, oder 0 Texture Ops und 12 arithmetische Ops ausführen. Wenn du von einem "2. zweiten 4xSIMD Pixelprozessor" sprichst, impliziert das taktbereinigte doppelte Shader-Power ggü. der Konkurrenz, was jedoch nicht der Fall ist. (Oder, um genau zu sein, in dem "besten" Fall steht es zwar 24 vs. 12, also 2:1 für ATI. Doch die Texture-Ops nehmen bei üblichen Shadern den deutlich geringeren Teil ein, wie bekannt.)

Taktbereinigt ist beim NV35 die die "zählende" (also die arithmetische) Shaderpower nur ein bisschen schwächer, was der Takt ggü. R350 locker wieder wett machen dürfte. CineFX2 leidet darunter, dass die Pipes aufgrund strenger und hochkomplexer Optimierungsregeln zumeist stark unterausgelastet sind. (Die Texture-Op-Einheiten sind so oder so, ob beim NV35 oder R3x0, in der Regel unterausgelastet, das ist aber weniger schlimm, wenn du die Anteile in einigen Shadern vergleichst. Die Modifizierung von Textur-Koordinaten wird ab PS.1.4 ja mit den arithmetischen Ops gemacht, nicht mehr mit Texture Ops. Rechnen ist das, was zählt. Hier steht es 8 vs. 8 Ops, unter besonderen Umständen 16 vs. 12.)


Wenn man "nur" trilinear filtert, oder "nur" 2x AF nimmt, meinetwegen auch bilinear, ist es füllratentechnisch egal ob 8x1 oder 4x2, egal ob beim Single- oder Multitexturing. Bei einer ungeraden Anzahl bilinear gefilterter Texturen ohne AF ist man mit 8x1 im Vorteil, wobei der Vorteil mit zunehmender Texturzahl sinkt. Die tatsächlichen (also relativ kleinen) 4x2-Nachteile reißt NV mit dem Takt mehr als wieder raus, wenn wir mal bilineares Single-Texturing außer Acht lassen.

Wenn du Füllrate ansprichst, die Stencil-Füllrate mit aktiviertem MSAA ist beim R350 ggü. NV35 z.B. nicht gerade toll. Hier gibts ja keine Texturfilterung, da bieten NV30 bzw. NV35 8x0. In neueren Games, die auf den First-Z-Pass setzen ist die FX nicht im Nachteil (da ebenfalls 8x0) und bei Stencil Schatten der NV35 zumindest auf dem Papier deutlich im Vorteil (ebenfalls 8x0, dazu Ultra Shadow) während sie bei Uralt-Games (bilineares Single-Texturing) wegen 4x2 tatsächlich im Nachteil ist — solange man kein AF nimmt, jedenfalls... :rolleyes::
 
Zuletzt bearbeitet:
aths,

Anstatt den Quote-war weiterzuführen, was nichts bringt, ausser die Lesbarkeit und Nachvollziehbarkeit vollends zu töten, sollten wir uns mal einigen worüber wir überhaupt sprechen.

IMHO war Riptors Frage 'werkimmanent' und so war und ist auch meine Antwort zu verstehen.

"Was bringen die Einsparungen im R300 für einen Vorteil gegenüber einem fiktiven R300, der diese Einsparungen nicht hat?"

Würde dieser (fiktive R300) dadurch langsamer? Nein, nicht per se, aber in der logischen Folge schon.

Denn:
Da es sich bei dieser Betrachtung sehr wohl um identische Voraussetzungen handelt (gleiches Design-Team mit gleichen Tools etc., gleicher Fertigungsprozess, gleicher Takt-Target usw.), würde derselbe R300, wie er im Spätsommer letzten Jahres veröffentlicht wurde nur 'bereichert' um die herausgestrichenen Einsparungen durch den höheren Transistorcount langsamer zu takten sein, da es sich hier nicht um die von Robbitop so gern zitierten Massetransistoren (wie offenbar im Kyro II) handelt, sondern um Funktionseinheiten, die selbst erheblich zur Abwärmeproduktion beitragen.
Entweder also geringerer Takt (der wohl auch das geringere Übel gewesen wäre) oder Verzicht auf den zweiten Pixelprozessor, wie in der Value-Reihe 9600 geschehen, obwohl dort auch der 0,13µ Fertigungsprozess mit hineinspielt, aber als Indiz mag gelten, daß auch R9500 und R9800SE mit jeweils nur vier aktiven Pipelines keiner höheren Taktraten als ihre unverkrüppelten Vettern spendiert bekamen.

Und da ATi der Takt wohl nicht hoch genug war, haben sie ja mittlerweile mehrere Aufgüsse mit gesteigertem Takt herausgebracht, da weitere Verfeinerungen im Fertigungsprozess und bereinigte Design-Schwächen, was Transistorenverteilung angeht, dies erlaubten.
 
@ aths: Ja, jetzt ist mir das auch klarer geworden... Dennoch war es eigentlich so von mir ausgelegt worden, wie Carsten es sagt (weil der Text ja auch nicht von mir war):

"IMHO war Riptors Frage 'werkimmanent' und so war und ist auch meine Antwort zu verstehen."

... was jetzt prinzipiell EGAL ist, weil ihr mir beide nen Löffel Weisheit in den Mund gesteckt habt (Danke ;) ), was jetzt angesichts der Tatsache, dass der Quote-War "leicht" gedehnt geworden ist, für mich aber MEHR als ausreichend beantwortet worden ist (wollte nur einen Löffel ;) ).

Was mir jetzt aber noch in den Sinn gekommen ist (auch wenn es vielleicht nicht ganz zum Thema paßt, aber aths hat damit "angefangen"):

Warum wird den "Pixelpipelines" keine zweite TMU spendiert, wie dies früher immer der Fall war (bei ATIs Radeon VE - Radeon 7500 warens ja sogar 3, Parhelia sogar 4, aber dafür auch nur 4 Pipes)! Heißt das jetzt, dass es an den generellen Designvorzügen von 8*1 Architekturen gilt (bzw. den neuen, "flexiblen" Design wie z.B. bei der GFFX?)? IMO wars doch so, dass eine zweite TMU gerade die Vorzüge bei Multitexturing hat und genau DA die Füllrate verdoppeln kann, was ja mit EINER TMU nicht möglich ist (oder doch?). Wird Multitexturing weniger verwendet als früher oder ist es für die Gesamtperformance sinnvoller, auf doppelte TMUs zu verzichten, weil dadurch die Shadergeschwindigkeit zu stark sinkt?

Vielleicht wirklich etwas unpassend, aber das ist mir jetzt genau in den Sinn gekommen, bezogen auf:

"Das 8x1-Design hat Vorteile, die sind aber nicht Welt bewegend. R300s 8x1 ist ggü. dem 4x2 vom NV30 klar im Vorteil, weil NV30 pro Takt nur 4 arithmetische 2.0-Shaderops (statt 8, wie R300) berechnen kann, aber fast gar nicht, weil die TMUs zu 4x2 angeordnet sind."
 
Zuletzt bearbeitet:
Original erstellt von Riptor
Warum wird den "Pixelpipelines" keine zweite TMU spendiert, wie dies früher immer der Fall war (bei ATIs Radeon VE - Radeon 7500 warens ja sogar 3, Parhelia sogar 4, aber dafür auch nur 4 Pipes)! Heißt das jetzt, dass es an den generellen Designvorzügen von 8*1 Architekturen gilt (bzw. den neuen, "flexiblen" Design wie z.B. bei der GFFX?)? IMO wars doch so, dass eine zweite TMU gerade die Vorzüge bei Multitexturing hat und genau DA die Füllrate verdoppeln kann, was ja mit EINER TMU nicht möglich ist (oder doch?). Wird Multitexturing weniger verwendet als früher oder ist es für die Gesamtperformance sinnvoller, auf doppelte TMUs zu verzichten, weil dadurch die Shadergeschwindigkeit zu stark sinkt?
Eine TMU kostet Transistoren. R300 bzw. R350 haben 8 TMUs, NV30 bzw. NV35 haben 8 TMUs. Es sind jeweils bilineare TMUs. Pro Takt können beide also die gleiche Anzahl an Texeln erzeugen. Zu Voodoo2-Zeiten war bilineares Filtering noch modern. Die 2. TMU brachte dann doppelte Multitexturing-Füllrate. Aber (eigentlich steht das bereits in den Postings) sofern man TF oder AF verwendet, braucht man ohnehin mehr als 1 bilineares Sample pro Pixel. Da ist es füllratentechnisch egal, ob man 2 TMUs für 1 TF-Sample nimmt, oder 1 TMU über 2 Takte beansprucht (via Loopback.)

Ganz ähnlich mit der Shader-Geschwindigkeit: Ob nun in 8 Pipes pro Takt je 1 arithmetische Op, oder in 4 Pipes je Takt 2 arithmetische Ops gerechnet werden können, ist ziemlich egal.

Für die Zukunft erwarte (= erhoffe) ich Architekturen mit 8 Pipes, und entweder jeweils 1 trilinearen TMU oder 2 bilinearen. Das würde die trilineare Füllrate schlagartig verdoppeln. Eine trilineare TMU kann aus zwei bilinearen bestehen, wo man jedoch bei einer etwas Logik eingesparen kann (z. B. für die Koordinaten-Berechnung) oder aus einer TMU, die einen 4x4-Filter appliziert (= interne Bandbreiten-Anforderung steigt sehr stark, dafür kann man aus einer MIP-Map trilinear filtern.)
 
Zuletzt bearbeitet:
Wenn's auch OT ist: Das Bandbreiten-Problem darf natürlich nicht vergessen werden. GeForce2 GTS führte 4x2 ein, bei 128 Bit DDR. Die Bandbreite reichte vorne und hinten nicht, erst mit LMA (GeForce3) bzw. HyperZ II (Radeon 8500) wurde die Füllrate auch tatsächlich nutzbar (auf 32-Bit-Rendering bezogen jedenfalls.)*

Radeon 9700 und GeForce 5900 haben 8 TMUs bei 256 Bit DDR. Sieht nach Unterauslastung aus. In der Tat ist da noch Luft. Verdoppelt man nun gleich die Render-Architekturbreite (auf 8x2 z. B.) wird 256 Bit DDR für reines Multitexturing schon wieder grenzwertig. Aaaber, das tritt in den Hintergrund, wenn

- Lange DX9-Shader zum Einsatz kommen
- Die HW "vernünftig" designt ist.

Denn lange arithmetische Rechnungen sind praktisch Bandbreiten-frei, jetzt muss die Pipe nur so gestaltet sein, dass in diesen Zeiten die Texturen für die nächsten Pixel gesampelt werden. Ich denke, dass das 256 Bit-DDR-Interface auch dann noch lebt, wenn die Grakas längst 512 MB RAM haben werden.

* Anekdote 1: Die GeForce2-Füllraten, die von Nvidia genannt wurden, gelten natürlich nur für synthetische Benchmarks, das kann man sich ja denken. Sie gelten aber außerdem nur für's 16-Bit-Rendering, obwohl die Karten ja so als tolle 32-Bit-Karten beworben wurden. Dass die da Füllrate direkt mit dem RAM-Interface skaliert, wusste ich anfangs auch nicht.

Anekdote 2: NVidia gibt für den NV25U an: 4,8 Mrd. AA-Samples. Wie kommen die Zustande? Klar: 4 Pipes und 4x MSAA. Dank 4 ROPs pro Pipe könnten in der Tat pro Takt und Pipe 4 MSAA-Samples die Pipe verlassen, also 16 Samples insgesamt. Bei einem 128-Bit-DDR-Interface werden pro Takt 256 Bit an Daten übertragen. Das heißt, die 16 Samples sind nur dann möglich, wenn man im 16-Bit-Modus und mit abgeschaltetem Z-Buffer rendert...

Damit will ich eigentlich nur sagen, ganz ohne weiteres kann man nicht einfach mal die Zahl der TMUs verdoppelt, wenn die Leistung auch beim User ankommen soll. R3x0 mit 8x2 auszustatten wäre deutlich aufwändiger, als 8x1 mit "Lehrbuch-Filtern".
 
Zuletzt bearbeitet:
Zurück
Oben