PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD/ATI - AMD will in Zukunft über den Tessellation-Level bestimmen


Seiten : 1 2 3 [4] 5

Coda
2011-01-24, 15:40:24
Ich will von DIR Zahlen sehen, die zeigen, dass, vorallem für High-Poly Modells, es nur in Ausnahmefällen einen Vorteil gäbe es über Tessellation auf der GPU zu realisieren.
Der Vorteil ist ja primär mal nicht die Geschwindigkeit beim Rendering, sondern das automatische LOD und das man viel weniger Platz im VRAM braucht.

Gipsel
2011-01-24, 16:02:17
Was ist gerade die Diskussion?Wenn ich das wüßte. :rolleyes:
Irgendwie kann man gar keinen Einwand vorbringen, ohne das man gleich vom Hundertsten ins Tausendste kommt.
Das die gleiche tesselierte Dreieckssuppe rausgeschrieben in einen Vertexbuffer und dann gerendert ohne Tri-Limiter auf GF100 gleich schnell wäre als die Tesselationsvariante?

Zumindest würde man mehr Bandbreite brauchen, aber wenn das nicht limitiert könnte es ähnlich schnell sein. Wobei ich mir da nicht ganz sicher bin, weil bei der Tesselation evtl. besser auf die vier Tri-Setups verteilt wird.Ganz genau. Meine Aussage war, das man das nicht einfach sagen kann, daß es mit Tess schneller wird, selbst auf einer GTX580 mit einer effizienten Tessellationsimplementation. Ohne Tess kann man sich ja einen eventuell aufwendigen Domainshader sparen und im Prinzip noch die Zugriffe auf height und normal maps, also die gesparte Bandbreite für den Vertexbuffer wird dort (zum Teil) auch wieder verbraten.

Achja, die Verteilung auf die 4 Setups sollte im Prinzip gleich ablaufen. Nur bei einer extrem feinen Geometrie könnte ich mir vorstellen, daß man es schafft, da irgendwas durcheinander zu bringen. Aber ich habe dazu noch nichts in den Tests der Quadros (mit unlimitiertem Dreiecksdurchsatz) gesehen.

Gipsel
2011-01-24, 16:07:47
Der Vorteil ist ja primär mal nicht die Geschwindigkeit beim Rendering, sondern das automatische LOD und das man viel weniger Platz im VRAM braucht.Ja. Und einen großen Anteil der Ersparnis erreicht man eben auch schon bei recht moderaten Tessfaktoren. Ob man jetzt 95% oder 99% spart, macht für heute realistische Szenarien nicht wirklich einen umwerfenden Unterschied. Das war mein Punkt.

LovesuckZ
2011-01-24, 16:08:18
Warum zweifelst Du es denn an? Irgendwie wird mir das zu blöd.

Ich zweifel doch garnicht daran. Woran ich zweifel, ist die Aussage, dass es nur in Ausnahmefällen ein Leistungsvorteil erbringt. Und hier will ich Zahlen sehen.

Es ist also alles andere als trivial, mit Tessellation überhaupt eine höhere Performance zu erreichen, als wenn man die gleiche Dreieckszahl von vornherein ohne Tess rendert.

/edit: Und dann erkläre gleich mit, wieso AMD überhaupt es auf der GPU ausführen lässen sollte, wenn man mit einer CPU-Berechnung doch auf nVidia-Niveau läge.

Coda
2011-01-24, 16:39:20
Ach jetzt kapier ich dich.

Klar, wenn man wirklich dynamische Tesselation auf der CPU machen müsste wäre das natürlich grottenlangsam.

Gipsel
2011-01-24, 17:37:51
Ach jetzt kapier ich dich.

Klar, wenn man wirklich dynamische Tesselation auf der CPU machen müsste wäre das natürlich grottenlangsam.
Hmm, also ich bin nicht sicher, daß LS genau das meinte (also ich habe davon bestimmt nicht geschrieben, weswegen ich auch überhaupt nicht kapiert habe, welche Belege er da von mir wollte). Aber die Antwort mit den allgemeinen Vorteilen von Tess hast Du ja bereits gegeben.

Irgendwie muß ich wohl noch an meiner Ausdrucksfähigkeit arbeiten. Obwohl das Krümelmonster doch eigentlich mein Argument der diminishing returns doch auch auf Anhieb verstanden hat. Kurz, einen Großteil der Vorteile kann man bereits bei relativ kleinen Tessfaktoren einsacken. Die zusätzlichen Ersparnisse werden mit steigendem Tessfaktor relativ gesehen immer kleiner. Und wenn die Modelle sowieso noch ein paar mehr Polys haben, da sie auch ohne Tess mit DX10 noch passabel aussehen sollen, dann ist der Fall eigentlich klar und auch anders gelagert, als wenn dann mal DX11 only Spiele rauskommen.

DrFreaK666
2011-01-24, 17:41:11
... Und hier will ich Zahlen sehen.
...


57378723985723498
35786258
342857234857
5397³

zufrieden?? :biggrin:
Ich glaube, ich habe schon ein paar Posts mit solchem Spam von Dir gelöscht. Das nächste mal gibt's was dafür von mir zurück.

DrFreaK666
2011-01-24, 17:49:27
LovesuckZ will irgendwelche Zahlen von dir sehen.
Was hat das genau mit dem Thema zu tun??

AMD will uns die Möglichkeit geben den Tess-Grad selbst zu bestimmen. Darum gehts, oder nicht???
Gibt sicherlich schon einige Tess-Threads, worin man über die Leistungsfähigkeit "diskueren" kann...
Ich wollte hier die Stimmung aufbessern - hier gehts mir zu ernst zu. Ausserdem ist das meiste OT...

zum Thema: Ich find gut. Punkt

edit: Hier könnt ihr euch austoben. Zahlen gibts dort auch...
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=482279&highlight=tesselation
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=482342&highlight=tesselation
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=489935&highlight=tesselation
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=468283&highlight=tesselation

LovesuckZ
2011-01-24, 17:51:51
Hmm, also ich bin nicht sicher, daß LS genau das meinte (also ich habe davon bestimmt nicht geschrieben, weswegen ich auch überhaupt nicht kapiert habe, welche Belege er da von mir wollte). Aber die Antwort mit den allgemeinen Vorteilen von Tess hast Du ja bereits gegeben.

Irgendwie muß ich wohl noch an meiner Ausdrucksfähigkeit arbeiten. Obwohl das Krümelmonster doch eigentlich mein Argument der diminishing returns doch auch auf Anhieb verstanden hat. Kurz, einen Großteil der Vorteile kann man bereits bei relativ kleinen Tessfaktoren einsacken. Die zusätzlichen Ersparnisse werden mit steigendem Tessfaktor relativ gesehen immer kleiner. Und wenn die Modelle sowieso noch ein paar mehr Polys haben, da sie auch ohne Tess mit DX10 noch passabel aussehen sollen, dann ist der Fall eigentlich klar und auch anders gelagert, als wenn dann mal DX11 only Spiele rauskommen.

Du hast dich doch ganz klar und unmissverständlich ausgedrückt:

Außerdem "spart" man das ja auch gar nicht alles wirklich, da auch ein ansehnlicher Mehraufwand in den Hull- und insbesonderen den Domainshadern geleistet werden muß. Es ist also alles andere als trivial, mit Tessellation überhaupt eine höhere Performance zu erreichen, als wenn man die gleiche Dreieckszahl von vornherein ohne Tess rendert.

Es wäre unsinnig auf der GPU Geometrie zur erzeugen. Da stellt sich mir die Frage, warum Tessellation überhaupt in APIs aufgenommen wurden ist. Immerhin ist der Aufwand für die Umsetzung immens, wo die CPU es annährend gleichwertig erledigen könnte.
Auch deine Aussagen über den benötigen Level spricht Bände. Widerspricht dies sogar AMD's Vorgehen in der Vergangenheit, die ein Level von 16 (oder war es 32?) unterstützten.

S940
2011-01-24, 17:55:59
Hmm also wenn ich mich als LS Interpret betätigen darf:

Ich glaube er will nen Beweis für die "diminishing returns", da er seiner Aussage nach bereits beim Wellentest des Island Demos das Gegenteil gezeigt hätte. Ob er das wirklich irgendwo hinten belegt hat .. kA ... kann mich nicht daran erinnern, lese aber auch nicht alles mit.

Aber vielleicht versteh ich ebenfalls nur Bahnhof ^^

LovesuckZ
2011-01-24, 17:58:31
Hmm also wenn ich mich als LS Interpret betätigen darf:

Ich glaube er will nen Beweis für die "diminishing returns", da er seiner Aussage nach bereits beim Wellentest des Island Demos das Gegenteil gezeigt hätte. Ob er das wirklich irgendwo hinten belegt hat .. kA ... kann mich nicht daran erinnern, lese aber auch nicht alles mit.

Aber vielleicht versteh ich ebenfalls nur Bahnhof ^^

Nein. Ich will zahlen haben, die zeigen, dass das Erzeugen von Geometrie auf der GPU nur in Ausnahmefällen schneller ist als das "offiline" Erzeugen durch die CPU.
Eine GTX580 ist in Stone Giant mit "high" knapp doppelt so schnell als eine 6970. Warum sollte man also die Geometrie auf der GPU erzeugen lassen, wenn man per CPU auf GTX580 Niveau liegen könnte? nVidia hätte sich dem Aufwand bei Fermi komplett sparen können.

DrFreaK666
2011-01-24, 17:59:38
Nein. Ich will zahlen haben, die zeigen, dass das Erzeugen von Geometrie auf der GPU nur in Ausnahmefällen schneller ist als das "offiline" Erzeugen durch die CPU.
Eine GTX580 ist in Stone Giant mit "high" knapp doppelt so schnell als eine 6970. Warum sollte man also die Geometrie auf der GPU erzeugen lassen, wenn man per CPU auf GTX580 Niveau liegen könnte? nVidia hätte sich dem Aufwand bei Fermi komplett sparen können.

Und das hat genau NULL mit dem Thread zu tun!!!!
Wieso ich dann ne "Ohrfeige" bekomme versteh ich nicht

LovesuckZ
2011-01-24, 18:01:15
Und das hat genau NULL mit dem Thread zu tun!!!!
Wieso ich dann ne "Ohrfeige" bekomme versteh ich nicht

Und dieser Thread steht immerhin im "Diskussionsforum". Leichte Abschweife sollte man wohl erlauben. AMD spezifisch kann man doch im Unterforum bereden.

DrFreaK666
2011-01-24, 18:02:27
Und dieser Thread steht immerhin im "Diskussionsforum". Leichte Abschweife sollte man wohl erlauben. AMD spezifisch kann man doch im Unterforum bereden.

Man kann auch einen neuen Thread eröffnen, der genau zum Thema passt...

Tesseract
2011-01-24, 18:14:27
Nein. Ich will zahlen haben, die zeigen, dass das Erzeugen von Geometrie auf der GPU nur in Ausnahmefällen schneller ist als das "offiline" Erzeugen durch die CPU.

es geht doch garnicht um das erzeugen auf der CPU. entweder, du hast die tessellierten vertices durch parameter beschrieben, dann erzeugt die GPU sie "aus dem nichts" indem sie berechnet werden, oder alternativ dazu kannst du das komplette mesh vorberechnen und in den vram laden und von da normal raus zeichnen. letztere variante ist prinzipiell schneller weil die graka einfach ein polygon nach dem anderen zeichnet bis der vertexbuffer durch ist. das problem an der variante ist halt, dass sie a) unflexibler ist und b) den vram zumüllt (bei den polygonzahlen die bei ordentlicher tessellation anfallen kann reden wir hier schnell mal von 1+ GB vram nur für vertices) und das ist genau genommen auch keine tessellation mehr.
die tessellation selbst on-the-fly auf die CPU auszulagern ist natürlich grottenlangsam weil alles zig mal über den PCI-bus muss. davon redet aber doch niemand.

LovesuckZ
2011-01-24, 18:28:47
es geht doch garnicht um das erzeugen auf der CPU. entweder, du hast die tessellierten vertices durch parameter beschrieben, dann erzeugt die GPU sie "aus dem nichts" indem sie berechnet werden, oder alternativ dazu kannst du das komplette mesh vorberechnen und in den vram laden und von da normal raus zeichnen. letztere variante ist prinzipiell schneller weil die graka einfach ein polygon nach dem anderen zeichnet bis der vertexbuffer durch ist. das problem an der variante ist halt, dass sie a) unflexibler ist und b) den vram zumüllt (bei den polygonzahlen die bei ordentlicher tessellation anfallen kann reden wir hier schnell mal von 1+ GB vram nur für vertices) und das ist genau genommen auch keine tessellation mehr.
die tessellation selbst on-the-fly auf die CPU auszulagern ist natürlich grottenlangsam weil alles zig mal über den PCI-bus muss. davon redet aber doch niemand.

Als Laie ist es schwer richtig zu beschreiben. Aber das "Offline"-Verfahren ist ja genau das, was Gipsel hier als Primärverfahren haben will. Und da stellt sich dann einem die Frage, warum überhaupt Tessellation in der jetzigen Form als Pflichtfeature in APIs aufgenommen wurden ist. Denn einem visuellen Vorteil bringt es nicht, wenn ein Großteil des optischen Outputs "Offline" erstellt wird. Auf Umsetzungen wie in Stalker, AvP, Dirt:2, Metro2033 und auch Lost Planet 2 kann man als PC-Spieler vollends verzichten.

Gipsel
2011-01-24, 18:36:37
AMD will uns die Möglichkeit geben den Tess-Grad selbst zu bestimmen. Darum gehts, oder nicht???
Ganz genau.
Gibt sicherlich schon einige Tess-Threads, worin man über die Leistungsfähigkeit "diskueren" kann...
Ich wollte hier die Stimmung aufbessern - hier gehts mir zu ernst zu. Ausserdem ist das meiste OT...
Zum OT trägst auch Du bei. Mann oh Mann, Modtext-Zitat, Diskussion einer Ermahnung, Du legst es echt darauf an, oder? Bleibe bitte Ontopic und antworte lieber nicht einige Posts. Und wenn Dir das Thema des Threads nicht zusagt, schau Dir einen anderen an!

Gipsel
2011-01-24, 18:43:24
Du hast dich doch ganz klar und unmissverständlich ausgedrückt:

Es wäre unsinnig auf der GPU Geometrie zur erzeugen.
Offenbar nicht unmißverständlich für Dich. Wo habe ich etwas von unsinnig geschrieben. Ich sprach von "diminishing returns", zu deutsch dem abnehmendem Grenzertrag bei Verwendung höherer Tessfaktoren.
Da stellt sich mir die Frage, warum Tessellation überhaupt in APIs aufgenommen wurden ist. Immerhin ist der Aufwand für die Umsetzung immens, wo die CPU es annährend gleichwertig erledigen könnte.Ich habe nirgendwo nur ein Sterbenswörtchen darüber verloren, daß ich angeblich Tess auf der CPU machen wollte. Mensch, lese mal etwas aufmerksamer, was ich schreibe!
Auch deine Aussagen über den benötigen Level spricht Bände. Widerspricht dies sogar AMD's Vorgehen in der Vergangenheit, die ein Level von 16 (oder war es 32?) unterstützten.
:confused:
unterstütztes Maximum <=> sinnvoll in der Verwendung bei den meisten heutigen Anwendungen

Du erkennst den Unterschied?

Gipsel
2011-01-24, 18:46:09
AMD spezifisch kann man doch im Unterforum bereden.;D
Wieso hast Du denn den Thread "AMD will in Zukunft über den Tessellation-Level bestimmen" genannt? Soll ich das ändern?

LovesuckZ
2011-01-24, 18:58:20
Offenbar nicht unmißverständlich für Dich. Wo habe ich etwas von unsinnig geschrieben. Ich sprach von "diminishing returns", zu deutsch dem abnehmendem Grenzertrag bei Verwendung höherer Tessfaktoren.

Darauf habe ICH mich nicht bezogen.


Ich habe nirgendwo nur ein Sterbenswörtchen darüber verloren, daß ich angeblich Tess auf der CPU machen wollte. Mensch, lese mal etwas aufmerksamer, was ich schreibe!

Huch?

Du hast aber der Aussage vom Duke widersprochen, die sich spezifisch auf die kleinen bezog. Und die stimmt einfach. Und welche Faktoren relevant sind und welche nicht, hängt immer vom Content des Spiels ab. Die Aussage kann man also nicht verallgemeinern. Wenn man für DX9/10/11 sowieso Modelle mit ein paar mehr Polys als Basis nimmt, dürfte in der Praxis alles oberhalb von 8 sowieso irrelevant sein.
[...]
Um das mal ganz einfach auszudrücken, das heißt also, daß mit Faktor 32 das Basismodell nur 1 Promille der Dreiecke des finalen Modells hat, man "spart" also 99,9%, bei Faktor acht spart man aber auch schon 98,5%, die größte Ersparnis bringen also prinzipiell die kleinen Faktoren. Außerdem "spart" man das ja auch gar nicht alles wirklich, da auch ein ansehnlicher Mehraufwand in den Hull- und insbesonderen den Domainshadern geleistet werden muß. Es ist also alles andere als trivial, mit Tessellation überhaupt eine höhere Performance zu erreichen, als wenn man die gleiche Dreieckszahl von vornherein ohne Tess rendert. [...]

Du sprichst dich klar für das "Offline"-Rendering aus, jenes dann per mit kleinen Levels aufgepuscht wird.


:confused:
unterstütztes Maximum <=> sinnvoll in der Verwendung bei den meisten heutigen Anwendungen

Du erkennst den Unterschied?

Ist das ironisch? Du sagst selbst, "die größte Ersparnis bringen also prinzipiell die kleinen Faktoren". Demnach macht die Spezifikation weder heute noch in der Zukunft sinn, da ab Level 8 ein Großteil der zu leistenden Arbeit umsonst sein würde.

;D
Wieso hast Du denn den Thread "AMD will in Zukunft über den Tessellation-Level bestimmen" genannt? Soll ich das ändern?

Es ging um "Mit welcher Einstellung soll ich spielen" Themen. Genauso wie es im nVidia-Bereich getätigt wird, wenn es um AA-kompartibilität von nVidia geht. Soetwas hat hier nichts zu suchen.

Gipsel
2011-01-24, 19:00:57
Aber das "Offline"-Verfahren ist ja genau das, was Gipsel hier als Primärverfahren haben will.Ich will gar nichts haben. Hör doch mal auf mit dem Blödsinn!
Und da stellt sich dann einem die Frage, warum überhaupt Tessellation in der jetzigen Form als Pflichtfeature in APIs aufgenommen wurden ist.Das haben doch schon Coda und etwas ausführlicher und gerade eben Tesseract nochmal klar gesagt!?! Was verstehst Du denn nicht?

Gipsel
2011-01-24, 19:06:46
Wo habe ich etwas von unsinnig geschrieben. Ich sprach von "diminishing returns", zu deutsch dem abnehmendem Grenzertrag bei Verwendung höherer Tessfaktoren.
Darauf habe ICH mich nicht bezogen.Na nun reicht es aber! Du quotest mich also nur zum Spaß und Deine Posts sollen dann nichts mit dem zu tun haben, was ich geschrieben habe? Ja klar! Das kannst Du gerne woanders machen!
Du sprichst dich klar für das "Offline"-Rendering aus, jenes dann per mit kleinen Levels aufgepuscht wird.Ich und wahrscheinlich eine Menge anderer Leute hier haben keinen Plan, was Du meinst.
Ist das ironisch? Du sagst selbst, "die größte Ersparnis bringen also prinzipiell die kleinen Faktoren". Demnach macht die Spezifikation weder heute noch in der Zukunft sinn, da ab Level 8 ein Großteil der zu leistenden Arbeit umsonst sein würde.Lese meine Posts genauer! Die Bedingungen, unter denen das gilt, stehen dabei. Und jetzt höre auf mit dem Blödsinn!

Coda
2011-01-24, 19:16:16
unterstütztes Maximum <=> sinnvoll in der Verwendung bei den meisten heutigen Anwendungen

Du erkennst den Unterschied?
Gipsel, da muss ich jetzt aber auch mal was dagegen sagen. Das ist so Quatsch.

Man will ja sagen wir 0,25 Dreiecke/Pixel erreichen und das kann man mit großen Dreiecken eben evtl. nur mit hohen Tesselationsfaktoren. Hohe Tesselationsfaktoren sind also auch selbst auf kleiner Hardware je nach Ausgangsmesh alles andere als sinnlos. Die Performance wird ja nicht durch den reinen Tesselationsfaktor eingeschränkt sondern durch das Bottleneck am Tesselator/Tri-Setup/Rasterizer wenn zu viele kleine Dreiecke erzeugt werden.

Das ist definitiv der falsche Ansatz in dieser Diskussion. Wenn dann sollte man darüber streiten wie hoch die Dreiecksrate/Pixel sinnvollerweise sein sollte und daraus resultiert ja auch meine scharfe Kritik an AMD hier einfach oben abzuriegeln.

Die Sache wäre weitaus sinnvoller, wenn sie den vorgegeben Tesselationsfaktor mit einem Faktor <1 multiplizieren würden. Aber das ist halt ohne Shadermodifikation nicht möglich. Die maximale Tesselation können sie sehr einfach über ein Register regeln.

LovesuckZ
2011-01-24, 19:18:54
Na nun reicht es aber! Du quotest mich also nur zum Spaß und Deine Posts sollen dann nichts mit dem zu tun haben, was ich geschrieben habe? Ja klar! Das kannst Du gerne woanders machen!

Find' ich ironisch, dass du so etwas schreibst. :freak:
Davon abgesehen habe ich diesen Teil nicht gequotet, weil ich diesen Teil nicht kommentieren wollte.


Ich und wahrscheinlich eine Menge anderer Leute hier haben keinen Plan, was Du meinst.

Lese meine Posts genauer! Die Bedingungen, unter denen das gilt, stehen dabei. Und jetzt höre auf mit dem Blödsinn!

Verstehst du selbst deine eigenen Postings nicht?
Also nochmal:

Du hast aber der Aussage vom Duke widersprochen, die sich spezifisch auf die kleinen bezog. Und die stimmt einfach. Und welche Faktoren relevant sind und welche nicht, hängt immer vom Content des Spiels ab. Die Aussage kann man also nicht verallgemeinern. Wenn man für DX9/10/11 sowieso Modelle mit ein paar mehr Polys als Basis nimmt, dürfte in der Praxis alles oberhalb von 8 sowieso irrelevant sein.

Bei den mit Tess möglichen Einsparungen gibt es ja auch sowas wie "diminishing returns" (wem das deutsch besser gefällt: abnehmender Grenzertrag). Die Dreieckszahl skaliert ja nicht linear mit dem Tessfaktor, sondern in etwa quadratisch.
Um das mal ganz einfach auszudrücken, das heißt also, daß mit Faktor 32 das Basismodell nur 1 Promille der Dreiecke des finalen Modells hat, man "spart" also 99,9%, bei Faktor acht spart man aber auch schon 98,5%, die größte Ersparnis bringen also prinzipiell die kleinen Faktoren. Außerdem "spart" man das ja auch gar nicht alles wirklich, da auch ein ansehnlicher Mehraufwand in den Hull- und insbesonderen den Domainshadern geleistet werden muß. Es ist also alles andere als trivial, mit Tessellation überhaupt eine höhere Performance zu erreichen, als wenn man die gleiche Dreieckszahl von vornherein ohne Tess rendert. Die Geforces kaschieren das auf den Consumerkarten etwas, da der Dreiecksdurchsatz ohne Tess limitiert wird (weswegen die auch in dem obigen PCGH-Test bei ganz kleinen Tess-Faktoren zum Teil deutlich hinter den AMD-Karten liegen). Wenn Du wirklich hochperformante Tesselation mit (sub-)pixelgroßen Dreiecken haben willst, muß sich noch Einiges mehr an der GPU-Architektur tun.

Und daher auch meine Bitte, dass du hier Zahlen postet, die deinen Standpunkt untermauern.

Gipsel
2011-01-24, 19:22:02
Ich will zahlen haben, die zeigen, dass das Erzeugen von Geometrie auf der GPU nur in Ausnahmefällen schneller ist als das "offiline" Erzeugen durch die CPU.
Reichen die Einschätzungen von Tesseract und Coda?
Was ist gerade die Diskussion? Dass die gleiche tesselierte Dreieckssuppe rausgeschrieben in einen Vertexbuffer und dann gerendert ohne Tri-Limiter auf GF100 gleich schnell wäre als die Tesselationsvariante?

Zumindest würde man mehr Bandbreite brauchen, aber wenn das nicht limitiert könnte es ähnlich schnell sein.
Der Vorteil ist ja primär mal nicht die Geschwindigkeit beim Rendering, sondern das automatische LOD und das man viel weniger Platz im VRAM braucht.
alternativ dazu kannst du das komplette mesh vorberechnen und in den vram laden und von da normal raus zeichnen. letztere variante ist prinzipiell schneller weil die graka einfach ein polygon nach dem anderen zeichnet bis der vertexbuffer durch ist. das problem an der variante ist halt, dass sie a) unflexibler ist und b) den vram zumüllt
Ich hatte dazu geschrieben, daß es nicht trivial (also einfach zu sagen) ist, ob es schneller ist oder nicht. Erkennst Du ein Muster in den Aussagen? Woran hängst Du Dich eigentlich auf?

Zumal das gar nicht der Hauptpunkt in dem Posting war, es ging um den abnehmenden Grenzertrag beim Sparen von VRAM und z.B. der Animation der Modelle, das kann man nämlich am low poly base mesh machen. Krümelmonster, der auf den gleichen Beitrag geantwortet hat (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8526529#post8526529), hat das Prinzip offensichtlich ohne Probleme verstanden.

Coda
2011-01-24, 19:24:06
Der abnehmende Grenzertrag ist hier aber nicht so einfach anzuwenden, weil das Ergebnis von der Größe der Ausgangspolygone abhängt. Bei Multisampling ist die relevante Größe (ein Pixel) ja konstant.

Oder mal anders: Microsoft spezifiziert nicht sinnlos 64x als maximalen Tesselationsfaktor wenn es für alle möglichen Anwendungen auch 32x oder 16x getan hätte.

Ich finde es allgemein auch sehr bedenklich, dass hier an gesetzen Parametern der Render-Pipeline rumgepfuscht werden soll. Das machen die Treiber aus guten Gründen eigentlich seit D3D10 nicht mehr von selber, wenn nicht ein Profil hinterlegt ist. Man könnte sicher auch einen Algorithmus konstruieren der davon ausgeht, dass die Dreiecksmenge exakt die erwartet ist (Stream-Out mit anschließender Verarbeitung).

Eigentlich ist fast anzunehmen, dass AMD, wenn sie wirklich einen generischen Clamp-Schalter einbauen, der standardmäßig an ist keine WHQL-Zertifizierung mehr bekommen würden.

Gipsel
2011-01-24, 19:33:02
Gipsel, da muss ich jetzt aber auch mal was dagegen sagen. Das ist so Quatsch.

Man will ja sagen wir 0,25 Dreiecke/Pixel erreichen und das kann man mit großen Dreiecken eben evtl. nur mit hohen Tesselationsfaktoren. Hohe Tesselationsfaktoren sind also auch selbst auf kleiner Hardware je nach Ausgangsmesh alles andere als sinnlosIch hatte explizit geschrieben, daß es immer vom Content abhängt und pauschale Aussagen nicht zu machen sind. Als Bedingung dafür, daß kleinere Faktoren heutzutage meist ausreichen, hatte ich erwähnt, daß der Basemesh wegen der parallelen Verwendung ohne Tess auf DX10-Karten schon ein paar mehr Polys hat (und man demzufolge mit geringeren Faktoren auf die angestrebte Dreiecksgröße kommt) und daß es anders ist als bei zukünftigen Workloads, die vollkommen auf DX11 setzen und Modelle mit geringeren Polyzahlen als Basis einsetzen kann.

Du siehst, wir sind uns vollkommen einig ;)

Edit:
Und welche Faktoren relevant sind und welche nicht, hängt immer vom Content des Spiels ab. Die Aussage kann man also nicht verallgemeinern. Wenn man für DX9/10/11 sowieso Modelle mit ein paar mehr Polys als Basis nimmt, ...

LovesuckZ
2011-01-24, 19:34:14
Gipsel,
Cuda und Tesseract schreiben eine Erklärung. Grundsätzlich sehen sie aber, das ist mein Eindruck, den Sachverhalt anders als du. Du sprichst dich klar für "Offline Rendering" aus.


Eigentlich ist fast anzunehmen, dass AMD, wenn sie wirklich einen generischen Clamp-Schalter einbauen, der standardmäßig an ist keine WHQL-Zertifizierung mehr bekommen würden.

Sie werden kaum einen generischen Clamp-Schalter verwenden, sondern anwendungspezifisch Profile hinterlegen. Da die Testanwendungen von Microsoft wohl kaum "abgefangen" werden, sollte das Zertifikat kein Problem sein. Eher wird es interessant sein zu beobachten, wie Microsoft auf solch einen Fall reagiert. Etwas, mitdem sich auch Futuremark für 3DMark11 auseinandersetzen muss. Denn für die Anwendung ist es anscheinend nicht ersichtlich, mit welcher Einstellung der Treiber hantiert.

Coda
2011-01-24, 19:36:19
Du siehst, wir sind uns vollkommen einig ;)
Eher nicht, denn du argumentierst hier offenbar Pro-Clamp-Schalter.

Wenn sie wie ich schon erwähnt habe wenigstens ein multiplikatives Verfahren einsetzten würden. Dann wäre das Ergebnis ja sogar halbwegs sinnvoll. Aber selbst dann wird das wohl nicht gut funktionieren wenn die Funktion zur Bestimmung des Tesselationsgrades nicht linear ist.

Gipsel,
Cuda und Tesseract schreiben eine Erklärung. Grundsätzlich sehen sie aber, das ist mein Eindruck, den Sachverhalt anders als du. Du sprichst dich klar für "Offline Rendering" aus.
Tut er nicht. Er wollte dir nur klar machen, dass Tesselation primär nicht der Performancesteigerung dient. Da geh ich auch relativ konform mit ihm.

Wobei ein statisches LOD ziemlich sicher schlechter aussehen wird als dynamisches mit Tesselation, deshalb ist das nicht direkt vergleichbar.

LovesuckZ
2011-01-24, 19:42:34
Tut er nicht. Er wollte dir nur klar machen, dass Tesselation primär nicht der Performancesteigerung dient. Da geh ich auch relativ konform mit ihm.

Das habe ich verstanden. Deswegen will er auch kein großflächiges "Tessellation" auf der GPU, sondern "high-poly" Modell, die maximal mit einem "kleinen Faktor" verarbeitet werden.
Und darauf baut meine Frage auf, warum überhaupt Tessellation in der jetzigen Form als Pflicht spezifiziert wurde, wenn es laut ihm keinen bedeutenden Vorteil bringen würde.

Gipsel
2011-01-24, 19:43:11
Ich finde es allgemein auch sehr bedenklich, dass hier an gesetzen Parametern der Render-Pipeline rumgepfuscht werden soll. Das machen die Treiber aus guten Gründen eigentlich seit D3D10 nicht mehr von selber, wenn nicht ein Profil hinterlegt ist. Man könnte sicher auch einen Algorithmus konstruieren der davon ausgeht, dass die Dreiecksmenge exakt die erwartet ist (Stream-Out mit anschließender Verarbeitung).

Eigentlich ist fast anzunehmen, dass AMD, wenn sie wirklich einen generischen Clamp-Schalter einbauen, der standardmäßig an ist keine WHQL-Zertifizierung mehr bekommen würden.
Ich vermute mal, die Profile können nicht nur auf Spielebasis gemacht werden, sondern pro Hullshader, der die benötigten Tessfaktoren ermittelt. Und wie man die dann abändern kann, entzieht sich meiner Kenntnis. Ich denke schon, daß sie da im Notfall praktisch beliebig am Algo drehen können (Shaderreplacement), oder eben auch einfach am Ende eine Skalierung mit x% dranklatschen können. Der Slider ist ja offensichtlich noch lange nicht final, da muß man erstmal sehen, was draus wird. Das Ergebnis kann am Ende (wie schon häufig im Thread erwähnt) irgendwas zwischen den Extremen von "nützlicher Treiberfunktion" und "verwirrendes Mittel um die Frameraten auf Kosten von Bildqualität zu erhöhen" sein.

Coda
2011-01-24, 19:44:39
Wir sollten vielleicht wirklich mal abwarten was dabei am Ende rauskommt.

Mich würde die Billiglösung mit reinem Clamp einfach nerven. Das ist einfach schlampiges Engineering und High-End-Hardware nicht würdig. Außerdem riecht es dann echt streng nach Hilflosigkeit und verlangter billigstmöglicher Lösung seitens des Managements.

Gipsel
2011-01-24, 19:48:44
Eher nicht, denn du argumentierst hier offenbar Pro-Clamp-Schalter.Nein?
Wenn sie wie ich schon erwähnt habe wenigstens ein multiplikatives Verfahren einsetzten würden. Dann wäre das Ergebnis ja sogar halbwegs sinnvoll. Aber selbst dann wird das wohl nicht gut funktionieren wenn die Funktion zur Bestimmung des Tesselationsgrades nicht linear ist.Mein Lag beim Lesen und Antworten der Postings ist offensichtlich etwas zu groß ;)

Schaffe89
2011-01-24, 19:50:50
Achso, wer pro Clamp Schalter argumentiert wird zum Fanboy abgestempelt oder was?^^ Ist dass denn so wichtig zu wissen wer jetzt pro Clamp oder nicht pro Clamp argumentiert?

Das ist einfach schlampiges Engineering und High-End-Hardware nicht würdig. Außerdem riecht es dann echt streng nach Hilflosigkeit und verlangter billigstmöglicher Lösung seitens des Managements.



Das ist eine übertriebene Interpretation deinerseits.
Zudem hast du bisher übersehen, dass auch optisch gute Erfolge damit erzielt worden sind.

Wir sollten vielleicht wirklich mal abwarten was dabei am Ende rauskommt.



DAs würde ich auch meinen. :)

Gipsel
2011-01-24, 20:00:33
Das ist eine übertriebene Interpretation deinerseits.
Zudem hast du bisher übersehen, dass auch optisch gute Erfolge damit erzielt worden sind.Nun, es ist eine nachvollziehbare Einschätzung von Coda. Ob Du die teilst oder nicht, ändert nichts daran.
Und ob man es als "optisch guten Erfolg" einordnen sollte, wäre ich auch vorsichtig. Es zeigt im Prinzip nur, daß man in einigen (bisher doch recht isolierten) Beispielen nicht übermäßig viel von einer Reduzierung der Tessfaktoren sieht.
Aber auch hier gilt natürlich, daß man erst mal abwarten muß, wie das am Ende dann wirklich aussieht. Man merkt schon, daß die Releasenotes nicht lügen, wenn sie von einem "early prototype" des Tess-Sliders sprechen. Im Moment kann man nur hoffen, daß da vernünftig dran gearbeitet wird.

Schaffe89
2011-01-24, 20:08:48
Nun, es ist eine nachvollziehbare Einschätzung von Coda. Ob Du die teilst oder nicht, ändert nichts daran.


Sicher, man wird abwarten müssen.
Allerdings riecht es für mich kaum nach Hilflosigkeit, besonders deswegen nicht, weil mit sehr hoher wahrscheinlichkeit keine Titel kommen werden, welche extreme low Poly Oberflächen bieten, sondern sich das alles im Humanen Bereich abspielen wird, deswegen ist für meine Person diese Einschätzung recht zweifelhaft.

Die Clamp-Kritik in allen Ehren, die ist begründet und nachvollziehbar.

Coda
2011-01-24, 20:12:13
Sicher, man wird abwarten müssen.
Allerdings riecht es für mich kaum nach Hilflosigkeit, besonders deswegen nicht, weil mit sehr hoher wahrscheinlichkeit keine Titel kommen werden, welche extreme low Poly Oberflächen bieten, sondern sich das alles im Humanen Bereich abspielen wird, deswegen ist für meine Person diese Einschätzung recht zweifelhaft.
Warum brauchen sie dann den Schalter? Du wiedersprichst dir doch selber.

DrFreaK666
2011-01-24, 20:20:44
Warum brauchen sie dann den Schalter? Du wiedersprichst dir doch selber.

Also wenn ein Spiel mit tesselation nciht mehr flüssig läuft dann nutze ich den Schalter. Ist doch logisch.
Wenns so einen Schalter im Spiel gibt dann wird dieser ja auch sicherlich genutzt um die Details zu verringern

LovesuckZ
2011-01-24, 20:25:27
Also wenn ein Spiel mit tesselation nciht mehr flüssig läuft dann nutze ich den Schalter. Ist doch logisch.
Wenns so einen Schalter im Spiel gibt dann wird dieser ja auch sicherlich genutzt um die Details zu verringern

Und wenn das Spiel wegen DoF, oder SSOA, oder MSAA, oder Schattenqualität nicht mehr "flüssig läuft"?

DrFreaK666
2011-01-24, 20:27:48
Und wenn das Spiel wegen DoF, oder SSOA, oder MSAA, oder Schattenqualität nicht mehr "flüssig läuft"?

ja dann MSAA, SSAO oder DoF deaktivieren/Stufe verringern - wenn möglich.

airbag
2011-01-24, 20:31:23
Und wenn das Spiel wegen DoF, oder SSOA, oder MSAA, oder Schattenqualität nicht mehr "flüssig läuft"?
Muss man je nach Spiel abwegen. Wenn Tessellation so umgesetzt wäre, dass es die Immersion extrem steigert, würde man tendenziell Anderes abschalten um es noch einsetzen zu können. ;)
Ist bis jetzt aber noch nícht und daher nicht unbedingt mit AA oder einer guten Beleuchtung zu vergleichen.

LovesuckZ
2011-01-24, 20:36:13
Muss man je nach Spiel abwegen. Wenn Tessellation so umgesetzt wäre, dass es die Immersion extrem steigert, würde man tendenziell Anderes abschalten um es noch einsetzen zu können. ;)
Ist bis jetzt aber noch nícht und daher nicht unbedingt mit AA oder einer guten Beleuchtung zu vergleichen.

Darum geht es ja: Der Leistungsverlust ist in heutigen Spiel eher minimal. Ein DoF oder ein SSOA@Ultra ziehen wesentlich mehr Leistung. Deswegen ist der Schalter ja auch unlogisch: Es gibt haufenweise Option, die viel Leistung kosten. Aber keine davon wird von AMD bevorzugt behandelt.

Blediator16
2011-01-24, 20:54:59
Ich bin echt gespannt, ob Tesslation wirklich so hochgradig wichtig wird, wie hier einem suggeriert wird. Zumal echt hart übertrieben wird:freak:

Coda
2011-01-24, 20:57:40
Ich bin echt gespannt, ob Tesslation wirklich so hochgradig wichtig wird, wie hier einem suggeriert wird. Zumal echt hart übertrieben wird:freak:
Die ersten Techdemos von neuen Techniken sehen seit jeher so aus. Man macht sich die Arbeit ja nicht ohne dass es heraussticht.

DrFreaK666
2011-01-24, 21:03:13
Bitte? Es gab doch Screenshots von der derzeitigen Implementierung? Das zusammen mit den Bezeichnungen am Schalter lassen derzeit ziemlich sicher darauf schließen, dass es reines Clamp ist.

Und das kann man sehr wohl zu kritisieren. Auch wenn es euch nicht in den Kram passt.

Die FPS steigen und es sieht besser aus als ohne Tess.
Daher find ich es sinnvoll.

Coda
2011-01-24, 21:07:30
Wie oft genau muss ich noch wiederholen, dass Clamp die übelste Schrottbilliglösung ist die sie sich dafür nur haben ausdenken können? Was genau darf ich daran nicht kritisieren? Wie begriffsstutzig seid ihr eigentlich?

Es geht mir nicht um den Schalter an sich, sondern die Art wie er offenbar umgesetzt ist. Zum 100. Mal.

Dr. Cox
2011-01-24, 21:15:12
Wie wäre es mal zur Abwechslung mit einer sachlichen und produktiven Diskussion?

Black-Scorpion
2011-01-24, 21:21:36
Vielleicht weil es zu einem unfertigen Schalter den keiner voll überprüfen kann nichts zu diskutieren gibt? Außer natürlich von einigen die alles schon vorher wissen. Mann könnte ja mit dem meckern auch warten bis es was zum überprüfen gibt. Aber nein es wird erst gemeckert.

Gipsel
2011-01-24, 21:23:52
Leute! Bleibt doch mal etwas ruhiger!
Ansonsten siehe hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8525877#post8525877).

Tesseract
2011-01-24, 21:26:22
Komischerweise immer nur bei AMD.
das ist überhaupt nicht komisch, das spiegelt einfach AMDs geschäftspraxis wieder.
kritik ist nichts, das man gleichmäßig verteilt. die gehört dort hin, wo sie angebracht ist und das ist momentan nunmal fast ausschließlich bei AMD.

Langenscheiss
2011-01-24, 21:34:59
das ist überhaupt nicht komisch, das spiegelt einfach AMDs geschäftspraxis wieder.
kritik ist nichts, das man gleichmäßig verteilt. die gehört dort hin, wo sie angebracht ist und das ist momentan nunmal fast ausschließlich bei AMD.
Da ist schon was wahres dran, obwohl man sagen muss, dass speziell der Treiber 11.1a irgendwie vermurxt scheint. Diese etwas merkwürdige Umkonfigurierung der Texturfilter-Qualitätsmodi (ich sag nur "Performance"-Modus) und dann dieser Prototyp-Regler fürs Tesselation. Wirkt alles ein wenig "rushed".

Raff
2011-01-24, 21:39:34
das ist überhaupt nicht komisch, das spiegelt einfach AMDs geschäftspraxis wieder.
kritik ist nichts, das man gleichmäßig verteilt. die gehört dort hin, wo sie angebracht ist und das ist momentan nunmal fast ausschließlich bei AMD.

Endlich sagt's mal jemand so, wie's sich gehört.

Da ist schon was wahres dran, obwohl man sagen muss, dass speziell der Treiber 11.1a irgendwie vermurxt scheint. Diese etwas merkwürdige Umkonfigurierung der Texturfilter-Qualitätsmodi (ich sag nur "Performance"-Modus) und dann dieser Prototyp-Regler fürs Tesselation. Wirkt alles ein wenig "rushed".

Kaum ist Terry weg, machen die Schergen, was sie wollen. ;D

MfG,
Raff

Exxtreme
2011-01-24, 22:12:08
Semi-OT:

Kaum ist Terry weg, machen die Schergen, was sie wollen. ;D

MfG,
Raff
Wo ist Terry hin?

Gipsel
2011-01-24, 22:14:40
Wenn sie wie ich schon erwähnt habe wenigstens ein multiplikatives Verfahren einsetzten würden. Dann wäre das Ergebnis ja sogar halbwegs sinnvoll. Aber selbst dann wird das wohl nicht gut funktionieren wenn die Funktion zur Bestimmung des Tesselationsgrades nicht linear ist.Man müßte mal definieren, was das Ziel ist. Was noch recht problemlos gehen müßte, ist nicht nur eine prozentuale Verringerung der Tesselationsfaktoren, sondern auch eine relative Verringerung der Anzahl der Dreiecke, was vielleicht näher an Deiner Vorstellung ist (im Prinzip skaliert das direkt die angestrebte Dreiecksgröße).

Die Anzahl N der Dreiecke bei einer tessellierten Dreiecksdomain beträgt (für ungerade Tessfaktoren t, aber egal, es sind immer ungefähr 1,5*t²) exakt
N = 1,5 * t² - 0.5
Für Quads ist es sogar noch einfacher immer N = 2 * t².

Will man jetzt die Zielgröße der Dreiecke mit 1/x skalieren (also die Anzahl mit x), so kann man das praktisch immer ziemlich genau mit einem angepaßten Tessfaktor ta von
ta = sqrt(x) * t
erreichen.
Ist im Prinzip das gleiche, nur ist die Skale dann nicht mehr linear in den Tessfaktoren, sondern linear bei der Dreiecksgröße bzw. der Anzahl der Dreiecke. Das mag es etwas bequemer machen. Falls der Treiber also eine Option zur Verfügung stellt, die den Nutzer das so skalieren läßt, wäre das in meinen Augen schon ein nettes Feature.

DrFreaK666
2011-01-24, 22:15:21
Semi-OT:

Wo ist Terry hin?

http://news.ati-forum.de/index.php/news/34-amdati-grafikkarten/1656-terry-makedon-wechselt-innerhalb-amds

Gipsel
2011-01-24, 22:17:26
Semi-OT:

Wo ist Terry hin?
AFAIR zur APU-Truppe (Software-Marketing).

horn 12
2011-01-24, 22:19:41
FINAL Cat 11.1a Treiber dürfte BALD online, da in wenigen Stunden unsder GTX 560 Launch bevorsteht...

Schauen wie sich die 1GB/ 2GB HD6950/ 6970 nun schlagen werden... ODER auch nicht...

y33H@
2011-01-24, 22:20:45
AFAIR zur APU-Truppe (Software-Marketing).Ja, er macht nun die APUs.

@ horn 12

Erst mal GTX 560, dann 11.1a.

Dr. Cox
2011-01-24, 23:12:56
Erst mal GTX 560, dann 11.1a.

Sorry für offtopic, aber wann ist es denn soweit?

y33H@
2011-01-25, 09:05:07
Dann, wann NVs üblicher Termin ist. Und nein, es ist nicht 6h.

SamLombardo
2011-01-25, 09:07:34
Auf Umsetzungen wie in ...Lost Planet 2 kann man als PC-Spieler vollends verzichten.
Nö, muss ich widersprechen! Die Monster/Aliens in LP2 sind mit das geilste was man jemals auf dem Bildschirm bestaunen durfte. Ähnliches gilt für das Tessellationwasser (und ja, ich hör schon das gebashe, aber nur zu:wink:) Die Viecher sind dank Tessellation imho schöner aus als der "berühmte" Drache aus Unigine -und das in Bewegung:eek:) Ich finde es super, dass derartiges heute möglich ist und möchte keine Tessellationstufe missen, und wenn meine Grafikkarte die Tessellation aus Gründen von Leistungsdefiziten selbständig "runterrechnen" würde wäre das für mich ein absolutes no go!

Gruß!

Schlammsau
2011-01-25, 09:17:46
Sorry aber das Game ist absolut häßlich, da hilft auch kein tesselliertes Wasser.

Ich denke, da ist auch viel Psychologie mit dabei, die Gehirnwäsche von Huang, LovesuckZ und Co. hat bei manchen zumindest gewirkt.

Schöner als der Heaven Drachen?..... :ulol:

SamLombardo
2011-01-25, 09:26:32
(und ja, ich hör schon das gebashe, aber nur zu:wink:)

Gruß Trotzdem





Edit: Hast Du es selber gespielt @DX11 max? Ich kann Deine Aussage nämlich nicht nachvollziehen. Man mag von dem Game halten was man will (Der spielerische Superhit isses nun sicher nicht) aber die Viecher sehen zum Teil absolut atemberaubend aus!

=Floi=
2011-01-25, 09:42:29
Gruß Trotzdem





Edit: Hast Du es selber gespielt @DX11 max? Ich kann Deine Aussage nämlich nicht nachvollziehen. Man mag von dem Game halten was man will (Der spielerische Superhit isses nun sicher nicht) aber die Viecher sehen zum Teil absolut atemberaubend aus!


mach hald einfach einen shot dazu und du entkräftest jegliche kritik.

SamLombardo
2011-01-25, 09:50:03
Bin gerade auf Arbeit, werd aber heute abend mal sehen:wink:

kruemelmonster
2011-01-25, 10:08:16
Krümelmonster, der auf den gleichen Beitrag geantwortet hat (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8526529#post8526529), hat das Prinzip offensichtlich ohne Probleme verstanden.

Mal sehen ob ich wirklich alles verstanden habe:

Den Effekt der "diminishing returns" hab ich genauso aufgefasst wie von dir in Post #756 (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8526965&postcount=756), da passt alles.

Nun kommen die Fragezeichen, tut mir leid ausgerechnet diesen Satz auszugraben, ich machs auch kurz. ;)

Es ist also alles andere als trivial, mit Tessellation überhaupt eine höhere Performance zu erreichen, als wenn man die gleiche Dreieckszahl von vornherein ohne Tess rendert.

Rein fürs Verständnis:

Durch die Arbeit, die die Hull und Domainshader für die Tesselation leisten müssen, kann die Situation eintreten dass es günstiger/schneller wäre das gleiche Modell mit mehr Tris (um den Wegfall des Tesselationsfaktors auszugleichen) old-school zu rendern?
Welche Situationen wären dies denn; und welchen Anteil an der Arbeit hat die CPU eigentlich noch in gerade diesem Renderabschnitt?

---

Danke euch Gipsel, Coda und Tesseract für eure kontinuierlichen Erklärungen, die mir ein wenig mehr Licht ins Dunkel der Zusammenhänge bringen. :up:

SamLombardo
2011-01-25, 10:18:08
Auch wenn leicht OT hier mal ein Oberbossfight aus LP2 von youtube
http://www.youtube.com/watch?v=KGrapP8og_s
Wer Intresse hat kann bei Youtube auch nach anderen Bossfights schauen, die sind beinahe alle sehr beeindruckend. Aber auch die kleineren Monster (die rollenden "Stachelschweine" zum Beispiel) sind dank Tessellaion toll anzuschauen und ja - meiner Meinung nach - durchaus auf Niveau des Drachen:wink:

Gruß

Blediator16
2011-01-25, 10:50:35
Erinnert stark an DMC4 Bosse, die auch vollgebumpert aussahen.

Gipsel
2011-01-25, 12:00:26
Rein fürs Verständnis:

Durch die Arbeit, die die Hull und Domainshader für die Tesselation leisten müssen, kann die Situation eintreten dass es günstiger/schneller wäre das gleiche Modell mit mehr Tris (um den Wegfall des Tesselationsfaktors auszugleichen) old-school zu rendern? Welche Situationen wären dies denn;
Ja, rein von der Performance ist das gut möglich. Das Problem daran ist, daß man mit Tessellation eine ziemlich gute Möglichkeit hat, den Geometrie-LOD entsprechend der Entfernung zum Betrachter (also der Größe eines Dreiecks auf dem Bildschirm) zu regeln. Im Hullshader kann man ja individuell festlegen, mit welchem Tessfaktor tesseliert werden soll. Außerdem verbraucht man weniger VRAM (weil das Ausgangsmodell weniger Polygone hat, die dort abgelegt werden müssen, die bei Tessellation erzeugten belegen nur einen relativ kleinen Puffer, der möglichst komplett auf dem Chip bleiben sollte, also überhaupt kein RAM beansprucht), was so ziemlich der einzige positive Performanceeffekt von Tessellation ist, der mir spontan einfällt.
Zusammengefaßt, Tess bietet mehr Flexibilität (erweiterte Möglichkeiten, die ansonsten nur schwer/langsam so hinzubekommen wären) bei weniger VRAM-Verbrauch, ist aber im Allgemeinen nicht schneller. Wenn z.B. aufwendige Domainshader benutzt werden, ist es sogar mit einiger Wahrscheinlichkeit langsamer, wenn man ohne Tess nicht ein VRAM-Limit trifft.
und welchen Anteil an der Arbeit hat die CPU eigentlich noch in gerade diesem Renderabschnitt?
Keine. Im Prinzip wird das Modell am Anfang einmal übertragen (egal ob mit Tess oder ohne), und dann kann man eigentlich alles auf der GPU machen.

Schlammsau
2011-01-25, 12:02:27
Auch wenn leicht OT hier mal ein Oberbossfight aus LP2 von youtube
http://www.youtube.com/watch?v=KGrapP8og_s
Wer Intresse hat kann bei Youtube auch nach anderen Bossfights schauen, die sind beinahe alle sehr beeindruckend. Aber auch die kleineren Monster (die rollenden "Stachelschweine" zum Beispiel) sind dank Tessellaion toll anzuschauen und ja - meiner Meinung nach - durchaus auf Niveau des Drachen:wink:

Gruß

Ist der Unterschied von DX9 und DX11 wirklich so groß?
Oder hast du das noch nicht ausgetestet?

Mir ist jedenfalls aufgefallen, dass im Benchmark zumindest, kaum visuelle Unterschiede bei den verschiedenen APIs vorhanden waren. Das Monster hatte mit oder ohne Tessellation "Spikes".

Mal mal nen DX9 vs. DX11 Screenshotvergleich, damit wir die Unterschiede sehen.

SamLombardo
2011-01-25, 12:12:08
Ist der Unterschied von DX9 und DX11 wirklich so groß?
Oder hast du das noch nicht ausgetestet?

Mir ist jedenfalls aufgefallen, dass im Benchmark zumindest, kaum visuelle Unterschiede bei den verschiedenen APIs vorhanden waren. Das Monster hatte mit oder ohne Tessellation "Spikes".

Mal mal nen DX9 vs. DX11 Screenshotvergleich, damit wir die Unterschiede sehen.
Bei PCGH gibts einen http://www.pcgameshardware.de/aid,767502/Lost-Planet-2-im-Technik-Test-DirectX-9-gegen-DirectX-11-Grafikkarten-und-CPU-Benchmarks/Action-Spiel/Test/
Sind nun nicht Welten, aber doch merklich imho.

gruß

LovesuckZ
2011-01-25, 12:12:44
Ja, rein von der Performance ist das gut möglich.


Das kann man anzweifel. Wäre dies so, hätten Spiele ein höheres Geometrie-Niveau und Tessellation wäre sinnlos.
Es wäre also wirklich an der Zeit, dass du Beispiele bringst. Denn irgendwie ist es für den normalen Menschen aus deiner Erklärung nicht ersichtlich, wieso überhaupt Tessellation eingesetzt werden sollte, da ein statisches Geometrie-Level wesentlich einfacher zu realisieren und deutlich schneller wäre.

/edit: Du bist auch der erste, der sich weltweit so klar gegen Tessellation auf der GPU auspricht. Das ist bezeichnend, hat man diese kritischen Worte nirgendwo sonst gelesen. Hier wären also Beispiele für deine These sehr angebracht, um dieses Thema generell weiter zu verfolgen.

SamLombardo
2011-01-25, 12:14:11
Hier siehst du es doch. Gravierend !
http://techgage.com/article/lost_planet_2_dx9_vs_dx11/

Ich find DX9 oftmals besser, gebe mal ein beispiel warum:


Das kann nur jemand sagen, der das Spiel garantiert noch nie persönlich live gesehen hat:rolleyes: Die unterschiede mögen nicht riesig sein aber diese Aussage..naja

deekey777
2011-01-25, 12:43:09
Das kann man anzweifel. Wäre dies so, hätten Spiele ein höheres Geometrie-Niveau und Tessellation wäre sinnlos.
Es wäre also wirklich an der Zeit, dass du Beispiele bringst. Denn irgendwie ist es für den normalen Menschen aus deiner Erklärung nicht ersichtlich, wieso überhaupt Tessellation eingesetzt werden sollte, da ein statisches Geometrie-Level wesentlich einfacher zu realisieren und deutlich schneller wäre.

/edit: Du bist auch der erste, der sich weltweit so klar gegen Tessellation auf der GPU auspricht. Das ist bezeichnend, hat man diese kritischen Worte nirgendwo sonst gelesen. Hier wären also Beispiele für deine These sehr angebracht, um dieses Thema generell weiter zu verfolgen.
Wo spricht er sich gegen die Tessellation aus?

Schaffe89
2011-01-25, 12:59:00
Warum brauchen sie dann den Schalter? Du wiedersprichst dir doch selber

Eine rethorische Frage, mit welchem Sinn?
Der Schalter wird eingebaut um die HD5k und Karten mit weniger starker Tess Performance den Rücken zu stärken und es wird die Möglichkeit gegeben in zukünftigen Spielen, welche eventuell (irgendwann??) low Poly Modelle mit hohen Tess Graden in High Poly Texturen umwandeln und dafür mords Performance benötigen. Somit kannman das Level Treiberseitig oder eben selbst senken oder gar erhöhen, das wurde doch alles schon im Thread besprochen, ich habe nur den Ist Zustand beschrieben und einen Ausblick vermutet.

Zumal niemand weiß, wie und inwiefern AMD hier mit ihren Profilen herangehen wird, deswegen ist der verfrühte Ausspruch von Hilfosigkeit für mich eher also unnötige Würze in einer sachlichen Diskussion zu verstehen.

Wie oft genau muss ich noch wiederholen, dass Clamp die übelste Schrottbilliglösung ist die sie sich dafür nur haben ausdenken können? Was genau darf ich daran nicht kritisieren? Wie begriffsstutzig seid ihr eigentlich?


Mich wundert halt deine Sichtweise, weil sie mir äußerst negativ erscheint. Zudem niemand begriffsstutzig ist, besonders ich nicht, da ich zu Beginn ganz klar klargestellt habe, dass die Kritik an dem Clamp-Verfahren sicherlich unter dem Aspekt "Sinkende BQ" je nach Content und voreingestelltem Tessgrad für verschiedene Bereiche des Bildes berechtigt ist.
Ich habe mich nur daran gestört, dass du dich nicht mäßigen kannst und Wörter wie billig, Hilflosigkeit etc.. dazupackst, das muss in einer sachlichen Diskussion nicht sein.
Aber gut, das ist deine Einschätzung - akzeptiert und Ende.

Ein DoF oder ein SSOA@Ultra ziehen wesentlich mehr Leistung. Deswegen ist der Schalter ja auch unlogisch: Es gibt haufenweise Option, die viel Leistung kosten. Aber keine davon wird von AMD bevorzugt behandelt.



Tess ist das erste Directx11 Feature mit dem man Einstellungen unter dem Aspekt "Regulierung" praktikabel einsetzen kann, könnte.
Deswegen wird die von AMD auch bevorzugt behandelt.
Ich bin gar der Meinung, dass dies aus AMD´scher Sicht gar nicht nötig war, dar die Tess Leistung für Spiele (bis jetzt!) locker ausreicht, schließlich muss die TExturqualität in puncto Oberfläche, bzw runde Objekte etc.. ohne Tess auch noch auf einem akzeptablen Niveau sein.
Ich denke dass sich Tesselation mit der Zeit etablieren wird und ähnlich wie AA oder AF zum gepflegten Standard wird, aber dann auch kleine Karten in der Lage sein müssen da nicht völlig einzubrechen.

Sorry aber das Game ist absolut häßlich, da hilft auch kein tesselliertes Wasser.


Unabhängig davon wer das gespostet hat muss ich da auch meinen Senf dazugeben.
Lost Planet 2 ist ein Paradebeispiel dafür, dass man relativ schlechte Texturen in einem Spiel nicht mit directx11 suggestiv verbessern kann.
Die tesselierten Viecher mögen ganz schön sein, das Wasser ist aber meiner Meinung nach Overkill, wenn es so aussieht als würde der Bach jeden Moment überlaufen.

Er sagt es doch: Im Grunde nur sinnvoll für "dynamische Erzeugung".


Das hängt wie gesagt von mehreren Parametern ab die wir noch nicht wissen.
AMD wird den Faktor wahrscheinlich nahe an dem platzieren, der für das ganze zu rendernde Bild am höchsten angesetzt wurde, um die Qualität zu wahren.
Zudem !vermute! ich, dass man alleine dadurch dass die Tess festgelegt ist und nicht dynamisch ist, Performance einsparen kann.

LovesuckZ
2011-01-25, 13:14:32
Wo spricht er sich gegen die Tessellation aus?

Er sagt es doch: Im Grunde nur sinnvoll für "dynamische Erzeugung".
Er beschreibt, dass "kleine Faktoren den meisten Gewinn bringen" und im Grunde alles ab Faktor 8 "irrelevant" wäre, da man generell schon ein "hohes Polygonniveau" benötigen werde. Und da man nach ihm dieses Ausgangsmaterial schneller und einfacher "Offline" erzeugen kann, spricht Gipsel sich hier klar und sehr eindeutig gegen Tessellation aus.

Ich finde dies ist ein interessanter Gedanke. Aber ohne Zahlen am Ende nicht für jemanden wie mich begreifbar.

Screemer
2011-01-25, 13:17:51
Er sagt es doch: Im Grunde nur sinnvoll für "dynamische Erzeugung".
Er beschreibt, dass "kleine Faktoren den meisten Gewinn bringen" und im Grunde alles ab Faktor 8 "irrelevant" wäre, da man generell schon ein "hohes Polygonniveau" benötigen werde. Und da man nach ihm dieses Ausgangsmaterial schneller und einfacher "Offline" erzeugen kann, spricht Gipsel sich hier klar und sehr eindeutig gegen Tessellation aus.

für mich sagt keiner deiner angeführten punkte aus, dass er sich gegen tess ausspricht. er hinterfragt lediglich den sinn bei heutigem content und genau hier hat er recht. in zukunft und mit entsprechender hardwarebasis wird sich das sicher ändern.

Schaffe89
2011-01-25, 13:26:24
Was mich bei Tess stört, sind die verzerrten Texturen und Punkt für die Oldschool Methode. :)

Screemer
2011-01-25, 13:34:36
was aber wiederum ein content problem ist.

LovesuckZ
2011-01-25, 13:49:25
für mich sagt keiner deiner angeführten punkte aus, dass er sich gegen tess ausspricht. er hinterfragt lediglich den sinn bei heutigem content und genau hier hat er recht. in zukunft und mit entsprechender hardwarebasis wird sich das sicher ändern.

Nein, er hinterfragt den Sinn von Tessellation - nicht vom Content.
Er schreibt doch: Man benötige für DX9 und DX10 ein High-Poly-Modell, also würde es keinen Sinn für DX11 machen aus einem relativ polygonarmes ein "High-Poly-Modell" zu erstellen. Leistungsgewinn durch Tessellation stünde in keinem Zusammenhang mit dem Aufwand für die Entwicklung.

Als Spieler ist das für mich neu. Und ich finde, wenn das "Offline-rendering" mir ein Geometrie-Niveau ohne sichtbaren LoD-Wechsel bringt (z.B. ein Niveau wie statisches Tessellation), dann sollte dies auch umgesetzt werden. Wozu Rechenkapazität einer GPU vergeuden, wenn es über die CPU genauso funktioniert?

deekey777
2011-01-25, 13:54:43
Er sagt es doch: Im Grunde nur sinnvoll für "dynamische Erzeugung".
Ich weiß nicht, was "dynamische Erzeugung" sein soll. Aber der Gedanke ist, dass zB NPC vor der Nase durch Tessellation detailreicher aussehen können, die weiter entfernten dagegen normal bleiben. Wie das geht, sieht man in der Froblins-Demo, wo nur die Froblins tesselliert werden, die zum Betrachter am nächsten sind.

Er beschreibt, dass "kleine Faktoren den meisten Gewinn bringen" und im Grunde alles ab Faktor 8 "irrelevant" wäre, da man generell schon ein "hohes Polygonniveau" benötigen werde.
Aber aes unter TF8 ist weiterhin Tessellation, oder?
Und da man nach ihm dieses Ausgangsmaterial schneller und einfacher "Offline" erzeugen kann, spricht Gipsel sich hier klar und sehr eindeutig gegen Tessellation aus.
Wo sagt er das?
In dem letzten Posting lese ich maximal, dass es möglich ist, dass bei gleicher Polygon-Zahl die Performance gleich oder schneller als mit Tessellation sein kann. Ergibt auch Sinn, schließlich liegt die Grafikkartenlast nicht auf Geometrie, sondern nach dem Raterizing (diverse Materialshader, komplizierte Beleuchtung usw.).

Viel interessanter als irgendwelche Hörner oder runde Schreibmaschinen sind Einschusslöcher.

LovesuckZ
2011-01-25, 14:05:53
Ich weiß nicht, was "dynamische Erzeugung" sein soll. Aber der Gedanke ist, dass zB NPC vor der Nase durch Tessellation detailreicher aussehen können, die weiter entfernten dagegen normal bleiben. Wie das geht, sieht man in der Froblins-Demo, wo nur die Froblins tesselliert werden, die zum Betrachter am nächsten sind.

Adaptives Tessellation ist optisch belanglos, wenn man den Faktor auf 8 beschränken und gleichzeitig aus einem Low-Poly-Modell heraus Geometrie erzeugen will. Außerdem bräuchte man kein adaptives Verfahren, wenn über das "Offline-Rendering" ein Niveau erreicht wird, dass z.B. die Qualität von statisch 8 erreichten sollte und gleichzeitig kaum langsamer wäre als z.B. eine GTX580.


Aber aes unter TF8 ist weiterhin Tessellation, oder?


Natürlich. Nur ist selbst ein Faktor von 8 unnötig, wenn man Modelle so detailreich gestaltet, dass der optische Gewinn gegen 0 geht. Das ist ein klares Bekenntnis gegen den Einsatz von Tessellation. Immerhin kostet es in diesem fall nur unnötige Leistung.


Wo sagt er das?
In dem letzten Posting lese ich maximal, dass es möglich ist, dass bei gleicher Polygon-Zahl die Performance gleich oder schneller als mit Tessellation sein kann. Ergibt auch Sinn, schließlich liegt die Grafikkartenlast nicht auf Geometrie, sondern nach dem Raterizing (diverse Materialshader, komplizierte Beleuchtung usw.).


Richtig. Es sollte die Last von der GPU genommen werden und die "gleiche Polygon-Zahl" "offline gerendert" werden.

Es ist sehr offensichtlich, dass Gipsel keinen Vorteil durch Tessellation auf der GPU sieht. Ich meine, dass sich jemand so öffentlich positioniert zum Thema empfinde ich sehr interessant, ist er der erste, der es so kritisch betrachtet.

Gipsel
2011-01-25, 20:07:47
@LS:
Damit ich die restlichen Threadleser nicht mit einer hoffentlich für Dich erschöpfenden Antwort nerve, schaue bitte mal hier rein:
Das kann man anzweifel.Ob Du das anzweifelst, ist vollkommen egal. Das ist einfach so. Wie sollte das auch anders sein? Da gibt es einfach keinen Grund dazu. Diesen Fakt haben Dir Coda und Tesseract bestätigt. Wenn Du es nicht glaubst, liefere doch mal ein Argument, warum es anders sein sollte.
Wäre dies so, hätten Spiele ein höheres Geometrie-Niveau und Tessellation wäre sinnlos.Warum wäre es sinnlos? Man gewinnt doch neue Möglichkeiten?
Denn irgendwie ist es für den normalen Menschen aus deiner Erklärung nicht ersichtlich, wieso überhaupt Tessellation eingesetzt werden sollte, da ein statisches Geometrie-Level wesentlich einfacher zu realisieren und deutlich schneller wäre.Ich behaupte, die Gründe sind für einen klar Interessierten schon sehr einfach ersichtlich. Und von deutlich schneller habe ich nie etwas geschrieben (grob ähnliche Geschwindigkeit, je nach genauem Fall mal schneller oder auch langsamer, bei ATI oft langsamer). Also höre auf, Dir sowas aus den Fingern zu saugen!

Und was Du vergleichen willst, ist doch sowieso Blödsinn. Wenn Tess eingesetzt wird, wird wohl in der übergroßen Anzahl der Tessfaktor dynamisch an die Entfernung zum Betrachter oder auch den Blickwinkel angepaßt werden, so daß man mit der Dreiecksgröße irgendeinen Zielwert erreicht und/oder bevorzugt die Silhouttenkanten stärker tesselliert und nicht Flächen, die praktisch senkrecht zum Betrachter zeigen (wo man das sowieso kaum sieht).

Der Vergleich, den Du anzweifelst, ist also sowieso praktisch kaum relevant, weil diese beiden Methoden (Rendern ohne Tess und Aufblasen eines Low-Poly-Modells mit statischer Tessellation auf die gleiche Polygonzahl wie ohne Tess oder dynamische Tess aber statischem Blickwinkel und Abstand und ein entsprechend genauso konstruiertes Modell ohne Tess) sowieso nicht zur Disposition stehen. Die Verringerung des Tessfaktors z.B. mit steigender Entfernung (oder bei entsprechenden Blickwinkeln) führt dazu, daß mit dynamischer Tessellation deutlich weniger Dreiecke gerendert werden, als das sonst der Fall wäre. Dies ist einfach ein großer Vorteil von Tessellation (zusammen mit einem reduzierten VRAM-Verbrauch), der dann bei ordentlicher Implementation natürlich auch schneller ist, als das Rendern sehr vieler Dreiecke (die in der Entfernung dann auch noch so mickrig sind, daß die Effizienz heutiger quadbasierter GPUs komplett in den Keller geht). Aber das ist eben kein Vorteil von Tess per se, sondern wird eben dadurch hervorgerufen, daß man bei dynamischer Anpassung der Tessfaktoren zum Teil deutlich weniger rendert (was eine Folge der erweiterten Möglichkeiten ist, die ich ständig erwähnt habe).
Du bist auch der erste, der sich weltweit so klar gegen Tessellation auf der GPU auspricht. Das ist bezeichnend, hat man diese kritischen Worte nirgendwo sonst gelesen.
Also wenn Du noch ein einziges Mal behauptest, ich bestreite die Vorteile von Tessellation, dann werte ich das als Trollversuch!Er beschreibt, dass "kleine Faktoren den meisten Gewinn bringen"Tun sie auch, wenn man es mal einfach mit dem Rendern eines hochaufgelösten Modells ohne Tess vergleicht, bei natürlich identischer Größe der Dreiecke auf dem Bildschirm am Ende.
und im Grunde alles ab Faktor 8 "irrelevant" wäre, da man generell schon ein "hohes Polygonniveau" benötigen werde.Du liest selektiv und ignorierst die Hälfte. Was schrieb ich schon als Antwort, als Du Dich erstaunt gezeigt hast, daß ich einen Tessfaktor von 21 im Island-Demo als "recht gering" bezeichnet habe?
Und was soll an einem Faktor von 21 "recht gering" sein, wenn hier propagiert werde, dass Maximal 16 ausreichen sein würde?
Diese letzte Aussage ist so absolut natürlich Unsinn, da das immer ein Wechselspiel mit dem Design des Content darstellt. Heutzutage muß ein Spiel auch ohne Tess noch halbwegs passabel aussehen, deswegen dürften recht geringe Faktoren auch zur Zeit meist ausreichen.[..]

Und um den Bogen zum Island-Demo zu schließen, hier gilt das natürlich so nicht. Beim Design des Content wurde nicht darauf geachtet, daß es ohne Tess noch passabel aussehen soll, eher das Gegenteil ist der Fall. Vielmehr soll ja gerade die Tessellation und ihr Einfluß demonstriert werden (daher die Bezeichnung "Demo"). Und in diesem Zusammenhang ist ein Faktor 21 offensichtlich (anhand Deiner Bilder) als "niedrig" einzustufen. Man sieht ja einen deutlichen Verlust an Geometriedetails im Vordergrund [..]
Also, nicht weil man unbedingt Modelle mit eher noch mittleren Polyzahlen benötigt, reichen in vielen Fällen heutzutage noch eher absolut gesehen niedrige Tessfaktoren aus, sondern weil man sie heutzutage sowieso hat, da die Spielentwickler auch faul sind und häufig einfach die DX10-Modelle im DX11-Modus mit Tess aufpeppen. Ich sage ja nicht, daß das erstrebenswert ist, es ist aber einfach häufig der momentane Zustand.

Wenn der Content aber voll auf die DX11-Pipeline ausgelegt ist, können höhere Tessfaktoren natürlich sehr sinnvoll sein. Die Einstufung von Tessfaktoren als hoch oder niedrig, sinnvoll oder nicht, muß also (wie ich schon immer hier schrieb) in Abhängigkeit vom Content erfolgen.

Ich habe Dir doch in einer PM schon lang und breit erklärt, wie das grob funktioniert. Tessfaktor 8 macht aus einem einzigen Dreieck ungefähr 100 Dreiecke. Falls man eine gewisse Zielgröße auf dem Bildschirm hat (bspw. 4 oder 8 Pixel oder was auch immer), kommt man da mit TF 8 an, wenn die Dreiecke im Ausgangsmodell schon ~400 bzw. 800 Pixel groß wären. Sowas ist schon sehr deutlich sichtbar und kommt außer bei glatten Flächen, sprich z.B. bei Gegnermodellen eigentlich kaum noch vor. Im Prinzip kann man also mit Tessellation die Geometriequalität auf ein neues Level anheben. Das schafft man prinzipiell auch ohne Tess, allerdings besitzt das zu tessellierende Modell laut Milchmädchenrechnung in diesem Beispiel nur grob 1% der Polygone wie das komplett statische, es belegt also nur einen Bruchteil des VRAMs. Außerdem muß man häufig (wenn der Gegner weiter weg ist) nur einen Bruchteil der Polygone rendern (weil der Tessfaktor natürlich dynamisch angepaßt wird und Geometrie-LOD anderweitig schwieriger/langsamer zu realisieren ist), so daß im Extremfall die Polygonlast auf ~1% des komplett statischen Vorgehens sinkt. Das ändert natürlich nichts daran, daß wenn die gleichen Dreiecke gerendert werden würden, die Version mit Tess nicht automatisch schneller ist als die ohne, bevor Du nochmal damit anfängst.

Und jetzt sage nicht, daß das keine großen Vorteile darstellen können.

Natürlich kann man jetzt hingehen und für den DX11-Modus totale low-poly-Modelle als Basis nehmen, wo man dann höhere Tessfaktoren benötigt, um auf die gleiche Dreiecksgröße in Pixeln zu kommen. Und sicher bringt dies auch im Prinzip noch einmal einen Vorteil. Allerdings ist dieser ganz objektiv kleiner, als was man überhaupt durch durch die Benutzung von Tess (auch mit Faktoren <=8 oder <=16) gewinnt.

Genauso gut kannst Du doch hingehen und fordern, wir benötigen ein DX11.1, welches Tessfaktoren bis 512 unterstützt. Da würde Dir auch jeder sagen, daß der Vorteil der möglichen Nutzung von einem Maximum von 512 statt 64 (Faktor 8) deutlich kleiner ist, als ein hypothetischer Schritt von 8 auf 64 (ebenfalls Faktor 8). Und genauso gilt es natürlich, daß der Schritt von 1 auf 8 (Faktor 8 und dazu überhaupt die Möglichkeit der dynamischen Anpassung) wichtiger ist, als der von 8 auf 64 (wieder Faktor 8). Ist das so schwer zu verstehen?

DX11 definiert jetzt ein Maximum von 64, so daß es natürlich Content geben wird, der das auch zu nutzen weiß (siehe nvidias Island-Demo ;)). Hätte MS ein Maximum von 32 oder gar nur 16 vorgegeben, wäre aber die Welt auch nicht untergegangen. Die Entwickler würden im Zweifelsfall eben Grundmodelle mit einer Handvoll mehr Polygonen nehmen, falls sie das in dem jeweiligen Fall überhaupt einschränken würde. Ein Grundmodell mit 100 oder 400 Polys zu nehmen ist jetzt nicht so der Riesenunterschied, aber 400 oder 600000 Polys um im worst case die gleichen Details zu bekommen, das ist ein sehr großer Unterschied.
Adaptives Tessellation ist optisch belanglos, wenn man den Faktor auf 8 beschränken und gleichzeitig aus einem Low-Poly-Modell heraus Geometrie erzeugen will.Dann machst Du es eben aus einem medium-poly-Modell und voila! Ist doch nicht so schlimm. Aber wenn Du nur low-poly-Modelle nehmen willst, ist Tess unbedingt erforderlich, sprich, daß ist DX11-exklusiv. Und dann kann man ja auch eher höhere Tessfaktoren nehmen, oder? Das würde ich aber erst mittelfristig erwarten.

So, nach diesem Monsterpost erwarte ich, daß Du mich mal endlich mit dem Kram in Ruhe läßt, aber das habe ich auch schon nach der PM gedacht :rolleyes:.

deekey777
2011-01-25, 20:38:08
Anandtech über den Catalyst 11.1a Hotfix (http://www.anandtech.com/show/4137/amds-gtx-560-ti-counteroffensive-radeon-hd-6950-1gb-xfxs-radeon-hd-6870-black-edition/4).

N0Thing
2011-01-27, 14:27:13
Schalt mal Tesselation bei Metro ab. Lass alles andre an und Du wirst sehen was mit den Frames passiert.;D

Einmal mit einmal ohne Tesselation macht schon einiges aus :smile:

Bin erst jetzt dazu gekommen deinen Versuch nachzustellen. So lange man DoF benutzt, macht es auf einer GTX 470 quasi keinen Unterschied, ob man Tesselation aktiviert oder nicht, die Unterschiede bei den fps sind marginal. Erst wenn DoF nicht aktiv ist, kann man durch die Deaktivierung von Tesselation deutlicher an fps hinzu gewinnen.

Da du geschrieben hast, man solle alles andere an lassen, kann ich nur sagen, daß mit den Frames bei mir nichts spannendes passiert, wenn ich Tesselation deaktiviere.
Mit welcher Karte und mit welchen Einstellungen sind deine Bilder entstanden?

Versuch:


Bei mir kam eine GTX 470 mit den Standardtaktraten zum Einsatz, Auflösung 1680x1050, im Spiel alle Settings maximiert, AAA als Antialiasingeinstellung.
Szene: Anfang Chapter 2, Bourbon

DoF: AN; Tesselation: AN

Frames, Time (ms), Min, Max, Avg
285, 10000, 28, 29, 28.500


DoF: AN; Tesselation: AUS
Frames, Time (ms), Min, Max, Avg
334, 10000, 32, 34, 33.400


DoF: AUS; Tesselation: AN
Frames, Time (ms), Min, Max, Avg
379, 10000, 36, 39, 37.900


DoF: AUS; Tesselation: AUS

Frames, Time (ms), Min, Max, Avg
477, 10000, 45, 49, 47.700

=Floi=
2011-01-29, 12:16:49
bekommt man durch die dynamische anpassung nicht wieder so toll aufploppendes lod zu gesicht?!
ich meine mal grob über den daumen gepeilt ändert es nicht an diesem alten problem und wenn ich mir das gar cry 1 ansehe ist die holzhammermethode "alles auf max" in der ini noch immer mist das beste.
Das ist wie mit SSAA total ineffizient, aber mit die beste optik.

N0Thing
2011-01-29, 13:00:10
Da ja keine Dinge aufploppen, sondern nur vorhandene Elemente feiner werden, sollte das eigentlich nicht sonderlich auffallen. Mir ist bisher in keiner Techdemo und in keinem Spiel ein aufploppen durch dynamische Tesselierung aufgefallen.

Gipsel
2011-01-29, 23:40:52
bekommt man durch die dynamische anpassung nicht wieder so toll aufploppendes lod zu gesicht?!
Nein, nicht unbedingt. Der DX11-Tessellator unterstützt sogenannte fraktionale Tessellationsfaktoren, also nicht nur ganzzahlige. Und wenn man die Tessfaktoren kontinuierlich durchfährt, springt da gar nichts. Das ist extra so ausgelegt.
Die Anzahl der Dreiecke ändert sich zwar immer nur beim Überschreiten von ganzzahligen Faktoren (dazwischen -also bei fraktionalen- nicht). Aber die jeweils neu hinzukommenden Dreiecke haben erstmal gar keine Fläche. Erst bei steigendem Nachkomma-Anteil bei den Tessfaktoren werden die langsam größer und somit sichtbar. Insgesamt erreicht man damit einen kontinuierlichen Übergang bei Änderung der Dreieckszahl.

Gast
2011-02-14, 15:32:50
or example, if a game uses tessellation, but sets the level to 64 - it really doesn't look any different than say level 16; but the performance impact of setting tessellation to 64 will be quite substantial; so in those instances we want to make sure the majority of our customers get a good experience when playing that game.
Interview with Andrew Dodd - AMD Catalyst Software Product Manager (http://www.hardwareheaven.com/interviews.php?interviewid=28)

desert
2011-03-09, 08:18:02
War ja irgendwie klar, das es nicht vernünftig eingesetzt wird.


....In jedem Fall laviert sich AMD auch schon mit nur einem einzigen Beispiel (und ganz besonders in diesem Beispiel!) auf sehr dünnes Eis – denn es sieht so aus, als wolle AMD die Tesselations-Optimierung doch als Cheat einsetzen.

So wie es hier nun läuft, entspricht dies überhaupt nicht dem, was AMD einst versprochen hatte (Tesselations-Optimierung nur für LowCost- und Mainstream-Karten), und entspricht auch nicht dem, was wir uns erhofft hatten (offensive Informationspolitik, in welchen Anwendungen und auf welchen Grafikkarten die Tesselations-Optimierung eingesetzt wird). Die Krone setzt dem ganzen auf, daß AMD hier die Tesselations-Optimierung nicht in einem realen Spiel anwendet, wo dies zugunsten von mehr beim Spieler ankommender Performance ja durchaus (unter gewissen Voraussetzungen) sinnvoll ist – sondern in einem theoretischen Benchmark, noch dazu einem expliziten Tesselations-Benchmark. Denn ganz egal ob AMD in einiger Zeit dutzende Spiele mit Tesselations-Optimierungen beglückt, aus einem theoretischem Benchmark hat man sich damit immer herauszuhalten....

mehr auf www.3dcenter.de ;)

boxleitnerb
2011-03-09, 08:55:34
Mir war es auch klar, aber in anderen Foren wurde ich dafür verrissen. Die Leute sind meist naiv und sehen nur eine Seite der Medaille. Hätte man den Schalter analog zu AA/AF ausgelegt, dass standardmäßig die Anwendung über den Level bestimmt, wäre es kein Problem und ein zusätzliches sehr positives Feature. Aber so...

Ephiriel
2011-03-09, 09:02:59
Gibts dafür auch ein Paar Screens zum vergleich?
Mich würd das mal interessieren wie hier der Unterschied aussieht zwischen den einzelnen Stufen im Heaven-Benchmark.

lg

boxleitnerb
2011-03-09, 09:08:48
Schlammsau hat ein paar Screenshots gemacht, musst mal das Forum durchforsten.
Ob man einen Unterschied sieht oder nicht, ist für einen synthetischen Benchmark aber nicht relevant, weil hier gerade die Performance getestet und verglichen werden soll. Und das geht nicht, wenn man die Last künstlich verringert.

Edit:
btw...wie kommt ihr drauf, dass der Schalter nur für die 6990 aktiv ist und nicht für alle Karten? Sie haben eben nur die 6990 mit dem Treiber getestet.

Schlammsau
2011-03-09, 09:25:40
Gibts dafür auch ein Paar Screens zum vergleich?
Mich würd das mal interessieren wie hier der Unterschied aussieht zwischen den einzelnen Stufen im Heaven-Benchmark.

lg

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8518885#post8518885
http://www.3dcenter.org/artikel/amd-mit-tesselations-optimierung

Ephiriel
2011-03-09, 09:52:04
Ob man einen Unterschied sieht oder nicht, ist für einen synthetischen Benchmark aber nicht relevant, weil hier gerade die Performance getestet und verglichen werden soll. Und das geht nicht, wenn man die Last künstlich verringert.
Da stimm ich dir auch zu, hat mich halt trotzdem interessiert, in wie weit sich das aufs Bild auswirkt.
Allerdings erscheint mir das ganze für Spiele eine durchaus sinnvolle Funktion zu sein, sollte man einmal ans Leistungslimit stoßen, da der Unterschied ja nicht gerade groß erscheint (Beziehe mich hier auf den Artikel, da ich die Forum-Screens hier nicht sehen kann :frown:)


http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8518885#post8518885
http://www.3dcenter.org/artikel/amd-mit-tesselations-optimierung
Danke :)

boxleitnerb
2011-03-09, 10:00:26
Bei Spielen finde ich das Feature im Prinzip auch gut. Bloß fehlt mir hier die Transparenz:

Wird hier für jede einzelne Karte(nfamilie) separat optimiert oder bekommt eine 6850 dieselbe Optimierung wie eine 6990, die sich deutlich in der Performance unterscheiden? Ändert sich von Treiber zu Treiber etwas?

Man stelle sich vor, in den Anwendungsprofilen würde pauschal für Crysis 2 2xMSAA empfohlen, weil alles darüber zuviel Leistung kostet und angeblich keinen optischen Unterschied bringt. Dummerweise gibt es Karten, die locker mehr als 2xMSAA schaffen. Und auch will der eine 30fps, der nächste 60, der dritte 100. Der eine sieht die leichten Bildqualitätsunterschiede, der andere nicht. Es gibt ein so breites Performancespektrum und so unterschiedliche Ansprüche, dass eine generelle Empfehlung, wie AMD sie mit "AMD Optimized" gibt, sinnlos ist.

deekey777
2011-03-09, 10:35:06
Verstehe ich as richtig: Die Golem-Jungs sind die einzigen, den es aufgefallen ist?

y33H@
2011-03-09, 10:54:50
Vll sind sie die einzigen, die so getestet haben.

boxleitnerb
2011-03-09, 11:32:10
Das find ich von golem auch ein starkes Stück. Sie merken es, sie erwähnen es und trotzdem verzerren sie den Vergleich...und weisen auch noch darauf hin! :freak:

Das Verrückte daran ist, dass sie damit noch zu den besseren Seiten gehören. Die Masse wird benchen und keinen Satz dazu schreiben außer "AMD hat mit dem neuen Treiber 50% mehr Performance rausgeholt ftw111elf!"

Exxtreme
2011-03-09, 11:32:54
Was hat Golem denn rausgefunden? Gibt es einen Link?

boxleitnerb
2011-03-09, 11:34:21
Steht in der gestrigen News. Die Tessellationkontrolle wurde für Unigine Heaven aktiviert in einem aktuellen Pressetreiber und begrenzt das Level auf 4x.

deekey777
2011-03-09, 11:34:53
Was hat Golem denn rausgefunden? Gibt es einen Link?
http://www.golem.de/1103/81952-4.html
Auch auf der Hauptseite steht was dazu.
Steht in der gestrigen News. Die Tessellationkontrolle wurde für Unigine Heaven aktiviert in einem aktuellen Pressetreiber und begrenzt das Level auf 4x.
Nicht ganz:
Der Launch-Treiber hat ein Tessellationsprofil für Unigine Heaven 2.0, der offenbar maximal einen TF von 4 zulässt. Da AMD Optimized default ist und keiner was gesagt hat, wurden die Tests mit diesem Profil durchgeführt. Möglicherweise enthält dieser Treiber auch weitere Profile.

DrFreaK666
2011-03-09, 11:48:26
Ja kann man das wenigstens ganz abschalten?

boxleitnerb
2011-03-09, 11:49:24
Stimmt. Ich habe mal versucht, andere Benchmarks mit dem Extreme Preset zu finden, wo auch alte Karten mit dem Treiber getestet wurden, konnte aber keine finden.
Lost Planet 2 scheint nicht betroffen zu sein, wenn man sich die Benchmarks auf CB anschaut - aber ohne einen direkten Treibervergleich kann man das schwerlich mit Sicherheit sagen. Hier sollte eine gezielte Untersuchung bei mehreren Spielen ansetzen.

Ja kann man das wenigstens ganz abschalten?

Ja. Aber es kam, wie es kommen musste:

Zitat aus dem golem.de Review:
Wir belassen für die bewerteten Benchmarks die Einstellungen auf den vorgegebenen Werten des Treibers.

DrFreaK666
2011-03-09, 11:56:50
Wir belassen für die bewerteten Benchmarks die Einstellungen auf den vorgegebenen Werten des Treibers.

WOW, wie schlau ist das denn??
Ich denke mal, dass sich bald jemand nur mit Tesselation-Software und dem Treiber beschäftigen wird.
Bin auf die Ergebnisse gespannt...

boxleitnerb
2011-03-09, 12:01:35
Das hat mich so geärgert, ich hab dem Autor mal eine Mail geschrieben diesbezüglich. Sowas gleich im Keim ersticken, sonst machen es noch andere nach.

Locuza
2011-03-09, 12:27:38
Laut Planet3DNOW! haben wir ja noch Hoffnung.
Hoffentlich halten die bösen Reaktionen sie auch sofort davon ab, dass in den Kopf zu bekommen.

Nach Rücksprache mit AMD wurde uns mitgeteilt, dass weder im Review-Treiber noch im Preview des AMD Catalyst 11.4 Tessellation-Profile hinterlegt seien. Die Beobachtungen seien ausschließlich auf einen Fehler im Treiber zurückzuführen. Ersten Untersuchungen zu Folge tritt der Fehler erst auf, wenn der Tessellation-Faktor über den entsprechenden Schieberegler im Catalyst Control Center verstellt und danach wieder "AMD Optimized" aktiviert wird. Offenbar verursacht ein Fehler im Treiber, dass der zuvor eingestellte Tessellation-Faktor im Unigine Heaven Benchmark angewendet wird, obwohl "AMD Optimized" aktiviert und der Tessellation-Schieberegler ausgegraut ist. Laut AMD konnte Golem dies auch bereits gegenüber AMD bestätigen. Das Treiber-Team arbeitet derzeit daran, diesen Fehler so schnell wie möglich zu beseitigen.

DrFreaK666
2011-03-09, 12:29:58
Laut Planet3DNOW! haben wir ja noch Hoffnung.
Hoffentlich halten die bösen Reaktionen sie auch sofort davon ab, dass in den Kopf zu bekommen.

War klar, dass es nur ein Bug ist :freak:

Winter[Raven]
2011-03-09, 12:54:15
War klar, dass es nur ein Bug ist :freak:

It's not a BUG.... it's just a feature ^^ :freak:

Nakai
2011-03-09, 12:57:10
Hab die News gestern schon gelesen. Naja wieder eine AMD-artige Sauerei.
Die sollten mal ihr CCC-Team feuern...cheaten is nich gut.


mfg

LovesuckZ
2011-03-09, 13:00:04
Jemand sollte man Stone Giant testen. Bei Kitguru (http://www.kitguru.net/components/graphic-cards/zardon/amd-radeon-hd6990-review/7/) ist eine 6990 mehr als doppel so schnell als eine 6970...

dllfreak2001
2011-03-09, 13:09:38
;( Schade drum, AMD lässt nichts aus um sein Image in den Keller zu treiben.
Ein echter Cheat ist es zwar nicht, dass aber ein Tess-Benchmark explizit im Detail gesenkt wird spricht Bände.

Ich bleibe erstmal bei Nvidia.

Hugo78
2011-03-09, 13:11:01
Das Fazit von Kitguru, über die mehr als Verdoppelung, fällt auch recht naiv aus.
This jump in hardcore tessellation performance is something that no one would have predicted.
You can’t help feeling that AMD’s original tessellation engine, in the 5000 series, was broken and that AMD has been fixing the issue in leaps and bounds.

Wenn man HW Redakteur ist und ein solches Ergebnis ganz offensichtlich "überrascht", weil nicht möglich angesichts der bekannten HW Daten,
dann sollte man doch anfangen ein paar Dinge zu hinterfragen...

boxleitnerb
2011-03-09, 13:25:24
Auch der hat ne Mail bekommen. Mal gespannt, ob und was er antwortet. Ich hab ihn gebeten, SG nochmal zu benchen mit verschiedenen Settings, demselben Treiber und 6970 und 6990.

Ronny145
2011-03-09, 13:34:01
Laut Planet3DNOW! haben wir ja noch Hoffnung.
Hoffentlich halten die bösen Reaktionen sie auch sofort davon ab, dass in den Kopf zu bekommen.


Nach Rücksprache mit AMD wurde uns mitgeteilt, dass weder im Review-Treiber noch im Preview des AMD Catalyst 11.4 Tessellation-Profile hinterlegt seien. Die Beobachtungen seien ausschließlich auf einen Fehler im Treiber zurückzuführen. Ersten Untersuchungen zu Folge tritt der Fehler erst auf, wenn der Tessellation-Faktor über den entsprechenden Schieberegler im Catalyst Control Center verstellt und danach wieder "AMD Optimized" aktiviert wird. Offenbar verursacht ein Fehler im Treiber, dass der zuvor eingestellte Tessellation-Faktor im Unigine Heaven Benchmark angewendet wird, obwohl "AMD Optimized" aktiviert und der Tessellation-Schieberegler ausgegraut ist. Laut AMD konnte Golem dies auch bereits gegenüber AMD bestätigen. Das Treiber-Team arbeitet derzeit daran, diesen Fehler so schnell wie möglich zu beseitigen.

Das wäre nahezu unglaublich das die erst jetzt von den buggy Schaltern erfahren. Der Fehler besteht seit dem ersten Treiber mit Tessellation Slider und auch jetzt noch im 10.4 Preview was mich unheimlich nervt. Das muss doch AMD auffallen beim Testen. Da kann man den naiven Testern von golem gar keinen Vorwurf machen. Nachdem bei hardwarecanucks und hexus keinerlei Unstimmigkeiten in Unigine zu erkennen sind, war mir das fast klar.

boxleitnerb
2011-03-09, 13:41:59
Allan von kitguru meint, er testet nächste Woche nochmal die 6990 und geht dann auch darauf ein. Ob da auch der Bug drinsteckt, bezweifle ich, weil er mit ziemlicher Sicherheit nicht mit dem Regler rumgespielt hat vorher.

Gipsel
2011-03-09, 14:14:27
Das wäre nahezu unglaublich das die erst jetzt von den buggy Schaltern erfahren. Der Fehler besteht seit dem ersten Treiber mit Tessellation Slider und auch jetzt noch im 10.4 Preview was mich unheimlich nervt. Das muss doch AMD auffallen beim Testen. Da kann man den naiven Testern von golem gar keinen Vorwurf machen. Nachdem bei hardwarecanucks und hexus keinerlei Unstimmigkeiten in Unigine zu erkennen sind, war mir das fast klar.
Ich behaupte mal, das war mit ein wenig Nachdenken von Anfang an die wahrscheinlichste Erklärung. :rolleyes:

Erkläre nichts mit Vorsatz, was auch mit Unvermögen möglich ist! :freak:

Nakai
2011-03-09, 14:27:25
Das wäre nahezu unglaublich das die erst jetzt von den buggy Schaltern erfahren. Der Fehler besteht seit dem ersten Treiber mit Tessellation Slider und auch jetzt noch im 10.4 Preview was mich unheimlich nervt. Das muss doch AMD auffallen beim Testen. Da kann man den naiven Testern von golem gar keinen Vorwurf machen. Nachdem bei hardwarecanucks und hexus keinerlei Unstimmigkeiten in Unigine zu erkennen sind, war mir das fast klar.

Its not a bug...its a fea....ach lassen wir das.

Das wurde wohl absichtlich eingebaut. Ein Fehler genau da, wo AMD gegenüber NV schlechter abschneidet, kann man sich nicht vorstellen.;D

kruemelmonster
2011-03-09, 14:59:31
Das ganze war ja sowas von arschklar...ich erwarte nichts, aber auch gar nichts mehr von AMD. Bei denen geht es nur um Kompromisse und Einschränkungen und nicht um Möglichkeiten.


AF-Berechnungen im Eimer?
Kein Problem Chef, wir vertuschen das mit AI, und es wird schon eh keiner merken.


Stromverbrauch geht durch die Decke?
Kein Problem Chef, wir begrenzen einfach die maximale Stromaufnahme und lassen alles was drüber liegt wegthrotteln. Werden schon keine Spiele/Apps kommen die über dem Limit liegen...


Tesselation-Engine taugt nix?
Kein Problem Chef, wir lassen nur soviel tesselieren wie unsere Karten noch schnell sind, darüber wird gecappt.


Dann kommt noch die PR dazu und faselt was von "dem Besten für unsere Kunden". Und die Meute applaudiert auch noch...:facepalm:

Ich kann diese Firma als Anbieter von 200€+ Grafikkarten einfach nicht ernst nehmen, da sie sich scheinbar um das Klientel für 200€+ Grafikkarten und deren Ansprüche überhaupt nicht kümmert. Stattdessen werden dämliche Werbebildchen für Spiele in das Installationsmenü des Treiber eingebaut, so dass bei zu geringer Auflösung der "Weiter"-Button hinter der Taskleiste liegt. Ganz großes Kino. :freak:

NV hat auch jahrelang bei 8x MSAA mehr fps-Verlust als AMD gehabt, und sie haben zu diesem Manko gestanden und es nicht "vernebelt". AMD dagegen hat das Nebel-Spiel schon so gut raus, dass sie versuchen dem Kunden einen Bug als Feature zu verkaufen.

NV frickelt nicht jahrelang am AF umher, einmal richtig gemacht mit G80 und das Thema ist abgehakt.
Mit Tesselation ist es die gleiche Geschichte: TruForm gab es schon auf dem R200 und es läuft auf dem RV800 noch beschissen, NV macht es dagegen einmal richtig mit dem GF100 und das Thema ist durch. Fertig. Nächste Aufgabe bitte.

Mag sein das Eyefinity ein tolles Feature ist, mag auch sein das NV ein AA-Defizit durch den Boxfilter hat, aber in der Gesamtheit aller Eigenschaften sehe ich keinen Grund mein Geld AMD in den Rachen zu werfen.
Die gehören für ihren Mist genauso durch Verzicht abgestraft wie Ubisoft.

Nakai
2011-03-09, 15:15:56
Stromverbrauch geht durch die Decke?
Kein Problem Chef, wir begrenzen einfach die maximale Stromaufnahme und lassen alles was drüber liegt wegthrotteln. Werden schon keine Spiele/Apps kommen die über dem Limit liegen...

All deine Kritikpunkte in Ehren(bei denen stimm ich zu), außer bei dem hier.
Ich sehe keine Problematik dabei. Vor allem werden ähnliche Technologien schon woanders eingesetzt. TDP-Begrenzung ist alles, nur nicht schwachsinnig.

Mag sein das Eyefinity ein tolles Feature ist, mag auch sein das NV ein AA-Defizit durch den Boxfilter hat, aber in der Gesamtheit aller Eigenschaften sehe ich keinen Grund mein Geld AMD in den Rachen zu werfen.
Die gehören für ihren Mist genauso durch Verzicht abgestraft wie Ubisoft.

Der Witz an der Sache ist, dass diese Mankos nur wegen architekturellen Defiziten entstanden sind. ;D
Viele dieser Probleme sind eher aus der Not entstanden.
Beim AF-Problem verspricht man ja langsam Besserung, natürlich nur, nachdem die Presse jahrelang auf die Probleme hingewiesen hat.:freak:

Das macht die Tesselationsbegrenzung natürlich nicht weniger schlimm ist. Was ich viel schlimmer finde ist, dass viele namhaften Zeitschriften und Seiten diese Fehler nicht erkannt haben(!!!). Das zeugt doch schon von der Qualität mancher Redakteure. Ich hoffe, dass einige Seiten diese Problematik nochmal aufrollen. Schadensbegrenzung ist jetzt angesagt.


mfg

y33H@
2011-03-09, 15:19:41
Dieser Bug ist altbekannt, seit die Funktion erstmals im Treiber auftauchte. Profile gibt's derzeit keine bzw. es wäre mir neu.

Gipsel
2011-03-09, 15:24:45
Dieser Bug ist altbekannt, seit die Funktion erstmals im Treiber auftauchte. Profile gibt's derzeit keine bzw. es wäre mir neu.
Genau so sieht es immer noch aus. Sturm im Wasserglas das Ganze.

desert
2011-03-09, 15:48:08
Genau so sieht es immer noch aus. Sturm im Wasserglas das Ganze.

Bei Nvidia wäre es schon eine weltweiter sturm der entrüstung. Aber immer wieder schön wie bei amd relativiert wird.

kruemelmonster
2011-03-09, 16:52:32
All deine Kritikpunkte in Ehren(bei denen stimm ich zu), außer bei dem hier.
Ich sehe keine Problematik dabei. Vor allem werden ähnliche Technologien schon woanders eingesetzt. TDP-Begrenzung ist alles, nur nicht schwachsinnig.

Schwachsinnig wäre ein zu hartes Wort...

Die Problematik sehe ich darin, das AMD mittlerweile auf eine Drossel zwingend angewiesen ist, sonst wäre z.B. das Antilles-Monster in der Form nicht möglich gewesen.
AMD ist bekannt dafür mehr auf Kante zu bauen als NV (und aktuell scheinbar darüber hinaus), daher sehe ich die Drossel als einen weiteren Bestandteil im großen Flickenteppich namens Radeon.


Das macht die Tesselationsbegrenzung natürlich nicht weniger schlimm ist. Was ich viel schlimmer finde ist, dass viele namhaften Zeitschriften und Seiten diese Fehler nicht erkannt haben(!!!). Das zeugt doch schon von der Qualität mancher Redakteure. Ich hoffe, dass einige Seiten diese Problematik nochmal aufrollen. Schadensbegrenzung ist jetzt angesagt.
mfg

Die Tesselationsbegrenzung ist ja nur ein Punkt unter vielen. Am schlimmsten finde ich den Punkt, dass AMD scheinbar Narrenfreiheit sowohl bei den User als auch bei der Mehrheit der Presse hat. Eine Einschränkung nach der anderen und alles wird hingenommen, nichts wird hinterfragt, Hauptsache schnell die Benchmarks mit Treiberdefault durchgejagt und das "Review" online gestellt. Das ist keine vierte Gewalt mehr sondern der verlängerte Arm der PR.

Gipsel
2011-03-09, 16:59:37
Die Tesselationsbegrenzung ist ja nur ein Punkt unter vielen. Am schlimmsten finde ich den Punkt, dass AMD scheinbar Narrenfreiheit sowohl bei den User als auch bei der Mehrheit der Presse hat. Eine Einschränkung nach der anderen und alles wird hingenommen, nichts wird hinterfragt, Hauptsache schnell die Benchmarks mit Treiberdefault durchgejagt und das "Review" online gestellt. Das ist keine vierte Gewalt mehr sondern der verlängerte Arm der PR.
Du hast scheinbar eine eher etwas einseitige Wahrnehmung der Presse in diesem Punkt. Nur als Beispiel soll hier die Sache mit dem AF angeführt werden, die doch inzwischen nicht mehr nur vom 3DC immer wieder beleuchtet wird.

Im Übrigen sind wir hier in keinem Forum für Medienkritik, ich bitte also darum, beim Thema zu bleiben.

dr_mordio
2011-03-09, 17:21:07
Die Problematik sehe ich darin, das AMD mittlerweile auf eine Drossel zwingend angewiesen ist, sonst wäre z.B. das Antilles-Monster in der Form nicht möglich gewesen.
.

Hmm, du weißt aber schon, das auch Nvidia bei der 580er eine solche drossel drinnen hat.
das sind auch die ersten experimente gewesen, denn auch bei NV geht mit einer doppel-580er nichts mehr ohne begrenzer, wenn das teil wirklich schneller werden soll als eine einzelne 580er

In so fern kann man AMD nicht was ankreiden und es beim nächsten totschweigen

MfG
Alex

Gipsel
2011-03-09, 18:06:39
Dann noch mal etwas auffälliger:

Back to Topic!

=Floi=
2011-03-09, 18:18:34
bitte unterscheide beide drosselungen!
bei ati ist die drossel in der hardware verankert und default "on".
bei nv existiert die drossel in software und muß extra aktiviert werden. bei einem neuen spiel, welches nicht erkannt wird ist die drossel aus! Über gpuz lässt sich die die drossel relativ einfach ausschalten und auch die stromversorgung der 580er ist ähnlich die der 480er. Weshalb von dieser seite auch keine überprpportionale belastung ausgeht, weil man am pcb gespart hat. Bei nv ist die drossel wesentlich höher angesetzt wie bei ati.


---
edit
trotzdem könnte der tesselations-gui-bug schon längst gefixt sein...

Na gerade noch mal so mit dem Edit gerettet! ;)

Schaffe89
2011-03-09, 21:04:57
Die Problematik sehe ich darin, das AMD mittlerweile auf eine Drossel zwingend angewiesen ist, sonst wäre z.B. das Antilles-Monster in der Form nicht möglich gewesen.

Nvidia drosselt auch dort, wo es erforderlich ist.
Das Problem ist vielmehr, dass man immer mehr Einheiten auf die Dies presst und dann Probleme hat, wenn wirklich "alle" ausgelastet werden.
Sehe hier kein Problem, was die Usability angeht.

Am schlimmsten finde ich den Punkt, dass AMD scheinbar Narrenfreiheit sowohl bei den User als auch bei der Mehrheit der Presse hat.

Bitte bleib wieder mal auf dem Teppich, bei der ganzen AF Kritik, hat AMD teilweise zurecht schon viel eingesteckt und kann weniger Grafikkarten verkaufen, weil viele Basher und Fanboys, das Thema extrem aufgebauscht haben.
AMD hat die Tess-Control angekündigt und jetzt ist sie scheinbar da.
Warum sie die Profile alledings für Benchmarks freigeschalten haben, ist mir selbst ein Rätsel.
Ich hoffe ein Fehler.

NV frickelt nicht jahrelang am AF umher, einmal richtig gemacht mit G80 und das Thema ist abgehakt.
Mit Tesselation ist es die gleiche Geschichte: TruForm gab es schon auf dem R200 und es läuft auf dem RV800 noch beschissen, NV macht es dagegen einmal richtig mit dem GF100 und das Thema ist durch. Fertig. Nächste Aufgabe bitte.

Ich bitte von solcher unnötiger agressiver Meinungsmache abzusehen. Das teilweise erbärmliche Geschwafel am euten politischen Aschermittwoch hat gereicht.
Die Tessleistung bei AMD ist derzeit völlig ausreichend und läuft nicht beschissen.

aber in der Gesamtheit aller Eigenschaften sehe ich keinen Grund mein Geld AMD in den Rachen zu werfen.
Die gehören für ihren Mist genauso durch Verzicht abgestraft wie Ubisoft.

Alles sehr einseitig und übertrieben.
Im Grunde stimme ich trotzdem teilweise zu, sofern man die sachlichen Argumente aus dem von dir verzapften Text heraussiebt.

Die Tesselationsbegrenzung ist ja nur ein Punkt unter vielen. Am schlimmsten finde ich den Punkt, dass AMD scheinbar Narrenfreiheit sowohl bei den User als auch bei der Mehrheit der Presse hat.

Angebliche ganz, ganz viele Punkte die du vorgibst auszuführen.
AMD Ende bleibt aber objektiv gesehen nur minimal schlechteres AF und eine Funktion die den Tess Grad begrenzt, aber abschaltbar ist und manche Redaktuere trotz vorher angekündgtem Begrenzer überrennt.
Oder willst du eine Grundsatzdiskussion starten, in der aufgeführt wird, was sich Nvidiaoder AMD im Bezug auf Kundenfreundlichkeit schon alles geleistet haben?

Soviel musste ich einfach loswerden. Sry for off Topic.

airbag
2011-03-09, 21:17:48
Ich behaupte mal, das war mit ein wenig Nachdenken von Anfang an die wahrscheinlichste Erklärung. :rolleyes:

Erkläre nichts mit Vorsatz, was auch mit Unvermögen möglich ist! :freak:

Das wäre ja eine Armutserklärung. :freak:

Das sie es gerade nicht im Heaven Benchmark merken, der die Referenz ist, würde mich arg wundern. Wenn sie es beim Testen bemerkt hätte, wäre es dann schon wieder Vorsatz.

Gipsel
2011-03-09, 21:31:00
Das wäre ja eine Armutserklärung. :freak:

Das sie es gerade nicht im Heaven Benchmark merken, der die Referenz ist, würde mich arg wundern. Wenn sie es beim Testen bemerkt hätte, wäre es dann schon wieder Vorsatz.
Also, noch mal für alle, die das immer noch nicht mitbekommen haben:
Das Verhalten der Beta-Treiber zum HD6990-Launchtreiber ist identisch zu allen anderen Treiberversion mit integrierter (offensichtlich im alpha-Stadium) Tess-Control im Controlpanel. Es hat sich nichts geändert, es gibt keine Profile dafür und auch Heaven läuft nicht schneller als zwei HD6970 im Crossfire.

Was Golem schlicht gemacht hat, ist am Tess-Slider rumzuspielen, der eben bekanntermaßen auch schon in vorherigen Treiberversionen verbuggt reagiert. Limitiert man manuell den Tess-Grad und stellt nachher einfach nur wieder auf "AMD optimized" zurück, so wird diese Einstellung nicht übernommen, der Tess-Grad bleibt limitiert. Man muß den manuellen Slider wieder zurück auf 64x fahren, damit die Limitierung wieder aus ist. Ohne das jemand an der Limitierung im Controlpanel rumspielt, ist die Limitierung standardmäßig aber immer noch aus. Golem hat das inzwischen soweit ich weiß auch bestätigt. Andere Tests mit dem gleichen Treiber haben übrigens auch keine Änderung bei Heaven gesehen.

=> Sturm im Wasserglas; riesige Aufregung, aber nix hat sich geändert

Im letzten Punkt irrt übrigens die Newsmeldung auf der 3DC-Startseite. Der Bug tritt nicht erst mit der neuen 11.4-Beta-Version auf, der Bug ist schon so lange drin, wie es den Tess-Slider gibt. Kann man ja hier im Thread einfach nachlesen.

Schaffe89
2011-03-09, 21:53:59
Gut, dann hat sich die Aufregung, wie auch zu Beginn der Einführung des Tess Schalters wiedermal in Luft aufgelöst.
Habe ebenfalls grade mit meiner HD6970 PCS+ den neuen Treiber getestet.
Keine Performanceunterschiede in Stone Giant oder Unigine Heaven, außer minimale Verbesserungen im einstelligen, niedrigen Prozentbereich, bei Unigine @ 1650x1080 8xAA Tess Etxreme

Spike2
2011-03-09, 22:31:09
Dennoch sehr merkwürdig... ich meine ein Bug, daß einfach eine Einstellung von einem GUI-Element nicht übernommen wird zu fixen, schaffe sogar ich als C++-Noob. Ein professioneller Coder sollte da höchstens 5 Minuten für brauchen, also wieso ist der Bug noch da?

Gipsel
2011-03-09, 22:40:47
Dennoch sehr merkwürdig... ich meine ein Bug, daß einfach eine Einstellung von einem GUI-Element nicht übernommen wird zu fixen, schaffe sogar ich als C++-Noob. Ein professioneller Coder sollte da höchstens 5 Minuten für brauchen, also wieso ist der Bug noch da?
Weil die QC der Treiberabteilung für ein nicht vermarktetes Feature des Treibers praktisch Null ist? Die wissen doch offenbar erst seit gestern, daß es den Bug überhaupt gibt. Bis dann die korrigierte Version irgendwann mal durch die internen Tests ist und schlußendlich noch die WHQL-Zertifizierung hinter sich hat, vergehen schon mal ein paar Wochen. Aber für den Cat 11.5 bin ich halbwegs zuversichtlich. Vielleicht gibt es etwas zeitnäher einen Hotfix :freak:

LovesuckZ
2011-03-09, 22:52:30
Dennoch sehr merkwürdig... ich meine ein Bug, daß einfach eine Einstellung von einem GUI-Element nicht übernommen wird zu fixen, schaffe sogar ich als C++-Noob. Ein professioneller Coder sollte da höchstens 5 Minuten für brauchen, also wieso ist der Bug noch da?

Weil dieses Verhalten gewollt ist. Wenn niemand so aufmerksam wie Golem.de ist, um nochmal halbwegs über das Ergebnis nachdenkt, werden so doch super tolle positive Ergebnisse geliefert. Und einen Nachteil gibt es ja nicht, da maximal der angeforderte Grad eingestellt wird.
Also eine Win-Win Situation für AMD.

Bucklew
2011-03-09, 22:56:09
War natürlich klar, dass jetzt ein gewisser Mod hier wieder anfängt seine Modrechte zu missbrauchen, um die Diskussion in die von ihm gewünschte Richtung zu lenken. Heutiges Motto: Alles nicht so schlimm, nur ein Bug, hier gibts nichts zu sehen, bitte weiter gehen!

So, damit hast Du Dir die Bedenkzeit über meine (oder auch Undertakers) bisherigen Warnungen redlich verdient!

Und in zwei Monaten wird es dann Standard sein bei AMD, dass ALLE Karten auf ein Tessellation-Level X per Profil gezwungen wird. Genau das, was ich schon vor zwei Monaten gesagt habe. Aber natürlich, es ist ja nur ein "Bug" ;)

Gipsel
2011-03-09, 23:26:45
Wenn niemand so aufmerksam wie Golem.de ist, um nochmal halbwegs über das Ergebnis nachdenkt, werden so doch super tolle positive Ergebnisse geliefert.Wenn man böse wäre, könnte man auch sagen, daß Golem nicht aufmerksam genug war, sonst hätten sie auf den (bekannten) Bug hinweisen können und hätten kein Review mit falschen zahlen veröffentlicht. :rolleyes:

LovesuckZ
2011-03-09, 23:31:12
Wenn man böse wäre, könnte man auch sagen, daß Golem nicht aufmerksam genug war, sonst hätten sie auf den (bekannten) Bug hinweisen können und hätten kein Review mit falschen zahlen veröffentlicht. :rolleyes:

Soso: Der Bug ist also so bekannt, dass ihn Golem kennen müsste, aber die Programmierer und/oder Qualitätssicherung von AMD nicht?!

:rolleyes:

Gipsel
2011-03-09, 23:35:39
Soso: Der Bug ist also so bekannt, dass ihn Golem kennen müsste, aber die Programmierer und/oder Qualitätssicherung von AMD nicht?!Ich dachte Golem wäre (im Gegensatz zu AMDs Treiberabteilung, darüber, daß solche Bugs Monate überleben können, müssen wir ja nicht reden :freak:) aufmerksam? Und wenn hier in diesem Thread eine Handvoll Leute das in wenigen Tagen rausbekommen hat, dann ist Golem wohl (zwecks Recherche natürlich) in solchen Foren nicht wirklich present (y33h@ kannte den z.B. ja auch).

Coda
2011-03-09, 23:46:00
Gipsel ich finde auch dass du ein wenig zu unkritisch bist was die Tesselationsgeschichte angeht.

Da muss man AMD schon ganz genau auf die Finger schauen. Das hat viel zu viel Potential für unbemerktes Bescheißen.

Und es ist ja nicht so, als hätte man das in der Vergangeheit nie getan.

LovesuckZ
2011-03-09, 23:46:08
Ich dachte Golem wäre (im Gegensatz zu AMDs Treiberabteilung, darüber, daß solche Bugs Monate überleben können, müssen wir ja nicht reden :freak:) aufmerksam? Und wenn hier in diesem Thread eine Handvoll Leute das in wenigen Tagen rausbekommen hat, dann ist Golem wohl (zwecks Recherche natürlich) in solchen Foren nicht wirklich present (y33h@ kannte den z.B. ja auch).

Hä? Okay, jetzt werden wieder Postings out-of-context zitiert, daher für die Leute, die dies, aus welchen Gründen auch immer, machen:
Golem hat eine Unstimmigkeit bei den Werten festgestellt. Die Schlussfolgerung war falsch, weil man nicht wusste, dass hier ein Fehlverhalten vorliegt. Golem hätte es wissen können, aber es ist kein muss. Oder wird man im ControlPanel darüber aufgeklärt? Oder hat AMD es kommuniziert? Oh, nein. :rolleyes:
Die Lösung für diesen Bug ist wohl unter 5 Minuten zu erledigen. Das so etwas sich zwei Monate durchzieht, ist gewollt. Das du dies anders siehst, ist dann keine Überraschung.

Mancko
2011-03-09, 23:48:57
Ich dachte Golem wäre (im Gegensatz zu AMDs Treiberabteilung, darüber, daß solche Bugs Monate überleben können, müssen wir ja nicht reden :freak:) aufmerksam? Und wenn hier in diesem Thread eine Handvoll Leute das in wenigen Tagen rausbekommen hat, dann ist Golem wohl (zwecks Recherche natürlich) in solchen Foren nicht wirklich present (y33h@ kannte den z.B. ja auch).

Also ich bin zwar sonst nicht auf Golem.de aber in dem Fall muss ich die mal in Schutz nehmen. Es ist in erster Linie AMD's Aufgabe konkurenzfähige Tesselationshardware zu liefern. Wenn sie das nicht können und solche Schalter einbauen, liegt für mich erstmal grundsätzlich keine Unschuldsvermutung mehr vor. Gerade AMD hat hier zu oft in der Vergangenheit an verschiedensten Stellen herumoptimiert. Wenn AMD jetzt negative Presse bekommt, trifft es ehrlich gesagt genau die Richtigen. Es hält die Firma ja niemand davon ab es Nvidia gleich zu tun und eine gescheite Hardware Einheit für das Thema einzubauen. Desweiteren hat AMD niemand davon abgehalten den Schalter erst gar nicht rauszugeben, solange der nicht richtig funktioniert.
Die Reviewer sind nicht für AMD's Unfähigkeit in Bereichen der Hardware oder der Software verantwortlich. Es ist AMD selber. Und eine Firma die den Anspruch hat Enthusiasten Hardware zu liefern, darf so halt einfach nicht herumstümpern. Im Endeffekt gehören in jedes Review für solche Aktionen permanent richtig fett markierte Minuspunkte rein bis die Affen das dort schnallen.

Gipsel
2011-03-09, 23:50:07
Gipsel ich finde auch dass du ein wenig zu unkritisch bist was die Tesselationsgeschichte angeht.Hey, ich bin nicht unkritisch (ich dachte das hätten wir ein wenig vorher im Thread schon mal festgestellt).
Ich sage doch jetzt bloß, daß diese Meldung mit den angeblich zur HD6990 eingeführten Tess-Profilen einfach nicht stimmt und das sich wirklich gar nichts geändert hat. Damit sind wir also immer noch beim Status quo von Januar. Man wird abwarten müssen, was passiert. Aber bisher ist eben nichts passiert, noch nicht mal der von Anfang an vorhandene Bug des Sliders im Control Panel wurde behoben. Also offenbar schraubt da im Moment wirklich gar keiner an der Option. :rolleyes:

Gipsel
2011-03-09, 23:53:15
Hä? Okay, jetzt werden wieder Postings out-of-context zitiert,
WTF?!?

Ich habe Dein komplettes Posting (abzüglich zweier Zeilenumbrüche und eines Smileys am Ende) zitiert. Was daran out-of-context sein soll, darfst Du mir gerne per PN erläutern.
Golem hätte es wissen können, aber es ist kein muss.Dann lies noch mal was ich schrieb:
Wenn man böse wäre, könnte man auch sagen, daß ...
So, und jetzt sollte die Diskussion lieber mal was Substantielleres liefern.

Gipsel
2011-03-10, 00:00:20
@Mancko:
So ging das letzte Zitat von mir übrigens weiter:
... sonst hätten sie [Golem] auf den (bekannten) Bug hinweisen können ...
Wenn Du meine Posts liest, wirst Du finden, daß ich eine mangelnde Qualitätskontrolle solcher Features des Treibers/ControlPanels auch als solche bezeichne.

LovesuckZ
2011-03-10, 00:06:19
WTF?!?

Ich habe Dein komplettes Posting (abzüglich zweier Zeilenumbrüche und eines Smileys am Ende) zitiert. Was daran out-of-context sein soll, darfst Du mir gerne per PN erläutern.
Dann lies noch mal was ich schrieb:

So, und jetzt sollte die Diskussion lieber mal was Substantielleres liefern.

Ich habe den Begriff "Aufmerksamkeit" immer nur in Verbindung mit den eigenen, von Golem ermittelten Zahlen verwendet und stellte nie den Zusammenhang mit dem Verhalten des ControlPanels von AMD dar.


Wenn niemand so aufmerksam wie Golem.de ist, um nochmal halbwegs über das Ergebnis nachdenkt,[...]

Ich finde es abenteuerlich, dass du hier dauernd Leuten etwas unterstellst, dass sie nie gesagt oder ausgedrückt haben:
Wenn man böse wäre, könnte man auch sagen, daß Golem nicht aufmerksam genug war, sonst hätten sie auf den (bekannten) Bug hinweisen können [...]


Golem hat nur eine Schuld: Sie haben nicht weiter recheriert. Das war es dann auch. Aber das hat nichts mit meiner Aussage zu tun gehabt.

Ronny145
2011-03-10, 00:09:17
Weil dieses Verhalten gewollt ist. Wenn niemand so aufmerksam wie Golem.de ist, um nochmal halbwegs über das Ergebnis nachdenkt, werden so doch super tolle positive Ergebnisse geliefert. Und einen Nachteil gibt es ja nicht, da maximal der angeforderte Grad eingestellt wird.
Also eine Win-Win Situation für AMD.


Golem und aufmerksam? Dann hätten sie bemerkt, dass die 2 Schalter momentan keinen Einfluss haben - und das auch nicht erst seit Cat 11.4. Speziell wenn das aufmerksame Golem vorher noch dran rumspielt und sonderbar große Steigerungen erzielt, sollte es irgendwie einleuchten. Lässt sich ganz easy nachprüfen. Mir ist das in Unigine sofort ins Auge gefallen. Ganz lustig wirds erst wenn golem noch große Rückschlüsse draus zieht und sich Gedanken macht. Bisschen naiv von golem.


Aber auch echt unfassbar das AMD anscheinend erst jetzt drauf kommt. Es gibt einen Beta Tester im Rage3d Forum den ich das gemeldet hatte, der nur leider zu unfähig war den Fehler bei sich nachzustellen. Trotz alledem hat sich überhaupt nichts geändert. Als der Bug hier im Thread angesprochen wurde hat sich doch auch keiner aufgeregt. Es wird erst dann zum Problem, wenn ein Tester vorher am Slider rumspielt und danach Optimized oder Anwendungsgesteuert einstellt, ohne dem Wissen der funktionslosen Schalter. Immerhin weiß AMD spätestens jetzt Bescheid.

LovesuckZ
2011-03-10, 00:13:41
Golem und aufmerksam? Dann hätten sie bemerkt, dass die 2 Schalter momentan keinen Einfluss haben - und das auch nicht erst seit Cat 11.4. Speziell wenn das aufmerksame Golem vorher noch dran rumspielt und sonderbar große Steigerungen erzielt, sollte es irgendwie einleuchten. Lässt sich ganz easy nachprüfen. Mir ist das in Unigine sofort ins Auge gefallen. Ganz lustig wirds erst wenn golem noch große Rückschlüsse draus zieht und sich Gedanken macht. Bisschen naiv von golem.

Aufmerksamkeit verbindet die Entdeckung der Unstimmigkeit in den ermittelten Zahlen. Was danach folgt wäre eher Unfähigkeit die Ursache zu recherieren. Was jedoch in Bezug auf die Aufmerksamkeit keine Rolle spielt.


Als der Bug hier im Thread angesprochen wurde hat sich doch auch keiner aufgeregt. Es wird erst dann zum Problem, wenn ein Tester vorher am Slider rumspielt und danach Optimized oder Anwendungsgesteuert einstellt, ohne dem Wissen der funktionslosen Schalter. Immerhin weiß AMD spätestens jetzt Bescheid.

Das ist normales Verhalten. Meisten fällt soetwas unter dem Tisch, weil es andere, interessanteste Dinge gibt, oder es fehlt der Weitblick, um alle Konsequenzen zu erkennen. Bis es dann eben zum Eklat kommt.

Gipsel
2011-03-10, 00:15:28
@LS:
Ich hatte Dich um eine PN gebeten, aber ehrlich gesagt erschließt sich mir die Argumentation Deines Postings auch nicht. Insbesondere dieser Teil:Ich finde es abenteuerlich, dass du hier dauernd Leuten etwas unterstellst, dass sie nie gesagt oder ausgedrückt haben???

Aber bevor ich mich wiederhole, am besten liest Du Dir die Ausführungen von Ronny145 durch, der sagt grob das Gleiche wie ich mit anderen Worten.

Gipsel
2011-03-10, 00:26:35
Aufmerksamkeit verbindet die Entdeckung der Unstimmigkeit in den ermittelten Zahlen. Was danach folgt wäre eher Unfähigkeit die Ursache zu recherieren.Achso, ich sehe. Du betreibst Wortdeuterei und führst eine Trennlinie zwischen "unaufmerksam" und "unfähig" ein. Alles klar!
Aber das müssen wir ja nicht hier im Thread betreiben bitte.

Schlammsau
2011-03-10, 05:59:16
Dieser Bug ist schon seit der Einführung dieses Reglers hier aufgefallen.

Einfach mal auf die Anfangsseiten dieses Threads schauen.

Fakt ist, wenn man den Schalter nicht angerührt hat, stimmen die Werte auch.

Coda
2011-03-10, 06:04:18
Dann ist ja gut. Und das meine ich nicht einmal ironisch.

Schaffe89
2011-03-10, 10:22:31
Weil dieses Verhalten gewollt ist. Wenn niemand so aufmerksam wie Golem.de ist, um nochmal halbwegs über das Ergebnis nachdenkt, werden so doch super tolle positive Ergebnisse geliefert. Und einen Nachteil gibt es ja nicht, da maximal der angeforderte Grad eingestellt wird.
Also eine Win-Win Situation für AMD.

Nun, dass du hinter jedem Bug oder Fehler eine gewisse vorgehensweise von AMD vermutest, was deiner unbändigen Befangenheit geschuldet ist.
Ich erinnere mich noch an die plumpe und unnötige Meinungsmache, als du den Thread eröffnet hast und an die ganzen Trollversuche gegenüber mir und gegenüber Mods.
Und eine Win-Win Situation ist das nicht, oder hast du dir schonmal das Golem Fazit durchgelesen?
DAs Zerfetzt ja ja quasi AMD mit falschen Anschuldigungen und teilweise kontroversen Vergleichen. Was mitunter Befangenheit und Unobjektivität bedeutet.


Gipsel ich finde auch dass du ein wenig zu unkritisch bist was die Tesselationsgeschichte angeht.

Da muss man AMD schon ganz genau auf die Finger schauen. Das hat viel zu viel Potential für unbemerktes Bescheißen.

Und es ist ja nicht so, als hätte man das in der Vergangeheit nie getan.

Unkritisch? Nunja, ich finde er ist äußérst kritisch. Er lässt sich nur nicht zu Meinungsmache und Übertreibung hinreißen.
Zusätzlich hat er auch keinen Verfolgungswahn wie LovsucksZ.

Dann hätten sie bemerkt, dass die 2 Schalter momentan keinen Einfluss haben - und das auch nicht erst seit Cat 11.4. Speziell wenn das aufmerksame Golem vorher noch dran rumspielt und sonderbar große Steigerungen erzielt, sollte es irgendwie einleuchten. Lässt sich ganz easy nachprüfen. Mir ist das in Unigine sofort ins Auge gefallen. Ganz lustig wirds erst wenn golem noch große Rückschlüsse draus zieht und sich Gedanken macht. Bisschen naiv von golem.

Genau meine Ansicht und imho auch die korrekte.
AMD hier an den Pranger zu stellen ist unnötig.
Und wer die Verschwörungstheorie auspacken will; gerne, aber dann ohne mich, ich bleib lieber bei den Fakten.

Fakt ist, wenn man den Schalter nicht angerührt hat, stimmen die Werte auch.

Man kann ihn ja anrühren, nur muss man halt auf 64x zurückstellen, anstatt nur Anwendungsgesteuert zu markieren. Mir ist das relativ schnell aufgefallen, nachdem ich ein paar Benchesdurchlaufen hab lassen.
DAs war vorher schon lange bekannt.
Golem.de hat hier einfach unglücklich mit den falschen Settings gebencht. Hoffe dasganze wird von AMD auch schnell wieder gefxit.

Alles nicht so schlimm, nur ein Bug, hier gibts nichts zu sehen, bitte weiter gehen!

Man könnte ja die Threads mit etwas mehr Sachlichkeit würzen und nicht immer die Verschwörungstheorie auspacken.

Screemer
2011-03-10, 10:38:08
wie hieß der treiber noch mal "early preview" oder so?!

deekey777
2011-03-10, 10:47:29
wie hieß der treiber noch mal "early preview" oder so?!
Nein, der Treiber hieß Launchtreiber der HD6990.

DrFreaK666
2011-03-10, 10:52:12
Beta-Treiber zum Launch sind nichts Neues

Gipsel
2011-03-10, 10:52:39
Als early Preview oder so ähnlich wurde nur der Tess-Slider mal bezeichnet.

DrFreaK666
2011-03-10, 10:54:40
Als early Preview oder so ähnlich wurde nur der Tess-Slider mal bezeichnet.

Das war einmal...

AMD Catalyst™ Driver 11.4 early Preview Features:

· Delivers performance enhancements for the AMD Radeon™ HD 6000 Series & Windows 7.
· Includes enhancements to the AMD Catalyst Control Center™
o New task based Display Management controls
§ Simplifies the configuration of displays and display settings
o New Eyefinity setup group
§ Setting up an Eyefinity group has never been easier
o New branding (based on system configuration)
§ AMD based platform – AMD VISION Engine Control Center
§ Discrete AMD GPU with Intel CPU – AMD Catalyst Control Center™
o AMD Catalyst update notification (found within the Information Center)
§ Please note this functionality is not yet enabled, but will be in a future AMD Catalyst release
§ This feature will be used to notify users that new AMD Catalyst software packages are available

· Fixed cases where Dragon Age 2 would hang in DirectX11 on ATI Radeon™ HD 5800 Series products.

Gipsel
2011-03-10, 10:58:15
Das war einmal...
Das schrieb ich ja auch ("wurde mal") ;)

N0Thing
2011-03-10, 12:31:18
Dieser Bug ist schon seit der Einführung dieses Reglers hier aufgefallen.

Einfach mal auf die Anfangsseiten dieses Threads schauen.

Fakt ist, wenn man den Schalter nicht angerührt hat, stimmen die Werte auch.

Ich frage mich gerade, warum AMD diesen Regler überhaupt in öffentlich verfügbare Treiber einbaut, wenn dessen Funktion noch nicht fehlerfrei ist und auch nach Monaten noch keine Profile hinterlegt wurden, was für ein kleines 3 Mann Team in dieser Zeit sicherlich keine große Aufgabe gewesen wäre.
Wenn es nur darum ginge dem Anwender mehr Auswahlmöglichkeiten zu bieten, dann hätte AMD den Regler in der Standardeinstellung auch auf Anwendungsgesteuert setzen können/sollen.

Schaffe89
2011-03-11, 12:59:23
Es geht aber nicht nur darum, sondern darum, dass AMD Die Tess Werte für Grakas mit wenig Tess Leistung clampen will, um den Dau-Nutzer sinvolle Vorteile zu verschaffen.
Eventuell haben sie auch Probleme mit dem WHQL Siegal oder beschäftigen sich derzeit mit anderen evtl. wichtigeren Dingen.

N0Thing
2011-03-11, 14:53:03
@Schaffe89:

Wenn sie keine Zeit dafür haben, warum dann den Schalter überhaupt der Öffentlichkeit präsentieren? Immerhin ändert sich gerade für den "Dau-Nutzer" bisher gar nichts.

Sinnvoll wäre es doch auch aus der Sicht von AMD gewesen, wenn sie den Schalter zusammen mit Profilen für alle Spiele, die Tesselation bieten, angepaßt an die jeweiligen AMD Grafikkarten, eingeführt hätten. Wenn sie den Schalter in der Standardeinstellung auf Anwendungsgesteuert eingestellt hätten, sollte es dann auch kein Problem mit dem WHQL-Siegel geben und die Anwender könnten beim Download, der Installation und/oder im Control Center auf die optionale Funktion aufmerksam gemacht werden. Die Medien und Foren erledigen dann den Rest.

=Floi=
2011-03-11, 15:29:48
AMD und profile... :rolleyes:


die ganze sache ist viel zu fragil und wird sicherlich auch sehr undurchsichtig werden.
1. sollte man von haus aus den TESS level in ruhe lassen. (das gilt auch für nv!)
2. verändert es teilweise viel zu stark das game und damit den content.

aspella
2011-03-11, 16:49:34
Wenn sie keine Zeit dafür haben, warum dann den Schalter überhaupt der Öffentlichkeit präsentieren? Immerhin ändert sich gerade für den "Dau-Nutzer" bisher gar nichts.

Sinnvoll wäre es doch auch aus der Sicht von AMD gewesen, wenn sie den Schalter zusammen mit Profilen für alle Spiele, die Tesselation bieten, angepaßt an die jeweiligen AMD Grafikkarten, eingeführt hätten. Wenn sie den Schalter in der Standardeinstellung auf Anwendungsgesteuert eingestellt hätten, sollte es dann auch kein Problem mit dem WHQL-Siegel geben und die Anwender könnten beim Download, der Installation und/oder im Control Center auf die optionale Funktion aufmerksam gemacht werden. Die Medien und Foren erledigen dann den Rest.

Profile ?

Gibt es doch schon längst. RADEONPRO !
Es funktiort bei mir in allen spielen und ist beispielweise deutlich umfangreicher und praktischer als der Nhancer.


http://www.bilder-upload.eu/thumb/6989a3-1299858468.jpg (http://www.bilder-upload.eu/show.php?file=6989a3-1299858468.jpg)

http://www.bilder-upload.eu/thumb/432b56-1299858659.jpg (http://www.bilder-upload.eu/show.php?file=432b56-1299858659.jpg)

http://www.bilder-upload.eu/thumb/7b11f1-1299858691.jpg (http://www.bilder-upload.eu/show.php?file=7b11f1-1299858691.jpg)

http://www.bilder-upload.eu/thumb/52e36a-1299858726.jpg (http://www.bilder-upload.eu/show.php?file=52e36a-1299858726.jpg)

http://www.bilder-upload.eu/thumb/bbd328-1299858755.jpg (http://www.bilder-upload.eu/show.php?file=bbd328-1299858755.jpg)

http://www.bilder-upload.eu/thumb/646240-1299858779.jpg (http://www.bilder-upload.eu/show.php?file=646240-1299858779.jpg)


Tesselationslevel kannst du bestimmen, V-Sync erzwingen, Kerne abschalten, frames anzeigen usw usw usw.

boxleitnerb
2011-03-11, 16:57:19
aspella, ich glaub du verwechselst da was.
Es geht nicht um Profile allgemein, sondern um das, was der Tess-Schalter macht. Aber wie ich schon mehrmals geschrieben habe, ist eine an Grafikkarten und Spiele angepasste Einstellung diesbezüglich Unsinn.

AMD Optimized ist nur was für den SuperDAU, der sowieso nicht merkt, ob er mit 30 oder mit 60fps spielt und den es überhaupt nicht juckt, wie das Bild aussieht. Für den Rest der Menschheit macht diese empfohlene Voreinstellung überhaupt keinen Sinn. Es hängt nämlich von der Hardware, von den Ansprüchen an die Flüssigkeit des Spielerlebnisses, von der übrigen Grafiklast (AA, Auflösung, AF, Details) und natürlich von der Tessellationlast im jeweiligen Spiel selbst ab, was da empfehlenswert ist und was nicht.

Das sind viel zu viele Variablen, die AMD alle nicht kennt und trotzdem meint, aufs Geratewohl irgendwas einstellen zu müssen.

Wie Floi sagte:
Tess in Ruhe lassen, Nutzer machen lassen. Den Schalter so wie AA und AF behandeln und alles ist gut.

aspella
2011-03-11, 17:07:38
Ich finde die Tesselationssteuerung äusserst praktisch.
In Metro2033 beispielweise veliere ich kaum optik wenn ich von anwendungsgestuert auf 8X gehe.
Grafisch muss man überhaupt keine einbussen eingehen und hat dabei deutlich mehr frames.

Also wo liegt das problem ?

Schlammsau
2011-03-11, 17:29:25
@boxleitnerb

glaub mir, 90% der Gamer sind so genannte Super-Dau´s! Wahrscheinlich haben die allermeisten von denen ein Controlcenter noch nie ausgeführt.

Ich kenne unzählige Casual-Gamer die gar nicht wissen was AA oder AF ist. Es zählt nur eines....möglichst hohe FPS zu haben.

aspella
2011-03-11, 17:30:46
Ist doch super das AMD dem endverbraucher die Wahl überlässt mit den Tesselationsreglern.
Bei nvidia muss man wählen, alles oder nichts.

Abgeschaltet vermisst man die optik und eingeschaltet die performance, na super.

Schrotti
2011-03-11, 17:31:15
Grafisch muss man überhaupt keine einbussen eingehen und hat dabei deutlich mehr frames.

Also wo liegt das problem ?

Was man nicht kennt das kann man nicht vermissen oder wie?

Woher willst du wissen das du nichts verpasst wenn du nicht weißt wie es ausschauen könnte?

Schlammsau
2011-03-11, 17:34:33
Das ist Blödsinn....es ist ein Regler da, und wenn man wirklich die volle "Tess-Pracht" haben will (meine Screenshots beweisen ja überdeutlich, dass sogar eine Halbierung des Tess-Levels, bisher kaum sichtbare einbussen in der IQ-Quali bringen), stellt man es einfach ein.

aspella
2011-03-11, 17:34:51
Was man nicht kennt das kann man nicht vermissen oder wie?

Woher willst du wissen das du nichts verpasst wenn du nicht weißt wie es ausschauen könnte?

Durch vergleiche bei sich daheim vielleicht ?

LovesuckZ
2011-03-11, 17:40:22
Ist doch super das AMD dem endverbraucher die Wahl überlässt mit den Tesselationsreglern.
Bei nvidia muss man wählen, alles oder nichts.

Abgeschaltet vermisst man die optik und eingeschaltet die performance, na super.

Und bei nVidia bekommt man bei selber Leistung die volle BQ. Das heißt, man kauft für den selben Preis nVidia anstatt AMD.

aspella
2011-03-11, 17:44:38
Aber klar doch:

http://beta.pcper.com/reviews/graphics-cards/amd-radeon-hd-6970-and-6950-review-cayman-architecture-revealed/metro-2033

Die einzigen die was gegen den regler haben und sich beklagen sind leute die in vermissen sprich die grünnen.

Also ich habe lieber 40 min als 25 in Metro2033 bei gleich bleibender optik

LovesuckZ
2011-03-11, 17:47:06
Aber klar doch:

http://www.techspot.com/review/348-amd-radeon-6970/page10.html

Die einzigen die was gegen den regler haben sind die die in vermissen.

Und? Sinn? Inhalt? Also - wenn du hier gipseln willst, lass es einfach.
In Metro2033 kostet advanced DoF deutlich mehr Leistung als Tessellation. Komisch nur, dass es dafür nur einen an/aus Schalter gibt. :freak:

aspella
2011-03-11, 17:52:13
Aber sicher doch deswegen schalten es tester auch ab mit folgender begründung

http://www.techspot.com/review/348-amd-radeon-6970/page10.html
The game was tested with DirectX 11, but Tessellation was left disabled as it hammered performance too severely. Anti-aliasing was also disabled and instead we used the default analytical anti-aliasing with 16xAF.


pcper.com hat mit tesselation getestet.
Ich würde mich mit 25FPS nicht begnügen wollen, aber bei NVIDIA hast du keine wahl entweder 25FPS oder deutliche abstriche in der optik.

Tesselation ON, DOF OFF
http://beta.pcper.com/reviews/graphics-cards/amd-radeon-hd-6970-and-6950-review-cayman-architecture-revealed/metro-2033

LovesuckZ
2011-03-11, 18:00:13
Aber sicher doch deswegen schalten es tester auch ab mit folgender begründung

http://www.techspot.com/review/348-amd-radeon-6970/page10.html



pcper.com hat mit tesselation getestet, wenn du spass an 25frames hast na dann gutte nacht.

Meinst du dieses pcper.com (http://www.pcper.com/article.php?aid=1089&type=expert&pid=4)?
Wohl nicht, oder? :freak:

aspella
2011-03-11, 18:04:05
Wechsel nicht das thema und bleibe schön bei den single-gpu karten.

http://beta.pcper.com/reviews/graphics-cards/amd-radeon-hd-6970-and-6950-review-cayman-architecture-revealed/metro-2033

http://www.computerbase.de/artikel/grafikkarten/2011/test-radeon-hd-6900-cf-vs.-geforce-gtx-500-sli/16/

Tess: On , DOF : Off

durschnittsframerate, wie die min ausschauen wird kannst du dir doch sicherlich denken ? Obwohl bei dir bin ich mir nicht so sicher.

Anderes nennenswertes Spiel das auf tesselation setzt:
http://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/16815-test-amd-radeon-hd-6970-und-6950.html?start=25

Fanboy sein schön und gut aber man sollte den bezug zur realität nicht verlieren nicht wahr Lovesuckz.

Bye

Es gibt einen Editbutton. Solch exzessive Mehrfachpostings bitte vermeiden.

Gipsel
2011-03-11, 18:19:42
wenn du hier gipseln willst, lass es einfach.

Wenn Du hier rumstänkern willst, laß es einfach!

san.salvador
2011-03-11, 18:22:11
Wechsel nicht das thema und bleibe schön bei den single-gpu karten.

http://beta.pcper.com/reviews/graphics-cards/amd-radeon-hd-6970-and-6950-review-cayman-architecture-revealed/metro-2033
http://www.computerbase.de/artikel/grafikkarten/2011/test-radeon-hd-6900-cf-vs.-geforce-gtx-500-sli/16/

Tess: On , DOF : Off

durschnittsframerate, wie die min ausschauen wird kannst du dir doch sicherlich denken ? Obwohl bei dir bin ich mir nicht so sicher.
Anderes nennenswertes Spiel das auf tesselation setzt:
http://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/16815-test-amd-radeon-hd-6970-und-6950.html?start=25

Fanboy sein schön und gut aber man sollte den bezug zur realität nicht verlieren nicht wahr Lovesuckz.

Bye
Man kann hier mehrere Quotes zusammenfassen und Beiträge auch editieren. Tu das.

LovesuckZ
2011-03-11, 18:23:24
Wechsel nicht das thema und bleibe schön bei den single-gpu karten.

http://beta.pcper.com/reviews/graphics-cards/amd-radeon-hd-6970-and-6950-review-cayman-architecture-revealed/metro-2033

Bist du blind? Denkst du wirklich, dass du so toll bist, dass dein Trollen nicht auffällt? Auch hier wurde Metro2033 mit Normal und Tessellation sowie mit einer GTX580 getestet. :rolleyes:

http://www.computerbase.de/artikel/grafikkarten/2011/test-radeon-hd-6900-cf-vs.-geforce-gtx-500-sli/16/

Tess: On , DOF : Off

durschnittsframerate, wie die min ausschauen wird kannst du dir doch sicherlich denken ? Obwohl bei dir bin ich mir nicht so sicher.

Denkst du, wenn du 5% mehr durch das Optimieren von Tess erhälst, dass es dann spielbar wäre? ;D

Hier mal der Start (Prolog, Treppe hochsteigen) von Metro2033 auf einer GTX580 mit High, aDoF und m/o Tessellation

2011-03-11 18:18:48 - Metro2033
Frames: 1031 - Time: 30137ms - Avg: 34.210 - Min: 31 - Max: 38

2011-03-11 18:20:14 - Metro2033
Frames: 1055 - Time: 29781ms - Avg: 35.425 - Min: 32 - Max: 39

Wow, ganze 1,2 FPS, die das deaktivieren von Tessellation in diesen 30 Sekunden bringt.

aspella
2011-03-11, 18:30:43
Bist du blind? Denkst du wirklich, dass du so toll bist, dass dein Trollen nicht auffällt? Auch hier wurde Metro2033 mit Normal und Tessellation sowie mit einer GTX580 getestet. :rolleyes:



Denkst du, wenn du 5% mehr durch das Optimieren von Tess erhälst, dass es dann spielbar wäre? ;D

Hier mal der Start (Prolog, Treppe hochsteigen) von Metro2033 auf einer GTX580 mit High, aDoF und m/o Tessellation

2011-03-11 18:18:48 - Metro2033
Frames: 1031 - Time: 30137ms - Avg: 34.210 - Min: 31 - Max: 38

2011-03-11 18:20:14 - Metro2033
Frames: 1055 - Time: 29781ms - Avg: 35.425 - Min: 32 - Max: 39

Wow, ganze 1,2 FPS, die das deaktivieren von Tessellation in diesen 30 Sekunden bringt.
Wo ist der link, zudem besteht das spiel nicht aus einer szene ;D

5% mehr , lol.
Auch wenn du es nicht hören willst hab je nach level locker bis zu 20FPS mehr dank dem sagenhaften Tesselationsregler. :smile:


Gängigste Auflösung, grünne konkurrenzkarte bricht wie in Stalker Call of Pripyat ein (57-61) Tesselation; ON
http://s7.directupload.net/images/110311/temp/ts5japym.jpg (http://s7.directupload.net/file/d/2460/ts5japym_jpg.htm)

Gipsel
2011-03-11, 19:05:06
Leute, wie oft muß ich noch sagen, daß das hier kein AMD vs. nvidia Benchmarkthread ist?

=Floi=
2011-03-11, 21:14:06
Aber klar doch:

http://beta.pcper.com/reviews/graphics-cards/amd-radeon-hd-6970-and-6950-review-cayman-architecture-revealed/metro-2033

Die einzigen die was gegen den regler haben und sich beklagen sind leute die in vermissen sprich die grünnen.

Also ich habe lieber 40 min als 25 in Metro2033 bei gleich bleibender optik


bitte schreibe: "bei ähnlicher optik" und da kann ich es imho gleich ausschalten. Die fps müssen ja irgenwo herkommen.
ati wird hier sicherlich auch noch nachbessern und dann ist die welt wieder in ordnung. ;)

zukunftige spiele werden auch einen höheren tess level einsetzen und besser mit diesem feature skalieren.


der sinn hinter der kritik ist einfach die möglichkeit bei der tesselation viel cheaten zu können und dem kunden mehr zu suggerieren wie eigentlich da ist! Das ist nunmal fakt und darum geht es in diesem thread vor allem. wenn ich die maximale tesselation will, dann soll sie auch da sein und das könnte in zukunft eben nicht mehr so sein. default sind die kommenden optimierungen (welche man sich wohl noch für die nächste generation aufhebt?!) eingeschaltet und der schalter sollte eigentlich auf anwendungsgesteuert sein. der schalter für den maximalen tess level ist an sich ganzt gut, nur gibt es auch noch die sache mit den profielen und hier beginnt dann das dilemma.
atis idee ist nicht dem kunden mehr möglichkeiten zu geben, sondern einfach um jeden preis längere balken zu haben. das kann auch nicht im sinne eine ati kunden sein.

Schlammsau
2011-03-11, 22:24:49
Wieso hat ein niedriger Tess-Level gleich eine schlechtere IQ zur folge?
Es sieht "anders" aus, aber schlechter?

Kann mir das mal einer erklären?

Für LZ und Konsorten auch nur weil es ein von nVidia gehyptes Feature ist. Würde es von AMD gehypt wär es scheisse/unnötig......

Gipsel
2011-03-11, 22:37:06
Wieso hat ein niedriger Tess-Level gleich eine schlechtere IQ zur folge?
Es sieht "anders" aus, aber schlechter?

Kann mir das mal einer erklären?
Die Frage ist, wie definiert man "gleich" und wie ist die Tessellation in jeweiligen Fall ausgelegt. Du hast Recht damit, daß man Beispiele aufmachen kann, wo eine moderate Verringerung des Tessfaktors keine wesentliche oder gar überhaupt keine Änderung des Bildeindrucks verursacht.

Es ist aber genauso möglich, daß sich der Entwickler gehörig Gedanken gemacht hat und seine Tess-Faktoren genau so ausrechnet, daß er praktisch ziemlich gut am "Knie" der Qualitätskurve sitzt. D.h. eine Erhöhung bringt praktisch kaum Verbesserungen, eine Verringerung aber ziemlich schnell Verschlechterungen. Dies sollten die Entwickler eigentlich anstreben und wird hoffentlich in Zukunft zum Regelfall werden.

Letztendlich kommt es also immer auf den Einzelfall an, die Abstimmung des Contents, um Sagen zu können, ob bzw. wann eine Verringerung der Tessfaktoren um welchen Wert sichtbare Einbußen bringen werden.

PS: Auf den letzten Absatz hättest Du auch verzichten können.

Gipsel
2011-03-12, 00:50:44
In dem Thread gibt's doch eigentlich seit Januar kaum was Neues. Solange nicht klar ist, was die Einstellungen im CP rund um den Tess-Slider und die vielleicht irgendwann mal auftauchenden Profile letztendlich genau machen werden, gibt es doch momentan offenbar nichts mehr zu diskutieren, was nicht schon damals bis zur Erschöpfung durchgekaut wurde.

Edit:
Der Beitrag ist beim Split abhanden gekommen. Habe den mal wieder hergestellt. Peter Gräber scheint unten ja ähnlich zu denken.

Tesseract
2011-03-12, 01:33:05
hier könnt ihr über die BQ weiterdiskutieren:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=504530

ich hoffe mal die splittung der posts macht so halbwegs sinn.

Peter Gräber
2011-03-12, 10:24:05
So wie AMD "diesen Tess-Schalter" der Presse kommuniziert hat, sollte die Option letztlich nur bei Modellen greifen, welche in der 3D-Performance ohnehin begrenzt sind. Die Andeutungen gingen hier klar in Richtung Modelle à la 6600 oder kleiner.

Dass die Vorstellung in Zusammenhang mit dem Beta-Treiber der Caymann-Modelle höchst unglücklich gewählt war, hat die entscheidende Marketing-Abteilung inzwischen vielleicht eingesehen, vielleicht aber auch nicht. Man nehme nur den aktuellen Launch der HD-6990, wo man abermals einen Preview-Treiber präsentierte, in welchem man kommende Treiberneuerungen anpries. Man mag einfach einmal unterstellen, dass die Entscheidungsträger hier möglichst viele "Pluspunkte" für einen Launch gesucht haben, welche man als Besonderheiten des eigenen Produktes herausstellen möchte.

Der "Bug" im Treiber, wenn man an dem Tess-Schalter spielt und dann wieder auf AMD Optimized zurückschaltet, der tauchte schon bei den Tests zur HD 6970/6950 auf und wurde in E-Mails auch kommuniziert. Es wäre sicherlich angebracht gewesen, die Option, solange es noch keine Profile gibt, offline zu nehmen oder zumindest diesen Fehler zu fixen. Auf der anderen Seite muss man klar sagen, dass einige Treiber-/Software-Probleme seit Vorstellung der HD-6000-Serie seitens der Presse an den Hersteller kommuniziert worden sind.

Ich kann mir gut vorstellen, dass man im Entwicklerteam dort aktuell durchaus am rotieren ist, denn neben den Fehlermeldungen auf der To-Do-Liste hat natürlich die Chefetage die Vorstellung der neuen Produkte in den Vordergrund geschoben.

Absicht - wie hier an einigen Ecken angedeutet - würde ich nicht unterstellen wollen. Und was den Tess-Schalter und AMD optimized betrifft, so muss man jetzt wirklich einmal final abwarten, wie das in den Profilen umgesetzt wird. Danach hat man möglicherweise triftige Gründe zur Kritik - vielleicht aber auch nicht.

Ronny145
2011-03-23, 19:37:33
Was Golem schlicht gemacht hat, ist am Tess-Slider rumzuspielen, der eben bekanntermaßen auch schon in vorherigen Treiberversionen verbuggt reagiert. Limitiert man manuell den Tess-Grad und stellt nachher einfach nur wieder auf "AMD optimized" zurück, so wird diese Einstellung nicht übernommen, der Tess-Grad bleibt limitiert.


Der Bug ist jetzt im neuesten 11.4 Preview nicht mehr vorhanden. Wird nur langsam mal Zeit, dass AMD die Profile folgen lässt.

DriverVer=03/21/2011, 8.840.2.0000
http://www2.ati.com/DRIVERS/hotfix/radeon_6990_antilles/amd_catalyst_11.4_preview_win7_march22.exe


Der hier ist noch ein Tag neuer.

http://www2.ati.com/DRIVERS/hotfix/radeon_6990_antilles/amd_catalyst_11.4_preview_win7_march23.exe

Gipsel
2011-03-23, 23:49:54
Wird nur langsam mal Zeit, dass AMD die Profile folgen lässt.Hmm, je nachdem was die Profile dann machen werden, könnte es auch besser sein, sie verschieben das auf den Sankt-Nimmerleins-Tag. :rolleyes:
Aber wie gesagt: mal sehen, was kommt.

Schaffe89
2011-07-07, 05:53:09
Und immernoch keine Profile?

deekey777
2011-07-07, 11:49:04
Danke an mapel110 für den Hinweis!

Auswirkungen des TF-Reglers in Crysis 2:
http://www.hardware.fr/articles/838-7/influence-tessellation-son-niveau.html

Raff
2011-07-07, 12:38:36
Danke an mapel110 für den Hinweis!

Auswirkungen des TF-Reglers in Crysis 2:
http://www.hardware.fr/articles/838-7/influence-tessellation-son-niveau.html

Das Coolste an dem Artikel ist der ... nennen wir es "Bug" ... Wasser-Tessellation-Layer mitten im Battery Park. :ugly: Die Fps droppen durch "Ultra"-Wasser auf einer HD 6950 um 3 Prozent, obwohl kein Wasser im Bild ist – erst im Wireframe-Modus. Zumindest lese ich das mit meinem nach der 11. Klasse gekickten Schulfranzösisch da heraus.

MfG,
Raff

deekey777
2011-07-07, 13:38:48
Aber zumindest bleibt das Wasser unsichtbar.

Wobei ich das mit dem Bürgersteig auch nicht kapiert habe. Da sind zig winzige Dreiecke, die dann geshadet werden, ohne irgendwelche visuellen Vorteile. Und zu kleine Dreiecke kosten Leistung. Hat man da was vergessen?

Schaffe89
2011-07-07, 14:12:21
Also clampt AMD die Tesselationstufe in Crysis 2 und legt zum ersten mal mittels Profilen Hand an?
Jetzt muss man sich angucken inwiefern das Ergebnis schlecht oder gut ist.
Leider ein französischer Test.
Falls die Optik kaum nicht sinkt und die FPS stark ansteigen, dann hat man da einfach überpaced.

Langenscheiss
2011-07-07, 14:14:18
Aber zumindest bleibt das Wasser unsichtbar.

Wobei ich das mit dem Bürgersteig auch nicht kapiert habe. Da sind zig winzige Dreiecke, die dann geshadet werden, ohne irgendwelche visuellen Vorteile. Und zu kleine Dreiecke kosten Leistung. Hat man da was vergessen?

Naja, aber die Tatsache, dass sie im Wireframe sichtbar sind, sagt doch, dass sie zumindest mal irgendwann von den Tesselationen einheiten berechnet wurden. Ziemlich viel Verschwendung würd ich sagen, genau wie mit dem Bürgersteig.

deekey777
2011-07-07, 14:33:40
Naja, aber die Tatsache, dass sie im Wireframe sichtbar sind, sagt doch, dass sie zumindest mal irgendwann von den Tesselationen einheiten berechnet wurden. Ziemlich viel Verschwendung würd ich sagen, genau wie mit dem Bürgersteig.
Da hast du recht: Es werden neue Dreiecke hinzuberechnet, die dann unsichtbar bleiben. Das ist Verschwendung, wobei Nvidia noch das Beste daraus machen kann (aufgrund der Architektur).

Was AMD machen kann? Am Besten gar nichts, sondern Crytek liefert einen weiteren Patch.

Raff
2011-07-07, 14:40:08
Wo sind die Verschwörungstheoretiker, die Crytek und Nvidia vorwerfen, absichtlich Leistung zu verblasen, um speziell Radeon-Karten stallen zu lassen? Ich wundere mich schon. ;)

Dass AMD nun per Profil clampt, habe ich indes nicht aus dem Französisch gefischt – ihr schon?

MfG,
Raff

Screemer
2011-07-07, 14:46:07
AMD user sind doch keine whiner ;-)

deekey777
2011-07-07, 14:47:32
Wo sind die Verschwörungstheoretiker, die Crytek und Nvidia vorwerfen, absichtlich Leistung zu verblasen, um speziell Radeon-Karten stallen zu lassen? Ich wundere mich schon. ;)

Dass AMD nun per Profil clampt, habe ich indes nicht aus dem Französisch gefischt – ihr schon?

MfG,
Raff
didlo4u hat gleich nach der Veröffentlichung des Patches geschrieben, dass das LOD bei der Tessellation auf Radeons nicht funktioniert. Sprich, es soll weiter teselliert werden als bei Nvidia.
Ob das wirklich stimmt, weiß ich nicht.

Es ist schon seltsam, dass Crytek so viel Mist baut und dieser Mist gerade die Radeons härter trifft als Geforces.
Es ist schon etwas anders als Monster mit tessellierten Hörnen vollzuscheißen, damit man bessere Performance liefert (LP2), aber irgendwie ist es das gleiche, was Crytek jetzt gemacht hat, zumindest beim Bürgersteig.

mapel110
2011-07-07, 17:00:32
didlo4u hat gleich nach der Veröffentlichung des Patches geschrieben, dass das LOD bei der Tessellation auf Radeons nicht funktioniert. Sprich, es soll weiter teselliert werden als bei Nvidia.
Ob das wirklich stimmt, weiß ich nicht.

Nach Screenshots, die ich gesehen habe, stimmt das. ATI tesselliert mehr. Naja, wird sicher noch 2-3 Patches geben für das Spiel.

Shaft
2011-07-07, 18:11:49
Das Coolste an dem Artikel ist der ... nennen wir es "Bug" ... Wasser-Tessellation-Layer mitten im Battery Park. :ugly: Die Fps droppen durch "Ultra"-Wasser auf einer HD 6950 um 3 Prozent, obwohl kein Wasser im Bild ist – erst im Wireframe-Modus. Zumindest lese ich das mit meinem nach der 11. Klasse gekickten Schulfranzösisch da heraus.

MfG,
Raff


Da ich Französisch nicht mächtig bin, muss ich mich auf Google Translation verlassen und bestätigt dies.

Abgesehen vom Optimierungsbedarf, ist das schon ein grober Bug, da wird Leistung verschwendet.

Würd sagen kommt davon, wenn man DX11 mal so nach schmeißt.

deekey777
2011-07-07, 19:24:29
Es heißt, dass in einem Cry-Level, wo es Wasser gibt, überall Wasser sein muss.
Ergibt aber wenig Sinn, denn der Meeresspiegel ist deutlich niedriger, wenn man vom Wasser aus dem Hafen ausgeht.

Coda
2011-07-07, 19:30:18
Nach Screenshots, die ich gesehen habe, stimmt das. ATI tesselliert mehr. Naja, wird sicher noch 2-3 Patches geben für das Spiel.
Das ist recht sicher kein Fehler des Spiels. Außer es gibt ATI-GPUs absichtlich einen anderen Hull-Shader. Das wäre schon harter Tobak.

Es heißt, dass in einem Cry-Level, wo es Wasser gibt, überall Wasser sein muss.
Ergibt aber wenig Sinn, denn der Meeresspiegel ist deutlich niedriger, wenn man vom Wasser aus dem Hafen ausgeht.
Wie meinen? Das Ozean-Wasser hat tatsächlich im ganzen Level die selbe Höhe.

Das Wasser als Last-Pass zu rendern ohne Software-Culling ist ein Resultat des Algorithmus den Crytek da seit Crysis 2 verwendet und war ohne Tesselation auch kein Problem, weil die GPU das unsichtbare Wasser sehr sehr sehr schnell verwerfen kann. Ein Problem wird das erst durch Tesselation, weil da weit mehr Arbeit in den Pre-Pixel-Shader-Stages auftritt, die nicht von der GPU verworfen werden kann.

deekey777
2011-07-08, 10:16:32
Das ist recht sicher kein Fehler des Spiels. Außer es gibt ATI-GPUs absichtlich einen anderen Hull-Shader. Das wäre schon harter Tobak.
Nee, ATi betreibt Shaderreplacement, um Crysis 2 niederzumachen. X-D


Wie meinen? Das Ozean-Wasser hat tatsächlich im ganzen Level die selbe Höhe.

Genau so meinen: Warum wird Wasser dort tesselliert, obwohl der Meeresspiegel viel niedriger ist (vom Gefühl her ist das Lager mindestens 1 m über dem Meeresspiegel).
Es könnte aber auch Fehler von GPUPerf sein.

Das Wasser als Last-Pass zu rendern ohne Software-Culling ist ein Resultat des Algorithmus den Crytek da seit Crysis 2 verwendet und war ohne Tesselation auch kein Problem, weil die GPU das unsichtbare Wasser sehr sehr sehr schnell verwerfen kann. Ein Problem wird das erst durch Tesselation, weil da weit mehr Arbeit in den Pre-Pixel-Shader-Stages auftritt, die nicht von der GPU verworfen werden kann.
Das heißt: Da Manhatten eine Insel ist (ja-ja), sind die meisten Level vom Wasser umgeben und das Wasser (dessen Dreiecke) wird - wenn man auf Ultra geht - nicht verworfen?

Aber zumindest bleibt das Wasser unsichtbar.

Wobei ich das mit dem Bürgersteig auch nicht kapiert habe. Da sind zig winzige Dreiecke, die dann geshadet werden, ohne irgendwelche visuellen Vorteile. Und zu kleine Dreiecke kosten Leistung. Hat man da was vergessen?
Korrektur:
Auf den Bildern mit bzw. ohne POM ist schon zu sehen, dass der Bordstein runder wird, wenn man auf Ultra geht.
Vielleicht hat sich ein CCC-Bug eingeschlichen und ließ TF auf zB 1, aber GPUPerf sieht den Bordstein dennoch als tesselliertes Objekt an.

Coda
2011-07-08, 10:28:34
Genau so meinen: Warum wird Wasser dort tesselliert, obwohl der Meeresspiegel viel niedriger ist (vom Gefühl her ist das Lager mindestens 1 m über dem Meeresspiegel).
Es könnte aber auch Fehler von GPUPerf sein.
Wieso sollte es nicht tesseliert werden?

Das heißt: Da Manhatten eine Insel ist (ja-ja), sind die meisten Level vom Wasser umgeben und das Wasser (dessen Dreiecke) wird - wenn man auf Ultra geht - nicht verworfen?
Das Wasser wird immer an die GPU gesendet zum rendern, egal welche Einstellung. Nicht sichtbare Dreiecke können von der GPU sehr schnell verworfen werden - Die Arbeit vor den Pixel-Shadern, wozu auch Hull/Tesselation/Domain gehört eben aber nicht, und die ist auf Ultra eben nicht unerheblich.

Ich verstehe echt nicht, was daran jetzt so schwer zu kapieren ist.

deekey777
2011-07-08, 10:35:30
Wieso sollte es nicht tesseliert werden?
Weil der Meeresspiegel in diesem Level mindestens 5 m niedriger ist. Aus welchem Grund ist dort pinkes Wasser direkt vor der Nase von Al zu sehen?
Hier nochmal der Link:
http://www.hardware.fr/articles/838-6/tessellation-loupe.html
Das allerletzte Bild.

Das Wasser wird immer an die GPU gesendet zum rendern, egal welche Einstellung. Nicht sichtbare Dreiecke können von der GPU sehr schnell verworfen werden - Die Arbeit vor den Pixel-Shadern, wozu auch Hull/Tesselation/Domain gehört eben aber nicht, und die ist auf Ultra eben nicht unerheblich.

Ich verstehe echt nicht, was daran jetzt so schwer zu kapieren ist.
Ich wollte nur sicher gehen.

Coda
2011-07-08, 10:37:48
Weil der Meeresspiegel in diesem Level mindestens 5 m niedriger ist. Aus welchem Grund ist dort pinkes Wasser direkt vor der Nase von Al zu sehen?
Weil's in dem Level eine Küste mit Wasser gibt. Ich verstehe die Frage nicht.

Die GPU kann nicht bevor sie tesseliert hat feststellen, das die Dreiecke nicht sichtbar sind, deshalb muss sie es immer tun. Im Wireframe ist das dann halt auch logischerweise sichtbar.

deekey777
2011-07-08, 10:41:23
Weil's in dem Level eine Küste mit Wasser gibt. Ich verstehe die Frage nicht.

Die GPU kann nicht bevor sie tesseliert hat feststellen, das die Dreiecke nicht sichtbar sind, deshalb muss sie es immer tun. Im Wireframe ist das dann halt auch logischerweise sichtbar.
Du kennst den Level nicht, oder?

Coda
2011-07-08, 10:42:18
Doch tue ich.

Schaffe89
2011-07-09, 12:05:10
Dass AMD nun per Profil clampt, habe ich indes nicht aus dem Französisch gefischt – ihr schon?



Nein, es wäre aber ratsam dies bei diesem sinnlosen Mehraufwand zu tun.
Aber vielleicht kommt ja noch ein Patch nach.

boxleitnerb
2011-07-09, 12:07:19
Nur hoffentlich nicht per default, das ergibt wieder einen sehr fragwürdigen Präzedenzfall.

Ronny145
2011-07-09, 12:30:09
Mit den Profilen hat AMD vielleicht wieder verworfen. Es ist jetzt schon ein halbes Jahr vergangen, da wäre es sicherlich problemlos möglich gewesen in den paar existierenden Spielen mit Tessellation ein Profil zu basteln. Solange AMD keine Stellung dazu nimmt, könnte es natürlich jederzeit noch passieren.

Coda
2011-07-10, 11:10:54
Anscheinend müssen sie ja erstmal den Bug fixen, der dafür sorgt, das der Hull-Shader immer maximalen Tesselationsgrad bestimmt.

Danach können wir weiterreden.

Raff
2011-07-10, 11:17:41
Das Wasser wird immer an die GPU gesendet zum rendern, egal welche Einstellung. Nicht sichtbare Dreiecke können von der GPU sehr schnell verworfen werden - Die Arbeit vor den Pixel-Shadern, wozu auch Hull/Tesselation/Domain gehört eben aber nicht, und die ist auf Ultra eben nicht unerheblich.

Nun, die Franzosen haben einen Fps-Drop von drei Prozent auf Cayman Pro gemessen. Eine GeForce wird dann wohl auch 1-2 Prozent verlieren. Das ist definitiv Verschwendung, aber in diesem Fall verschmerzbar.

MfG,
Raff

deekey777
2011-07-24, 12:01:34
Doch tue ich.
http://www.abload.de/thumb/crysis22011-07-2411-45x76u.jpg (http://www.abload.de/image.php?img=crysis22011-07-2411-45x76u.jpg)
Unter mit sind die alten Kanonen.

Man achte auf die schön gefilterten Texturen.

Coda
2011-07-24, 21:59:03
Ich versteh immer noch nicht, was du mir sagen willst :)

deekey777
2011-07-24, 22:00:50
Ich versteh immer noch nicht, was du mir sagen willst :)
Dass das pinke Mesh (richtiger Begriff?) den Eindruck erweckt, dass es noch eine Schicht Ozeanwasser ist.

Coda
2011-07-25, 11:09:11
Sorry, immer noch nicht. Was für eine "Schicht"? Ich sagte doch bereits, dass das Wasser immer gerendert wird.

deekey777
2011-08-17, 13:19:49
Sorry, immer noch nicht. Was für eine "Schicht"? Ich sagte doch bereits, dass das Wasser immer gerendert wird.
Hier sieht man, was ich meine: http://techreport.com/articles.x/21404/3
Aber so lange das nur einmal gerendert wird, ist es egal und damit wäre eine weitere Diskussion nicht nötig. :)

So oder so:
http://techreport.com/articles.x/21404/1
Bis auf die Sache mit dem Wasser (das ist nunmal so) ist Cryteks Leistung sehr fragwürdig. Der Artikel zeigt mehrere Beispiele, wo man sich fragt, welchen Zweck die Tessellation in Crysis 2 hat.
Radeon owners do have some recourse, thanks to the slider in newer Catalyst drivers that allows the user to cap the tessellation factor used by games. Damien advises users to choose a limit of 16 or 32, well below the peak of 64.

LovesuckZ
2011-08-17, 13:26:49
Der Zweck von Tessellation ist es Eingangsdreiecke zu zerlegen. Ich glaube, diesen Zweck erfüllt Tessellation in Crysis 2.

Und da die nVidia-Karten weniger als 20% verlieren - lol, dass ist 1/3 vom SSAO-Leistungseinbruch in Dragon Age 2 - ist es sehr effizient, jedenfalls effizienter als sonstiger Quatsch, dem man per Recheneinheiten umsetzen kann bzw. will.

Wenn man sich aber nun Hardware kauft, dessen Geometrieleistung auf dem Niveau von Low-End liegt, dann verliert man natürlich auch deutlich mehr Leistung. Aber psst, das wäre ja Logik.

/edit: Die Dreiecke sind deutlich größer als ein Pixel. Demnach kommt es auch zu keiner Limitierung durch das Rasterizing und Oversampling. Also existiert hier doch überhaupt kein Problem.

Mr. Lolman
2011-08-17, 13:43:12
Lies dir mal besser den Artikel durch. Tessellation ist durchaus sinnvoll und praktisch, aber das was Crytek da betreibt, entbehrt tw. jeglicher Logik...

Wobei:

They found a way to flex all that unused Fermi muscle! On things you can't see!

LovesuckZ
2011-08-17, 13:50:50
Lies dir mal besser den Artikel durch. Tessellation ist durchaus sinnvoll und praktisch, aber das was Crytek da betreibt, entbehrt tw. jeglicher Logik...

Habe ich.
Verstehe das Heulen jedoch nicht. Ineffiziente Anwendung von Technik ist gang und gebe in dieser Branche. War es und wird es immer sein.
AMD's Geometrieleistung beim Einsatz von Tessellation ist so dermaßen gering, dass jegliches Anwenden sie immer mehr schadet als es bei nVidia der Fall sein wird. Du kannst nicht erwarten, dass Programmierer deutlich mehr Zeit für Optimierungen investieren, die sowieso nur temporäre Auswirkung haben wird. Sobald AMD mit der nächsten Generation erscheint, wird sich das Problem von alleine lösen.

Im Gegensatz zu der SSAO Implementierung in Dragon Age 2. Der Leistungsverlust für einen kleinen pillepalle Schatten unter dem Fuß wird auch bei zukünftiger Hardware um die 50-60% betragen. Aber das ist anscheinend kein Artikel wert. :freak:

/edit: Soweit ich das mitbekommen habe, hat Crytek eine Vielzahl der Modelle "Tessellation-fähig" gemacht. Es fehlt doch nur die entsprechenden Höhen/Tiefen-Informationen für die Modelle. Die waren einfach nur faul, nachdem Austausch durch das Spiel zu gehen und die Modelle, die eben nicht tesselliert werden müssten, wie auszutauschen. Kann man verstehen, den Aufwand würde niemand machen, der ein kostenloses Update anbietet.

Mr. Lolman
2011-08-17, 13:58:21
Ineffizientes Anwenden ist eine Sache. Die andere ist unnuetze Verschwendung Polygonen die überhauptnichts zur Optik beitragen (nicht mal pillepalle). Und das hinterlässt angesichts der intensiven Zusammenarbeit zw. NV und Crytek und dem Tessellationsmonster Fermi einen schalen Beigeschmack...

edit: Die Dreiecke sind deutlich größer als ein Pixel. Demnach kommt es auch zu keiner Limitierung durch das Rasterizing und Oversampling. Also existiert hier doch überhaupt kein Problem.

Die Dreiecke sind mit Tessellation wohl eher kleiner als 1 Pixel. Schliesslich kommts ja schon auch drauf an wie die Objekte im Screenspace projeziert werden.

Edit: Du findest es also verständlich, dass man ein Feature anbietet, was zT bloss den Sinn hat Leistung zu vernichten? Hätte man halt nur die Objekte bearbeitet die tatsächlich auch von Tessellation profitiert hätten...

LovesuckZ
2011-08-17, 14:18:56
Ineffizientes Anwenden ist eine Sache. Die andere ist unnuetze Verschwendung Polygonen die überhauptnichts zur Optik beitragen (nicht mal pillepalle). Und das hinterlässt angesichts der intensiven Zusammenarbeit zw. NV und Crytek und dem Tessellationsmonster Fermi einen schalen Beigeschmack...

Na, der fade Beigeschmack kommt, weil du nVidia nicht magst. Wenn AMD so etwas machen würde - siehe auch Dragon Age 2 - dann hört man nichts.
Ich habe vor solchen Praktiken gewarnt. Aber manche wollen eben nicht hören.

Dazu kommt, dass der Einsatz von Tessellation durch die API gerechtfertigt ist. Es steht jeder Firma frei ihre Hardware an die Erfordernisse anzupassen. Du solltest dich also fragen, wieso AMD keine entsprechende Hardware gebaut hat. Wir hatten das Spiel doch schon mit CineFX und FP-Genauigkeit.
Das steht auch im krassen Gegensatz zur Umsetzung von SSAO über Pixelshader, das deutlich ineffizienter als wenn man CS nach DX11 verwenden würde. Gerechtfertigt war es zu Zeiten von DX10.x, aber nicht mehr, nachdem DX11 1 1/2 Jahre auf dem Markt ist und das Spiel DX11 unterstützt.

Und nicht vergessen, es gibt auch Pillepalleunterschiede laut Techreport:

You can see that there's not much visual difference between the two. The biggest change is the little "handles" atop the slabs. In the DX9 version, they're flat and just textures. In DX11, they appear to be real structures protruding from the top of the barrier. I think there may be higher-quality textures in use in DX11, but some of the difference there may be the result of the fact that I haven't duplicated the camera position precisely between the two shots. Whatever the case, the visual improvement when moving from DX9 to DX11 is subtle at best.


Die Dreiecke sind mit Tessellation wohl eher kleiner als 1 Pixel. Schliesslich kommts ja schon auch drauf an wie die Objekte im Screenspace projeziert werden.

Wobei, du hast recht. Mein Fehler.
Wobei das wiederrum die Theorie widerlegt, dass Dreiecke kleiner als 1 Pixel problematisch wären.


Edit: Du findest es also verständlich, dass man ein Feature anbietet, was zT bloss den Sinn hat Leistung zu vernichten? Hätte man halt nur die Objekte bearbeitet die tatsächlich auch von Tessellation profitiert hätten...

Soweit ich das sehe, hat Crytek (edit: fast) alle Modelle soweit fertig gestellt, dass man sie nur noch einbauen muss. Die waren einfach zu faul, dann die überflüssigen zu entfernen. Schau dir das Spiel dochmal an, es gibt z.B. bei 3 umschließenden Mauern meisten immer eine, die nicht tesselliert und mit DM dargestellt wird. Das ganze ist ein Flickwerk - ein kostenloses Update eben.

Cyphermaster
2011-08-17, 14:24:44
Wenn man sich aber nun Hardware kauft, dessen Geometrieleistung auf dem Niveau von Low-End liegt, dann verliert man natürlich auch deutlich mehr Leistung. Aber psst, das wäre ja Logik.Wie logisch ist es, völlig unnötige Poygone überhaupt abarbeiten zu lassen? Unnötige Arbeit bleibt Unnötige Arbeit, egal wie effizient ausgeführt. Effizienz ändert nichts an der grundsätzlichen Unsinnigkeit des Programmierens von höchsttesselierten Objekten, die simple Geometrien besitzen. Genau bei sowas sollte tendenziell ja eigentlich gespart werden, um hohe Poly-Counts für komplexere Geometrien spendieren zu können, wo sich ein sichtbarer Unterschied ergibt.

Der einzige nennenswerte Effekt an dieser Programmierarbeit war/ist, daß eine künstliche Vorteilssituation für genau den Hersteller geschaffen wird, der mit dem Spielehersteller zusammengearbeitet hat. Now you do the math.

/edit: Der letzte Absatz ist mit Absicht firmenneutral formuliert.

LovesuckZ
2011-08-17, 14:44:18
Wie logisch ist es, völlig unnötige Poygone überhaupt abarbeiten zu lassen? Unnötige Arbeit bleibt Unnötige Arbeit, egal wie effizient ausgeführt. Effizienz ändert nichts an der grundsätzlichen Unsinnigkeit des Programmierens von höchsttesselierten Objekten, die simple Geometrien besitzen. Genau bei sowas sollte tendenziell ja eigentlich gespart werden, um hohe Poly-Counts für komplexere Geometrien spendieren zu können, wo sich ein sichtbarer Unterschied ergibt.

Unnötige (nicht sichtbare) Dreiecke werden durch die Hardware weggeworfen und das schon seit Ewigkeiten, einmal im Domain-Shader (oder schon Hull?) und dann beim Rasterizing. Tessellation ist alleinig nur dafür da, eine höhrere Polygonzahl auf effizientere Weise zu erreichen. Dafür muss aber die Hardware gebaut werden.
Ein Wireframe-Modus macht es immer schlimmer als es am Ende ist. Deswegen sollte man sich dadurch nicht in die Irreführen lassen.


Der einzige nennenswerte Effekt an dieser Programmierarbeit war/ist, daß eine künstliche Vorteilssituation für genau den Hersteller geschaffen wird, der mit dem Spielehersteller zusammengearbeitet hat. Now you do the math.

Es gibt keine künstliche Vorteilssituation. Es ist belanglos, ob du mehr siehst oder nicht. Das Problem von AMD ist ein Deignsproblem, dass immer auftritt. Das, was du sagst, ist doch nur: Bitte nicht zu viel. Also der krasse Gegensatz von dem, wozu Tessellation gedacht wurde. ;)

/edit: Und das es ein Designproblem der heutigen AMD-Hardware ist, sieht man doch daran, dass AMD mit der nächsten Generation den selben Weg wie nVidia gehen wird. Und dann ist dieses Thema sowieso gegessen und vorbei.

Cyphermaster
2011-08-17, 15:02:51
Unnötige (nicht sichtbare) Dreiecke werden durch die Hardware weggeworfen und das schon seit Ewigkeiten, einmal im Domain-Shader (oder schon Hull?) und dann beim Rasterizing. Tessellation ist alleinig nur dafür da, eine höhrere Polygonzahl auf effizientere Weise zu erreichen. Dafür muss aber die Hardware gebaut werden.
Ein Wireframe-Modus macht es immer schlimmer als es am Ende ist. Deswegen sollte man sich dadurch nicht in die Irreführen lassen.Wenn man einen schlichten Würfel, der sich mit 12 Dreiecken rendern läßt, per Tesselation bei auf die tausendfache Polygonzahl (bei selbem Endergebnis) aufbläst, dann ist das unnötig, egal ob Wireframe oder anders. Und das auch, wenn jeweils eine gewisse Prozentzahl der Polygone verworfen wird. /edit: Das Designproblem liegt in der Software, nicht in der Hardware, denn auch nV-Designs erreichen durch das Mehr an Polygonen nur eines: verlorene FPS ohne bessere Grafik.
Es gibt keine künstliche Vorteilssituation. Es ist belanglos, ob du mehr siehst oder nicht.Du willst mir also sagen, daß es egal ist, ob ich mit mehr Aufwand auch mehr Grafikqualität bekomme oder nicht, Hauptsache ich habe möglichst alle Transistoren meiner Grafikkarte irgendwie beschäftigt? :ulol:
Das Problem von AMD ist ein Deignsproblem, dass immer auftritt. Das, was du sagst, ist doch nur: Bitte nicht zu viel. Also der krasse Gegensatz von dem, wozu Tessellation gedacht wurde. ;)Ich sage: Tesselation da, wo sie einen Effekt bringt. Und nein, ich glaube nicht, daß Tesselation (oder eine andere Technik) dafür gedacht ist, Leistung für keinen Effekt zu verbraten - wie es in diesem Fall passiert.

Tesseract
2011-08-17, 15:14:14
Wobei das wiederrum die Theorie widerlegt, dass Dreiecke kleiner als 1 Pixel problematisch wären.
nicht "problematisch" sondern schlicht ineffizient. das selbe rechen-budget kann man einfach deutlich sinnvoller investieren.

Unnötige (nicht sichtbare) Dreiecke werden durch die Hardware weggeworfen und das schon seit Ewigkeiten
trotzdem ist es besser so früh wie möglich bzw. so weit oben wie möglich in der hierarchie zu cullen.

LovesuckZ
2011-08-17, 15:14:57
Wenn man einen schlichten Würfel, der sich mit 12 Dreiecken rendern läßt, per Tesselation bei auf die tausendfache Polygonzahl (bei selbem Endergebnis) aufbläst, dann ist das unnötig, egal ob Wireframe oder anders. Und das auch, wenn jeweils eine gewisse Prozentzahl der Polygone verworfen wird.

Es ist nicht dein Recht zu entscheiden, was effzienz oder ineffizient ist. Wenn der Entwickler meint, dass muss so sein, dann wird er es umsetzen.
Du kannst es kritisieren, aber wie sagt man so schön:

Don't hate the player, hate the game.

Beschwere dich also bei denen, die den Entwickler die Möglichkeit geben, solch einen Mist umzusetzen. Die Hardware kann nichts dafür, die macht nur das, was aus einer höheren Schicht kommt.


Du willst mir also sagen, daß es egal ist, ob ich mit mehr Aufwand auch mehr Grafikqualität bekomme oder nicht, Hauptsache ich habe möglichst alle Transistoren meiner Grafikkarte irgendwie beschäftigt? :ulol:
Ich sage: Tesselation da, wo sie einen Effekt bringt. Und nein, ich glaube nicht, daß Tesselation (oder eine andere Technik) dafür gedacht ist, Leistung für keinen Effekt zu verbraten - wie es in diesem Fall passiert.

Du hast nicht verstanden, was das Problem bei AMD ist. Und du hast nicht verstanden, was Tessellation ist.

Cyphermaster
2011-08-17, 15:40:24
Es ist nicht dein Recht zu entscheiden, was effzienz oder ineffizient ist.Natürlich ist das mein Recht. Ich als Kunde entscheide, ob ich für mich eine gewisse Performanceeinbuße für eine bessere Grafik investiere. Ich als Kunde entscheide beim Kauf meiner Grafikkarte, wieviel Geld für welche Performance und welche Features ich bezahle - oder eben auch nicht.
Beschwere dich also bei denen, die den Entwickler die Möglichkeit geben, solch einen Mist umzusetzen. Wer hat wohl die Entwickler angewiesen und dafür bezahlt, daß sie auch bei den Modellen Tesselation vorsehen, bei denen es keinen erkennbaren Vorteil hat - und warum? Oder glaubst du, den Entwicklern war so langweilig, daß sie das unbedingt auch noch machen wollten?
Du hast nicht verstanden, was das Problem bei AMD ist. Wie sagtest du? Die Hardware kann nichts dafür, die macht nur das, was aus einer höheren Schicht kommt.Die Hardware hat mit einer sinnlosen Programmierung nichts zu tun.
Und du hast nicht verstanden, was Tessellation ist.Natürlich nicht. Du bist ja hier der Einzige, der Ahnung von sowas hat... :ulol:

Mr. Lolman
2011-08-17, 15:41:44
Beschwere dich also bei denen, die den Entwickler die Möglichkeit geben, solch einen Mist umzusetzen.

Also bei nVidia? ;)

LovesuckZ
2011-08-17, 15:42:28
Also bei nVidia? ;)

Wohl eher Microsoft, gell? :freak:


Wer hat wohl die Entwickler angewiesen und dafür bezahlt, daß sie auch bei den Modellen Tesselation vorsehen, bei denen es keinen erkennbaren Vorteil hat - und warum? Oder glaubst du, den Entwicklern war so langweilig, daß sie das unbedingt auch noch machen wollten?


Der Vorgang der Tessellierung ist nichts weiter als die Zerlegung eines Eingangsmeshes aus Dreiecken in ein Mesh mit mehr Dreiecken. Da die Modelle - wer errinnert sich nicht an Doom 3? - sowieso meisten als High-Poly-Modelle vorliegen, ist es doch der nächste logische Schritt, dass man diese ungefähr genauso in das Spiel überführt, indem ein relatives Low-Poly-Mesh durch die GPU um Dreiecke bereichert wird.

Tessellation selbst sagt auch nichts über die am Ende vorliegende Leistung aus. Durch weniger Vertex-Berechnungen und ein dynamisches LoD kann es auch deutlich schneller sein als der Weg ohne Tessellation.

Tesseract
2011-08-17, 16:56:21
Beschwere dich also bei denen, die den Entwickler die Möglichkeit geben, solch einen Mist umzusetzen.
klar, wenn schlecht gearbeitet wird ist natürlich das werkzeug schuld. :rolleyes:

LovesuckZ
2011-08-17, 16:59:43
klar, wenn schlecht gearbeitet wird ist natürlich das werkzeug schuld. :rolleyes:

Na, falsches Beispiel.
Die API ist ja nicht das Werkzeug, sondern in dem Fall eher ein Regelbuch.

Tesseract
2011-08-17, 17:03:14
Na, falsches Beispiel.
Die API ist ja nicht das Werkzeug, sondern in dem Fall eher ein Regelbuch.
eine API ist kein regelbuch sondern ein werkzeug um einen darunter liegenden abstraktionslayer ansprechen zu können.
das "regelbuch" ist höchstens die dokumentation zur API.

LovesuckZ
2011-08-17, 17:09:01
eine API ist kein regelbuch sondern ein werkzeug um einen darunter liegenden abstraktionslayer ansprechen zu können.
das "regelbuch" ist höchstens die dokumentation zur API.

Dann nimm die angebotenen Features bzw. Möglichkeiten, die durch die API zur Verfügung gestellt werden. Wenn Unterteilungsfaktoren von 1-64 zur Verfügung stehen, dann kann man nicht den Entwickler kritisieren, dass er diese auch verwendet, aber das Ergebnis nicht dem eigenen Geschmack entspricht.

In diesem Forum wird sich einerseits beschwert, wenn propritäre Schnittstellen verwendet werden (PhysX -> CUDA) gleichzeitig wird sich beschwert, wenn die Möglichkeiten einer offenen Schnittstell ausgenutzt werden. Und das noch von den selben Leuten.

Beschwert euch bei Microsoft und der Khronus Group, dass man den Entwickler zuviel Freiheiten gibt.

Tesseract
2011-08-17, 17:18:21
Dann nimm die angebotenen Features bzw. Möglichkeiten, die durch die API zur Verfügung gestellt werden. Wenn Unterteilungsfaktoren von 1-64 zur Verfügung stehen, dann kann man nicht den Entwickler kritisieren, dass er diese auch verwendet, aber das Ergebnis nicht dem eigenen Geschmack entspricht.
natürlich kann man das. es gibt so viele stufen, damit man adaptiv arbeiten kann. wenn man diese falsch verwendet kann die API nix dafür, dann ist der entwickler einfach unfähig oder unter zeitdruck.

In diesem Forum wird sich einerseits beschwert, wenn propritäre Schnittstellen verwendet werden (PhysX -> CUDA) gleichzeitig wird sich beschwert, wenn die Möglichkeiten einer offenen Schnittstell ausgenutzt werden. Und das noch von den selben Leuten.
was hat die offenheit der dokumentation/implementierung mit den möglichkeiten zu tun? du kannst auch in CUDA absoluten schwachsinn zusammen coden.

LovesuckZ
2011-08-17, 17:26:08
natürlich kann man das. es gibt so viele stufen, damit man adaptiv arbeiten kann. wenn man diese falsch verwendet kann die API nix dafür, dann ist der entwickler einfach unfähig oder unter zeitdruck.
was hat die offenheit der dokumentation/implementierung mit den möglichkeiten zu tun? du kannst auch in CUDA absoluten schwachsinn zusammen coden.

Es geht hier nicht um "absoluten Mux". Die Problematik ist, dass AMD ein Erzeugungssproblem von Dreiecken auf der GPU hat. Dieses Problem lässt sich nicht lösen, nur weil man mehr sieht. Es existiert immer, auch wenn man den selben "Qualitätsgrad" des Standard-<DX11-Modells aus einem Low-Poly-Mesh per Tessellation erzeugt. Die angebotenen Unterteilungsfaktoren sind die Grundlage für diese Threads. Durch die starke Wahlfreiheit kommt es doch erst zu der Offenbarung der Problematik. Wären nur maximal 8 Faktoren erlaubt, wäre das ganze doch vollkommen belanglos, da der Einbruch zwar immer noch stärker, aber der Abstand nicht so groß gegenüber nVidia wäre wie jetzt.

Und da Tessellation eben nicht gleichbedeutend mit mehr und/oder schönerer Optik ist, liegt die Schuld eben bei der Spezifikation von DX11 bzw. OpenGL 4.

boxleitnerb
2011-08-17, 17:38:46
Das hier macht sehr nachdenklich:

http://techreport.com/articles.x/21404/1

Wenn man sich anschaut, was für ein Quatsch da tesselliert und wieviel Performance verschwendet wird, ist AMDs Schalter nicht grundsätzlich verkehrt. Tessellation gehört adaptiv angewendet, davon sieht man in den anaylsierten Szenen meistens nix. Das Level stupide zu beschränken halte ich für doof, lieber einen Faktor einbauen, das bringt dann meistens auch mehr Performance (wenn nicht alles tottesselliert wird wie in Crysis 2):

As for the slider… as I said, clamping alone isn’t that good. It would have been much better if they would scale down the tessellation factors as well. That way you reduce tessellation everywhere in the scene, rather than just limiting the few parts that use high tessellation factors (although AMD wanted us to believe otherwise, pretty much all games use an adaptive tessellation scheme, so they don’t just throw large tessellation factors around. Limiting only the large factors doesn’t do all that much for performance… benchmarks such as Unigine Heaven may go over 8x every now and then, but it is so sporadic, that limiting to 8x gives virtually no performance increase. It’s almost as if AMD doesn’t understand their own performance problem). It would be a much better way to control detail over the scene. It would also be better in terms of performance. Currently the limiter is pretty useless unless you set it EXTREMELY tight (as you say, 2x to 4x on most, 6x on their best offerings)… A scaling factor would reduce tessellation over the entire scene, giving performance increases everywhere, not just the clamped areas.

Quelle:
http://scalibq.wordpress.com/2011/01/19/catalyst-hotfix-11-1a-amd-admits-defeat-in-tessellation/

Cyphermaster
2011-08-17, 18:04:19
Tesselation so zu nutzen, daß -wie in diesem Fall- weder eine bessere Optik, noch gleiche oder bessere Performance resultieren (Karten BEIDER Hersteller verlieren Performance), ist und bleibt nun mal unlogisch. Es mag möglich und erlaubt sein, aber kein sauber arbeitender Programmierer wird sich absichtlich freiwillig reines Transistoren-ABM antun. Schon gar nicht mit extra Aufwand.
Daß ein Fermi mit so einer Über-Anwendung besser zurecht kommt als die AMD-Pendants, da kann man sicher beipflichten. Zu behaupten, daß nVidia absichtlich Reserven für zukünftige, noch stärkere Tesselations-Nutzung einkalkuliert hätte, wäre schon spekulativ. Aber einen echten Architekturnachteil der AMD-Designs daraus stilisieren zu wollen, daß die nVidia-Chips mit unsinnigen Implementationen von Tesselierung besser zurecht kommen, ist schon abenteuerlich. Das ist, als würde man bei einem Auto den geringeren Spritverbrauch pro 100km im Rückwärtsgang als ernsthaften konstruktiven Vorteil hinstellen.

Realistisch hat nVidia wohl beim Lesen der Glaskugel während der Fermi-Entwicklung die Notwendigkeit an Tesselationsleistung für die nähere Zukunft schlicht überschätzt. Shit happens, eine Fehleinschätzung passiert jedem mal. Und in diesem Fall haben die Programmierer einen Fall kreirt, wo diese, sonst brachliegende, Leistung verbraten werden kann. Würde man davon als User mehr als nur extra Abwärme und Stromverbrauch haben, gäbe es nicht mal was dran zu meckern.

Das zusätzlich Schlimme daran ist, daß der fehlende Vorteil zusätzlich ein Argument für die Einführung eine Tesselation-Level-Kontrollfunktion (aber nicht unbedingt für den User!) ist: "Schutz for schlechter/unsinniger Programmierung, die unnötigen Leistungsverlust zur Folge hätte".

boxleitnerb
2011-08-17, 18:08:46
Die Power finde ich schon nicht verkehrt: Man kann in der Zeit, in der die Radeons noch tessellieren, schon weiterrechnen - auch bei vernünftigen Graden.

Aber die Entwickler müssen noch viel lernen bzw. sorgsamer arbeiten, das ist erstmal das Hauptproblem.

LovesuckZ
2011-08-17, 18:24:08
Aber einen echten Architekturnachteil der AMD-Designs daraus stilisieren zu wollen, daß die nVidia-Chips mit unsinnigen Implementationen von Tesselierung besser zurecht kommen, ist schon abenteuerlich.

Nein, das nennt man Wahrheit.
Abenteuerlich ist es über ein Thema zu schreiben, indem man sich nicht eingelesen hat. :freak:
Es gibt genug Belege für AMD's Designproblem. Die zu ignorieren, ist dann doch sehr irritierend. Wäre so wenn man sagt, dass Mercedes beim diesjährigen Formel 1 Auto kein Designproblem habe, nur weil 3 andere Firmen bessere Autos gebaut hätten...


Realistisch hat nVidia wohl beim Lesen der Glaskugel während der Fermi-Entwicklung die Notwendigkeit an Tesselationsleistung für die nähere Zukunft schlicht überschätzt. Shit happens, eine Fehleinschätzung passiert jedem mal. Und in diesem Fall haben die Programmierer einen Fall kreirt, wo diese, sonst brachliegende, Leistung verbraten werden kann. Würde man davon als User mehr als nur extra Abwärme und Stromverbrauch haben, gäbe es nicht mal was dran zu meckern.

Na, du hast die Fermi-Architektur nicht verstanden. Ist auch irgendwie nicht notwendig, wenn man über die Fermi-Architektur reden will. :rolleyes:


Das zusätzlich Schlimme daran ist, daß der fehlende Vorteil zusätzlich ein Argument für die Einführung eine Tesselation-Level-Kontrollfunktion (aber nicht unbedingt für den User!) ist: "Schutz for schlechter/unsinniger Programmierung, die unnötigen Leistungsverlust zur Folge hätte".

Ja? Komisch, wieso gibt es denn diesen Schalter, wenn AMD doch garkeine Probleme hätte?! Achja, dass das Herunterreglen durch den Schalter sich nicht auswirkt, ist in anderen Foren sogar schon widerlegt wurden: http://forums.anandtech.com/showpost.php?p=31992121&postcount=89

boxleitnerb
2011-08-17, 18:28:03
Achja, dass das herunterreglen durch den Schalter sich nicht auswirkt, ist in anderen Foren sogar schon widerlegt wurden: http://forums.anandtech.com/showpost.php?p=31992121&postcount=89

Den verlinkten Post verstehe ich nicht. Default ist das, was die Anwendung will (weil es ja noch kein Profil gibt). 64x ist sehr hoch - darüber wird Crysis 2 doch gar nicht gehen. Warum gibts da einen Performanceunterschied beim ersten Bilderpaar, wo (imo) keiner sein dürfte? Die Perspektive ist leicht anders und vielleicht gabs noch einen Nachladeruckler oder so. Den Werten vertraue ich nicht wirklich.

Warum hat er nicht z.B. mit Default vs. 16x getestet? Was der da gemacht hat, ist irgendwie sinnlos.

LovesuckZ
2011-08-17, 18:32:49
Den verlinkten Post verstehe ich nicht. Default ist das, was die Anwendung will (weil es ja noch kein Profil gibt). 64x ist sehr hoch - darüber wird Crysis 2 doch gar nicht gehen. Warum gibts da einen Performanceunterschied, wo (imo) keiner sein dürfte?

Warum hat er nicht z.B. mit Default vs. 16x getestet?

64x heißt nur, dass der Treiber den maximalen Grad weitergibt. Das kann alles zwischen 1x-64x bedeuten.
Was der andere Maximalgrad ist, weiß ich nicht. Ich hab die selben Bilder in einem weiteren Forum gesehen, aber das ganze ist zu lange her.

Gipsel
2011-08-17, 18:34:11
Den verlinkten Post verstehe ich nicht. Default ist das, was die Anwendung will (weil es ja noch kein Profil gibt). 64x ist sehr hoch - darüber wird Crysis 2 doch gar nicht gehen. Warum gibts da einen Performanceunterschied, wo (imo) keiner sein dürfte?

Warum hat er nicht z.B. mit Default vs. 16x getestet?
So wie das aussieht, hat er das einmal default (also unbeschränkt, die Karte macht, was das Game sagt, Beschränkung auf x64 wäre identisch, weil DX11 sowieso nur bis x64 unterstützt) laufen lassen und das andere mal auf x1 (oder x2, zumindest was ganz niedriges), da ist nämlich an den wichtigen Stellen gar keine Tessellation mehr zu erkennen. Dann sieht man natürlich schon den Unterschied. :rolleyes:

Aber das von LS vorgegebene Thema lautet ja "AMD will in Zukunft über den Tessellation-Level bestimmen". Da es bisher - wie Du ganz richtig sagst - keine Profile gibt, kann man das bisher allerdings klar verneinen ;)

Edit:
Im Übrigen weiß ich jetzt auch gar nicht, warum man hier groß über die Güte der Implementation von Tess in Crysis 2 diskutieren muß. Das ist einfach unter aller Kanone. Punkt. Und das hat mit dem eigentlichen Thema hier im Thread außerdem höchstens am Rande zu tun. Tessellation von vollkommen flachen oder auch schlicht nicht sichtbaren Objekten kostet auf jeder GPU des Universums unnötig Leistung. Das ist handwerklich schlecht, wie Mr. Lolman das bereits zum Ausdruck gebracht hat.

boxleitnerb
2011-08-17, 18:38:51
Jo :)
Nvidia sollte so einen Schalter auch einbauen. Dann könnten auch Leute mit beispielsweise einer GTX 550 die Performance anpassen. Hoffen wir mal, dass so ein Quark wie Crysis 2 eher die Ausnahme denn die Regel ist. Wie es richtig geht, zeigt Nvidias Endless City Demo.

Cyphermaster
2011-08-17, 18:53:33
Es gibt genug Belege für AMD's Designproblem. Die zu ignorieren, ist dann doch sehr irritierend. Wäre so wenn man sagt, dass Mercedes beim diesjährigen Formel 1 kein Designproblem habe, nur weil 3 andere Firmen bessere Autos gebaut hätten...Korrekt müßte das wohl eher lauten: "Wäre so, wie wenn man sagt, daß Mercedes bei allen ihren neuen Fahrzeugmodellen kein Problem hat, nur weil 3 andere Firmen bessere Formel-1-Modelle gebaut hätten".

Formel 1 ist nicht alles, und schon gar nicht der Normalfall - genau wie eine solche Implementation von Tesselation wie in Crysis 2 nicht die Einzige ist, sondern einfach unsinnig hochgezogene Geometrielast. Wenn du ein grundlegendes Architekturproblem belegen willst, müßte die Architektur nicht nur in so einem Sonderfall, sondern grundlegend zu schwach für die in Spielen vorkommenden Implementationen ausgelegt sein (so ähnlich, wie damals die Radeon 8500 bei "TruForm", das bei Nutzung praktisch jedes dazu fähige Programm zu einer nicht mehr spielbaren Diashow machte). Und so weit ich mich eingelesen habe, ist das nicht der Fall.

Fakt ist, daß man im Rennen um die FPS-Balken durch solche schlechten bzw. absichtlich tendenziösen (je nachdem, wie man's sehen will) Umsetzungen den Herstellern nur Wasser auf die Mühlen gießt, auch eine automatische, dem User nicht mehr zugängliche Tesselations-Levelkontrolle ("A.I. Version 2.0") verwirklichen zu wollen, die es bisher noch nicht gibt.
Na, du hast die Fermi-Architektur nicht verstanden. Ist auch irgendwie nicht notwendig, wenn man über die Fermi-Architektur reden will. :rolleyes:Nachdem du ja der Einzige zu sein scheinst, der Architekturen verstehen kann, fragt man sich sowieso, warum du dich so weit herabläßt, dich auf einem so niedrigen Niveau mit lauter solchen Unwissenden wie uns abzugeben. Kann natürlich nichts damit zu tun haben, daß man dich wegen deiner "rot-grün-Blindheit" und deiner Verbalarroganz aus anderen diesbezüglichen Foren schon rausgeschmissen hat.

LovesuckZ
2011-08-17, 19:02:52
Korrekt müßte das wohl eher lauten: "Wäre so, wie wenn man sagt, daß Mercedes bei allen ihren neuen Fahrzeugmodellen kein Problem hat, nur weil 3 andere Firmen bessere Formel-1-Modelle gebaut hätten".

Wenn wir über die Formel 1 reden, reden wir über das Formel 1 Auto und nicht über dem Straßen-Mercedes von nebenan.
Wenn du über diesen Wagen reden willst, dann mach das dann, wenn es das Thema ist.


Formel 1 ist nicht alles, und schon gar nicht der Normalfall - genau wie eine solche Implementation von Tesselation wie in Crysis 2 nicht die Einzige ist, sondern einfach unsinnig hochgezogene Geometrielast. Wenn du ein grundlegendes Architekturproblem belegen willst, müßte die Architektur nicht nur in so einem Sonderfall, sondern grundlegend zu schwach für die in Spielen vorkommenden Implementationen ausgelegt sein (so ähnlich, wie damals die Radeon 8500 bei "TruForm", das bei Nutzung praktisch jedes dazu fähige Programm zu einer nicht mehr spielbaren Diashow machte). Und so weit ich mich eingelesen habe, ist das nicht der Fall.

Da du nicht verstanden hast, wo das Problem liegt, siehst du auch nicht die Konsequenz aus jenem. Ob du mehr siehst, ist für die Erzeugung vollkommen belanglos. Es macht die Sache nicht besser, wenn die Absperrung mit Tessellation aussieht wie ein Stachelschwein, nur um einen optischen Unterschied aufzuzeigen. In beiden Fällen wäre der Leistungseinbruch annährend identisch.


Fakt ist, daß man im Rennen um die FPS-Balken durch solche schlechten bzw. absichtlich tendenziösen (je nachdem, wie man's sehen will) Umsetzungen den Herstellern nur Wasser auf die Mühlen gießt, auch eine automatische, dem User nicht mehr zugängliche Tesselations-Levelkontrolle ("A.I. Version 2.0") verwirklichen zu wollen, die es bisher noch nicht gibt.

Oder man baut bessere Hardware. Sowie es AMD zZ macht und bald veröffentlicht wird.
Lust auf eine Wette, dass der Front-End Aufbau von GCN mehr Fermi als Evergreen ähneln wird?


Nachdem du ja der Einzige zu sein scheinst, der Architekturen verstehen kann, fragt man sich sowieso, warum du dich so weit herabläßt, dich auf einem so niedrigen Niveau mit lauter solchen Unwissenden wie uns abzugeben. Kann natürlich nichts damit zu tun haben, daß man dich wegen deiner "rot-grün-Blindheit" und deiner Verbalarroganz aus anderen diesbezüglichen Foren schon rausgeschmissen hat.

Ich bin nicht der einzige. Ich bin nur der einzige, der es dir gegenüber sagt.
Nur weil immer mehr Zeugen Jehovas den Biologieunterricht bestürmen, ist der Darwinismus nicht falsch. Denkt mal darüber nach.

Gipsel
2011-08-17, 19:10:16
Da du nicht verstanden hast, wo das Problem liegt, siehst du auch nicht die Konsequenz aus jenem. Ob du mehr siehst, ist für die Erzeugung vollkommen belanglos. Es macht die Sache nicht besser, wenn die Absperrung mit Tessellation aussieht wie ein Stachelschwein, nur um einen optischen Unterschied aufzuzeigen. In beiden Fällen wäre der Leistungseinbruch annährend identisch.:facepalm:
Benutze ich ja echt nicht häufig, aber das geht ja wohl sowas am Problem in Crysis2 vorbei ...
Lust auf eine Wette, dass der Front-End Aufbau von GCN mehr Fermi als Evergreen ähneln wird?Also die bisher bekannten Blockdiagramme zu GCN sehen irgendwie deutlich unterschiedlich zu denen von Fermi aus. Die ähneln von der Anlage eher den älteren Radeons :rolleyes:

Und im Übrigen bitte ich doch noch einmal darum, sich in Zukunft etwas enger am Thema dieses Threads zu orientieren.