ATIs Tesselations Vereinfachung und die Konsequenzen

[Avalox]

Das aktuelle Tesselationsbeispiel von ATI zeigt ja, dass sich der Verabeitungsaufwand durch gezieltes "weglassen" ungemein vereinfachen lässt, ohne größere Einbussen in der Bildqualität hinnehmen zu müssen.


Deshalb kommt mir doch gleich die Frage in den Sinn?


Hat schon mal jemand überprüft, ob dieser bei ATI gefeierte Ansatz, nicht schon immer in den Lösungen anderer Hersteller zur Tesselation von Anfang an Bestandteil war?

[=Floi=]

welches beispiel? Die maximale tesselationstiefe zu begrenzen?

Der ansatz ist eben nicht brauchbar, weil eben genau da wo es gebraucht wird auch höher tesseliert werden soll.
Man sollte bei den optimierungsmöglichkeiten über den treiber wirklich abwarten was da möglich wird und wie ati es da genau macht.

[Avalox]

Der ansatz ist eben nicht brauchbar, weil eben genau da wo es gebraucht wird auch höher tesseliert werden soll.

Was heißt "nicht brauchbar"?
Die Frage ist doch, fällt es auf, oder fällt es nicht auf?
Wenn es nicht auffällt, kommt auch niemand auf die Idee genauer hinzusehen.


Gibt es denn Ansätze, z.B. mittels Referenz Renderer, nach weggelassener Tesselation in Referenz Situationen zu suchen?


Wenn ich mir so die aktuelle Grafik so ansehe, dann frage ich mich doch immer, wie das Ergebnis zusammen gesetzt ist? Eben wie viel Anteil des Ergebnis in der GPU steckt und wie viel Anteil des Ergebnis aus den verwendeten Software Algorithmen stammt.

Und gezielt "weglassen" ist schon immer eine sehr erfolgsversprechende Lösungsstrategie gewesen.

[=Floi=]

coda hat dazu etwas im anderen thread geschrieben. wenn du dir da die letzten 5 seiten durchliest, dann wirst du es auch begreifen.
der schalter im treiber lässt eben nicht etwas gezielt weg, sondern begrenzt nur den maximalen level. der "abnehmende grenzertrag" erledigt dann den rest.

ich hoffe coda schreibt dazu einen 3-4 seitigen kurzen artikel um es mehr leuten näher zu bringen.

[Darlie]

@Avalox
Du willst doch nicht andeuten das ein anderer Hersteller z.B. Nvidia sein könnte und ein gezieltes weglassen schon im Treiber implementiert ist? :confused:

[Avalox]

coda hat dazu etwas im anderen thread geschrieben. wenn du dir da die letzten 5 seiten durchliest, dann wirst du es auch begreifen.
der schalter im treiber lässt eben nicht etwas gezielt weg, sondern begrenzt nur den maximalen level.

?

Er lässt Details weg. Die Begrenzung sorgt, im Vergleich mit einem Referenzbild mit komplett gerenderten Tesselationslevel für weniger Details.

Dieses fällt je nach Situation kaum auf.


Nur ist die Frage ob, dieses was AMD dort vorhat nicht schon längst ähnlich von anderen Herstellern schon längst eingesetzt wird? z.B. eine Szenen dynamische Begrenzung des Tesselationslevels.

Wären solche "Weglass" Optimierungen heute schon jemanden aufgefallen? Wahrscheinlich nicht. Hat deshalb schon mal jemand die einzelnen Implementierungen der Hersteller systematisch auf solche Vereinfachungen untersucht?




@Avalox
Du willst doch nicht andeuten das ein anderer Hersteller z.B. Nvidia sein könnte und ein gezieltes weglassen schon im Treiber implementiert ist? :confused:


Na warum denn nicht? Muss auch nicht nVidia sein.


Man kommt mit der Technologie später auf dem Markt, weiß genau, dass diese Technik geradezu danach schreit ein Performancefresser zu sein und hat einen guten Überblick darüber was der Wettbewerber so macht.

Da liegt es doch Nahe, dass ein Team parallel beschäftigt wird, nach Optimierungswegen suchen zu lassen, um die Tesselation im Ergebnis zu beschleunigen, um eben einen Vorsprung vor der Konkurrenz zu haben.


Ich bin jedenfalls von den Ergebnissen überraschend beeindruckt. Wenn man diesen Ansatz nun dynamisch kombiniert, mit einer Situationsanalyse auf dem Bildschirm, dann hat man eine prächtige Performancesteigerung.



Deshalb muss doch die Frage gestellt werden, ob dieses was ATI nun so groß ankündigt, nicht schon längst so, oder so ähnlich beim Wettbewerb Einzug gehalten hat und ATI nur nachlegt?

[Tigerchen]

Gibt es einen handfesten Grund weshalb du dich so aus dem Fenster lehnst?
Wenn andere heimlich optimieren wäre das schon ein Hammer.

Hat sich eigentlich nV schon zu der Treiberoption von ATI geäußert? Oder halten die die Füße still?

[Avalox]

Gibt es einen handfesten Grund weshalb du dich so aus dem Fenster lehnst?


Nein überhaupt nicht.

Ich finde die ersten Ergebnisse der Überlegungen nur so beeindruckend, dass ich mich frage, weshalb ATI dieses nicht von Anfang an gemacht hat?

Und da fallen mir nur zwei Antworten ein.

Zum einen war man so geil, schnell auf den Markt zu kommen, dass man sich nahe der Referenzimplementierung gehalten hat und man zudem natürlich nicht die zukünftige Bedeutung der Tesselation ganz überblicken konnte.

Bloss diese Antworten gelten ja nicht für jemanden, der später mit seiner Lösung am Markt eintritt in der Form.

Also wenn ATI es zum Anfang nicht gemacht hat, weshalb haben es die anderen späteren Marktbegleiter nicht gemacht? Und dort fällt mir gar keine vernümftige Antwort ein. Also haben sie es ja vielleicht gemacht und nur nicht erzählt?

[Ailuros]

Deshalb muss doch die Frage gestellt werden, ob dieses was ATI nun so groß ankündigt, nicht schon längst so, oder so ähnlich beim Wettbewerb Einzug gehalten hat und ATI nur nachlegt?

Welche andere desktop GPU oder desktop SoC unterstuetzt DX11 Tessellation ausser AMD und NVIDIA?

NV hat es nicht noetig irgend etwas zu optimieren, eben genau weil es einen ziemlich grossen Unterschied in der Effizienz ihrer Tessellations-Implementierung gibt im Vergleich zu AMD.

Ich weiss nicht wie Du auf solche Schnappsideen kommst, aber ausnahmsweise mal einen sw Entwickler zu fragen der nicht parteisch denkt wuerde schon helfen das obrige zu bestaetigen.

Aber wenn Du schon bunte Konspirations-thesen im Vacuum entwickeln willst: NV's Tessellation ist ein reiner sw-Mechanismus, sie bescheissen bis zum geht nicht mehr und Larabee haette alles vernichtet wieder auf sw-Basis und endloser sw-cheaterei. Ach ja und Elefanten koennen doch fliegen.... :rolleyes:

[Avalox]

..:

habe zwar jetzt nicht die Idee, was der Softwareentwickler damit im Detail zu tun hat, es sei er arbeitet bei nVidia hat einen Überblick und darf zudem was erzählen.

Aber wie auch immer, die Tesselations-Vereinfachungen die nun im Gespräch sind, zeigen schlicht die Notwendigkeit, dass diese auch nachweislich erkannt und aufgezeigt werden können.
Glauben hin oder her.
Ein entsprechenden Test kenne ich aber nicht.

[Iruwen]

Sieht man nicht im Wireframe Modus dass NV nichts "optimiert"?

[Gipsel]

Ich bin zwar immer dafür, auch ungewöhnlichen oder überraschenden Gedankengängen zu folgen. Aber die Richtung, in die das jetzt geht, ist doch ein wenig absurd. In entsprechenden "directed tests" würde das auch recht schnell auffallen. Also heimlich ist schwierig.

[Hugo78]

Ich weiß wer Kennedy ermordet hat, aber schiebs AMD in die Schuhe.

[dargo]

Was heißt "nicht brauchbar"?
Die Frage ist doch, fällt es auf, oder fällt es nicht auf?
Wenn es nicht auffällt, kommt auch niemand auf die Idee genauer hinzusehen.

Oh... ja dann könnten wir so Einiges weglassen. Zb. 8xMSAA oder 16xAF oder, oder. Schließlich fällt vielen bei solchen Settings kein Unterschied auf. :rolleyes:

[Avalox]

Oh... ja dann könnten wir so Einiges weglassen. Zb. 8xMSAA oder 16xAF oder, oder. Schließlich fällt vielen bei solchen Settings kein Unterschied auf. :rolleyes:

Das wird doch gemacht. Nur, dass der Benutzer dieses transparent einstellen kann.

Man muss auch nur mal die tatsächlichen abweichenden Implementierungen der anisotropen Filterung im Vergleich mit der Referenz betrachten. Welches zudem erst in den Fokus rückte, nachdem die Thematik etwas bekannter wurde.

Das ist ein ziemlich passendes Beispiel, man darf nur nicht die heutige Situation betrachten.

Was der Hersteller so alles in seine Treiber einbaut ist völlig untransparent.

So werden z.B. die ganzen Sonderbehandlungen für Spiele, Benchmarks und ähnliches im Treiber, weder einzeln für die betroffenen Produkte genannt, noch wird irgendwo aufgelistet, was diese "Sonderbehandlungen" abweichend zur normalen Treiberbehanldung im Detail verändert.


Nein, die Informationspolitik der Hersteller ist schlecht, bewusst schlecht.
Und eine Motivation für solche Maßnahmen unterstelle ich immer und überall.
Zumal in diesem Fall der Nutzen auf der Hand liegt. Dieses sogar noch in mehreren Punkten.

Die Frage ist doch, kann es jemand unabhängig und nachweislich ausschliessen?

[=Floi=]

vergiss deinen gedankengang einfach.

[Ailuros]

Ich bin zwar immer dafür, auch ungewöhnlichen oder überraschenden Gedankengängen zu folgen. Aber die Richtung, in die das jetzt geht, ist doch ein wenig absurd. In entsprechenden "directed tests" würde das auch recht schnell auffallen. Also heimlich ist schwierig.

"Wenig"? :D

habe zwar jetzt nicht die Idee, was der Softwareentwickler damit im Detail zu tun hat, es sei er arbeitet bei nVidia hat einen Überblick und darf zudem was erzählen.

Aber wie auch immer, die Tesselations-Vereinfachungen die nun im Gespräch sind, zeigen schlicht die Notwendigkeit, dass diese auch nachweislich erkannt und aufgezeigt werden können.
Glauben hin oder her.
Ein entsprechenden Test kenne ich aber nicht.

NV's Perspektive ueber ihre eigene hw und dessen Implementierungen koennten als subjektiv empfunden werden und genau eben deshalb schlage ich vor dass eine dritte und so unabhaengig wie moeglich Quelle befragt wird.

Wenn ein sw Entwickler heute extreme Tessellation durch die eine und andere Architektur schickt ist es leicht zu sehen welche als erste schlapp macht und warum.

Die Frage ist dann eher ob man fuer die heutigen Verhaeltnisse solche Tessellations-Mengen braucht. IMHO ist AMD's Implementierung gut genug, was aber nicht heissen soll dass sie bei ihrer kommenden Generation auf hw-Ebene nicht nachladen werden.


Die Frage ist doch, kann es jemand unabhängig und nachweislich ausschliessen?

Selbstverstaendlich. Deshalb schlag ich auch einen unabhaengigen sw Experten vor.

[Darlie]

Die Treiberoptimierungen für Spiele sind aber genau dieser spekulative Fall, wir bekommen nur das zu sehen was wir sehen sollen. Nirgends wird erläutert was mit einem neuen treiber wirklich für spiel xy gepatcht wird, warum soll das nicht auch für das tesselieren so sein?
Wenn es doch total schwachsinnig sein sollte dann ist der Thread nur ein konspirativer Versuch die Klickzahlen auf 3dcenter zu erhöhen. :tongue:

[V2.0]

Wenn man die Leistungsunterschiede sieht, ist es durchaus denkbar,dass NV den Grad der Tesselation schon lange im Treiber regelt.

[y33H@]

Das sieht man viel eher an der Hardware.

[RLZ]

Die Frage ist dann eher ob man fuer die heutigen Verhaeltnisse solche Tessellations-Mengen braucht.
Das kann nur der Anwender nicht entscheiden.
Den maximalen Tesselationfaktor zu begrenzen ist nicht wie eine AF Begrenzung. Am ehesten kann man das noch mit einer Texturgröße vergleichen.
Hätten sie einen Faktor oder Bias gebaut, wäre es imo wesentlich nachvollziehbarer gewesen als den maximalen Wert festzulegen.

[Spasstiger]

Wenn man die Leistungsunterschiede sieht, ist es durchaus denkbar,dass NV den Grad der Tesselation schon lange im Treiber regelt.
Radeon HD 6970: 2 Raster-Engines und 2 Tessellatoren @ 890 MHz
GeForce GTX 460: 2 Raster-Engines und 7 Tessellatoren @ 675 MHz
D.h. die GTX 460 ist um bis 165% bei der Tessellation überlegen.
Und das spiegelt sich in den synthetischen Tessellationsbenchmarks auch einigermaßen wieder, schau z.B. hier mal die Benchmarks zur Tessellations-Demo aus dem DX11-SDK an: http://www.hardware.fr/articles/813-7/dossier-amd-radeon-hd-6970-6950-seules-crossfire-x.html.
Bei "Tessellation Ultra + DM" steht es 340 fps (GTX 460) zu 246 fps (HD 6970). Ein Vorteil von 38% für die GTX 460.
Bei adaptiver Tessellation liegt die HD 6970 vorne, weil sie natürlich in allen anderen Belangen mehr "Pferdestärken" hat und die Tessellationslast dann nicht mehr ins Gewicht fällt. Zumal die Geometrieleistung der HD 6970 ohne Tessellation deutlich über der GTX 460 liegt (1714 Mtri/s vs. 1103 Mtri/s gemäß den Benchmarks auf der Seite).

[Ailuros]

Radeon HD 6970: 2 Raster-Engines und 2 Tessellatoren @ 890 MHz
GeForce GTX 460: 2 Raster-Engines und 7 Tessellatoren @ 675 MHz
D.h. die GTX 460 ist um bis 165% bei der Tessellation überlegen.
Und das spiegelt sich in den synthetischen Tessellationsbenchmarks auch einigermaßen wieder, schau z.B. hier mal die Benchmarks zur Tessellations-Demo aus dem DX11-SDK an: http://www.hardware.fr/articles/813-7/dossier-amd-radeon-hd-6970-6950-seules-crossfire-x.html.
Bei "Tessellation Ultra + DM" steht es 340 fps (GTX 460) zu 246 fps (HD 6970). Ein Vorteil von 38% für die GTX 460.
Bei adaptiver Tessellation liegt die HD 6970 vorne, weil sie natürlich in allen anderen Belangen mehr "Pferdestärken" hat und die Tessellationslast dann nicht mehr ins Gewicht fällt. Zumal die Geometrieleistung der HD 6970 ohne Tessellation deutlich über der GTX 460 liegt (1714 Mtri/s vs. 1103 Mtri/s gemäß den Benchmarks auf der Seite).

Tessellations-Einheiten X vs. Tessellations-Einheiten Y koennte leicht zu einer Falle werden die offen zu Missverstaendnissen fuehren koennte. IMHO ist jegliche Einheit auf Fermi pro SM auf den workload jeglichen SMs angepasst, was mir erstmal vorschlaegt dass ich bei einem GF100/110 nicht 16x Mal so viel Tessellations-Logik habe als auf einem Cypress oder 8x Mal so viel wie auf einem Cayman.

Eine der Vorteile in Fermi ist IMHO dass die Einheiten ebenbuertig ueber die SMs verteilt wurden und da diese auch zwischeneinander mit einer quasi OoO Logik kommunizieren.

Damien Triolet's Beispiel ist uebrigens ziemlich gut, denn er schreibt afaik solche synthetische Tests selber. Die Frage ist dann eben eher ob er irgendwelche Tips dafuer von NV bekommen hat, aber es verstrickt weiterhin nur jegliche absurde Konspirations-Thesen.

Die eigentliche Frage ist ob Fermi mehr Tessellations-Mengen bearbeiten kann als Cypress bzw. Cayman und hier ist die Antwort deutlich ja.

Das kann nur der Anwender nicht entscheiden.
Den maximalen Tesselationfaktor zu begrenzen ist nicht wie eine AF Begrenzung. Am ehesten kann man das noch mit einer Texturgröße vergleichen.
Hätten sie einen Faktor oder Bias gebaut, wäre es imo wesentlich nachvollziehbarer gewesen als den maximalen Wert festzulegen.

So hab ich es auch nicht gemeint. Abhaengig vom Anwender oder was AMD durch ihren Treiber anstellen will, IMHO brauchen heutige 3D Applikationen nicht unbedingt mehr Tessellation als das was AMD's hw faehig ist.

Da wo es AMD keineswegs hilft ist die Entwicklung von zukuenftigen Spielen, wenn sie mit ihrer 28nm Generation mit weit besserer Tessellations-hw antanzen. Da wir schon bei wilden Thesen sind, macht mir diese merkwuerdige Treiber-massnahme mehr Sinn seitens AMD als allen ISVs fuer die Zukunft von jeglichen grossen Tessellations-Mengen abzuraten.

[Tigerchen]

Wird es denn nicht wieder laufen wie bei HDR? Bis es mal wirklich Standard wird in neuen Games hat eh jeder einen Beschleuniger der das mit Links erledigt.

Bis auf die üblichen 2-3 Spiele und Benchmarks die dann zum Anlass zu Glaubenskämpfen dienen.