NVIDIA - Kepler

[isigrim]

Nein.
Die geforce verliren genauso viel mit tressfx wie die amd. Wenn dann müsste der Einbruch bei den NV-Karten deutlicher ausfallen.

 

[y33H@]

Tomb Raider zeigt schonungslos die GPGPU-Schwächen der GTX680.

Schau dir die Werte doch an, der prozentuale Leistungsverlust ist im integrierten Benchmark identisch - was für Nvidia spricht, denn bei Direct Compute und Open CL ist idR die HD 7970 GE deutlich schneller.

 

[ONH]

Schiele ich oder was, die gtx680 hat ganz ander resultate und prozentuale einbusse. Was man auch erahnen könnte wenn man sieht das nur die Titan und 670 verglichen werden und die ggtx680 nur in der umfangreicheren Tabelle vorkommt wo man mit und ohne Tresfx nicht ohne weiteres vergleichbar sind.

 

[Markus Everson]

Könnte ein Mod bescheid geben wenn die üblichen Verdächtigen ihren Genitalienvergleich beendet und die Hosen wieder zugeknüpft haben?

 

[y33H@]

Schiele ich oder was, die gtx680 hat ganz ander resultate und prozentuale einbusse. Was man auch erahnen könnte wenn man sieht das nur die Titan und 670 verglichen werden und die ggtx680 nur in der umfangreicheren Tabelle vorkommt wo man mit und ohne Tresfx nicht ohne weiteres vergleichbar sind.

Beim internen Bench ist nur die GTX 670 dabei, ja. Aber warum sollte eine schnellere GTX 680 stärker einbrechen als eine GTX 670? Tut sie nicht, d.h. der Einbruch ist genauso hoch wie bei der HD 7970 GE.

Guck dir aber zudem mal die Ingame-Benches weiter unten an, da bricht eine GTX 680/670 stärker ein als eine HD 7970 GE (allerdings nur um rund sechs Prozent, was sicherlich keine "Schwäche" ist) - im internen Benchmark wie gesagt nicht.

HD 7970 GE ohne/mit Tress FX (Avg-Fps) = 80,6 vs 59,0 (73,2 %)
GTX 680 ohne/mit Tress FX (Avg-Fps) = 80,3 vs 54,1 (67,4 %)
GTX 670 ohne/mit Tress FX (Avg-Fps) = 76,0 vs 50,7 (66,7 %)

 

[Complicated]

Könnte ein Mod bescheid geben wenn die üblichen Verdächtigen ihren Genitalienvergleich beendet und die Hosen wieder zugeknüpft haben?

Es sind immer die selben die den selben Nagel in jeden Thread hämmern.

 

[Markus Everson]

Ja, das ist mir auch schon aufgefallen.

 

[WindHund]

Wenn das so weiter geht wird nVidia bald Schwierigkeiten haben seine Aufpreise zu rechtfertigen.
Tomb Raider zeigt schonungslos die GPGPU-Schwächen der GTX680.
http://www.pcgameshardware.de/AMD-R...mb-Raider-PC-Grafikkarten-Benchmarks-1058878/
Nicht die Performance begeistert nicht gerade, auch die Treiberfehler sind nicht gerade Premium.

So kurz nach dem Verkausstart sind doch solche Bugs nicht ungewöhnlich!
Jetzt lass nvidia mal ordentlich den Treiber anpassen, oder meinetwegen auch ein Patch fürs Spiel, so ganz Perfekt ist es noch nicht, auch nicht mit AMD only Hardware.

Aber, die angesprochene GPGPU Schwäche gibt es, aber nicht bei TressFX.
Da muss man schon ein wenig in de Profi Bereich gehen, z.B. beim Rendern:

http://www.hardwareluxx.de/index.ph...-geforce-gtx-titan-im-3-way-sli.html?start=16

Spoiler

 

[mariahellwig]

So kurz nach dem Verkausstart sind doch solche Bugs nicht ungewöhnlich!

Laut nVidia soll es dafür keine schnelle Lösung geben. Das Problem ließe sich nicht allein über den Treiber lösen, hier wären Anpassungen am Code notwendig.
Mit nVidias Anspruch auf Premiumprodukte lässt sich das nicht vereinbaren. Bei der Konkurrenz gibt es funktionierende Produkte.

 

[Complicated]

Hmm damit stellt sich das ganze schon anders dar. Da die probleme sich umgehen lassen mit dem deaktivieren von Tesselation, könnte ich mir vorstellen dass dies mit der Hardware-Implementierung zu tun haben könnte. Ich kann mich noch gut daran erinnern wie es die Diskussion gab ob Nvidia überhaupt Tesselation richtig umgesetzt hat und "echte" DX11 Hardware anbietet, als sie sich entschlossen keine seperate Tesselation Unit zu verwenden, sondern mehrere Tesselatoren in den Polymporphen Engines:
http://www.anandtech.com/show/2977/...tx-470-6-months-late-was-it-worth-the-wait-/5

As we covered in our GF100 Recap, NVIDIA seeks to separate themselves from AMD in spite of the rigid feature set imposed by DirectX 11. Tessellation is one of the ways they intend to do that, as the DirectX 11 standard leaves them plenty of freedom with respect to tessellation performance. To accomplish this goal, NVIDIA needs significantly better tessellation performance, which has lead to them having 14/15/16 tesselators through having that many PolyMorph Engines. With

Dies könnte sich nun rächen, wegen einer vielleicht unsauberen Hardware-Implementierung.

Edit:
Es scheint hier auch nur wenig Veränderung gegeben haben gegenüber Fermi in Version 2.0 auf Kepler:
http://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-review/2

Because NVIDIA still only has a single Polymorph Engine per SMX, the number of Polymorph Engines hasn’t been doubled like most of the other hardware in an SMX. Instead the capabilities of the Polymorph Engine itself have been doubled, making each Polymorph Engine 2.0 twice as powerful as a GF114 Polymorph Engine. In absolute terms, this means each Polymorph Engine can now spit out a polygon in 2 cycles, versus 4 cycles on GF114, for a total of 4 polygons/clock across GK104.

 

[MusicIsMyLife]

Hmm damit stellt sich das ganze schon anders dar. Da die probleme sich umgehen lassen mit dem deaktivieren von Tesselation, könnte ich mir vorstellen dass dies mit der Hardware-Implementierung zu tun haben könnte.

Im 3DCenter berichten User, dass sich die Probleme umgehen lassen.

Einer hat einen älteren Treiber installiert und das Tomb Raider-Profil des aktuellen Treibers importiert und es läuft mit Tesselation und imho auch TressFX. Zwar etwas langsamer, aber statil.

Ein weiterer User hat das Problem gelöst, indem er das Profil für Tomb Raider gelöscht hat und dei EXE von TR dem Profil von Hitman Absolution hinzugefügt hat. Auch dort soll es mit Tesselation und Co. keine Probleme mehr geben.

Sollte das flächendeckend stimmen, dann liegt es "lediglich" am Treiber.

 

[Complicated]

Na dann hat sich Nvidia aber keinen Gefallen gemacht mit der Aussage es würde nicht am Treiber liegen, sondern der Code müsse geändert werden.

 

[eratte]

http://www.heise.de/ct/meldung/Nvidia-raet-vom-Spielen-von-Tomb-Raider-ab-1818774.html

 

[MusicIsMyLife]

Na dann hat sich Nvidia aber keinen Gefallen gemacht mit der Aussage es würde nicht am Treiber liegen, sondern der Code müsse geändert werden.

Ich habe gerade nochmal den Thread auf 3DC gelesen. Es scheint so, als seien mit den Workarounds nicht alle Probleme zu beheben, da einige weiterhin bzw. von neuen Problemen berichten.

Insofern muss ich meine Vermutung wohl etwas revidieren. Scheint doch mehr als eine reine Treibergeschichte zu sein.

 

[TobiWahnKenobi]

dann ist es bestimmt taktik, dass AMD mir meinen key für tombraider noch immer nicht geschickt hat.. auch wenn mir nicht ganz aufgeht, was die davon hätten.. *gg*

naja.. spaß beiseite.. schade um das spiel - hatte mich drauf gefreut.. aber vllt. gibts ja einen patch + ein treiber-update, bis ich endlich den hochlegalen key für das spiel erhalte.. falls das noch geschieht..

AMD habe ich am 5.3. angemailt, wo mein code bleibt (never settle bundle) - gestern kam eine automatische antwort, dass meine anfrage innerhalb von 24-48 std beantwortet wird. dehne ich das zeitfenster etwas aus, dann fallen die 48std ins wochenende und wahrscheinlich wird das dann vor montag wieder nix.


(..)

mfg
tobi

 

[amdfanuwe]

@Tobi
Die Codes sollten doch vom Händler beim Verkauf übergeben werden ? Scheint aber einige Probleme zu geben.
http://www.fudzilla.com/home/item/30700-not-all-rosy-with-amd-never-settle-reloaded
Ich drück mal die Daumen, dass es klappt.

Zu NVIDIA und PhysX auf PS4 hat Fudzilla auch einen Artikel.
http://www.fudzilla.com/home/item/30702-nvidia-hops-on-playstation-4-train

 

[TobiWahnKenobi]

ja, die liegen im karton.. aber nicht "die" (plural) sondern halt nur einer (singular) und damit registriert man sich bei AMD für das never-settle-bundle.

dann bekommt man eine bestätigungsmail und wartet sich den wolf..



(..)

mfg
tobi

 

[y33H@]

Bei mir kam der Key nach 10 sec ... bei den Kollegen auch.

 

[TobiWahnKenobi]

Bei mir kam der Key nach 10 sec ... bei den Kollegen auch.

weiter so.. nähre meinen verdacht, dass das bösartige absicht ist.



mehr kam bisher nicht.


(..)

mfg
tobi

 

[WindHund]

Laut nVidia soll es dafür keine schnelle Lösung geben. Das Problem ließe sich nicht allein über den Treiber lösen, hier wären Anpassungen am Code notwendig.
Mit nVidias Anspruch auf Premiumprodukte lässt sich das nicht vereinbaren. Bei der Konkurrenz gibt es funktionierende Produkte.

Ja das schon, aber wenn nvidia den Code erst letztes Wochenende bekommen hat, zaubern können die auch nicht.

Zu NVIDIA und PhysX auf PS4 hat Fudzilla auch einen Artikel.
http://www.fudzilla.com/home/item/30702-nvidia-hops-on-playstation-4-train

PhysX ist doch schon lange bestandteil mancher Spiele, also bei mir ist PhysX installiert. (z.B: wegen Metro2033)

 

[Complicated]

Meine Recherche ergibt, dass TressFX wohl in erster Linie auf Order Independent Transperancy basiert (OIT)
http://blogs.amd.com/play/tressfx/
Das hat AMD mit der HD5000 eingeführt es findet auch schon im Mecha Demo Anwendung:
http://developer.amd.com/resources/...deon-hd-5000-series-graphics-real-time-demos/
Die mit Direct Compute anschließend berechnenden Feinabstimmungen kommen auch bei DoF zum Einsatz und werden hier beim Lady Bug Demo auch schon genutzt.

Und Nvidia hat ebenfalls seit 2007 OIT im Programm (Präsentation aus 2008: http://www.slideshare.net/acbess/order-independent-transparency-presentation). Das Problem hierbei scheint allerdings zu sein, dass dies kein DX11 Feature ist, sondern jeder Hersteller eigene Implementierungen genutzt hat bisher. Bis dato war es auch nicht sinnvoll nutzbar ohne zu grosse Performance einbussen, was AMD scheinbar gelöst hat.

Dass Tesselation Auswirkungen hat mag mit der Reihenfolge der Pipeline zu tun haben und somit bei Nvidia Probleme verursachen. Siehe dazu: http://scalibq.wordpress.com/2012/0...tion-is-not-i-repeat-not-different-from-amds/

yVertex shader -> Hull shader -> Tessellator -> Domain Shader -> Geometry Shader -> Pixel shader

Diese Reihenfolge ist universell bei alle GPUs so. Doch die Nvidia Tesselatoren sind auf den SMX von Kepler verbaut und AMDs OIT fügt vor der Tesselation stage zusätzliche Details hinzu. AMDs Tesselator ist nicht verteilt und kann wahrscheinlich somit damit besser umgehen, während Nvidias Pipeline die zusätzlichen Informationen ja auf alle 14/15/16 Tesselatoren verteilen muss-und dafür wird es vermutlich keine Steuerbefehle geben im Code.

 

[Oi!Olli]

weiter so.. nähre meinen verdacht, dass das bösartige absicht ist.



mehr kam bisher nicht.


(..)

mfg
tobi

Du bekommst Bioshock umsonst? Jetzt bin ich neidisch.

 

[mariahellwig]

@Complicated
Dank für die Aufklärung.

 

[MP05]

Hallo,

Meine Recherche ergibt, dass TressFX wohl in erster Linie auf Order Independent Transperancy basiert (OIT)
http://blogs.amd.com/play/tressfx/
Das hat AMD mit der HD5000 eingeführt es findet auch schon im Mecha Demo Anwendung:
http://developer.amd.com/resources/...deon-hd-5000-series-graphics-real-time-demos/
Die mit Direct Compute anschließend berechnenden Feinabstimmungen kommen auch bei DoF zum Einsatz und werden hier beim Lady Bug Demo auch schon genutzt.

Und Nvidia hat ebenfalls seit 2007 OIT im Programm (Präsentation aus 2008: http://www.slideshare.net/acbess/order-independent-transparency-presentation). Das Problem hierbei scheint allerdings zu sein, dass dies kein DX11 Feature ist, sondern jeder Hersteller eigene Implementierungen genutzt hat bisher. Bis dato war es auch nicht sinnvoll nutzbar ohne zu grosse Performance einbussen, was AMD scheinbar gelöst hat.

Dass Tesselation Auswirkungen hat mag mit der Reihenfolge der Pipeline zu tun haben und somit bei Nvidia Probleme verursachen. Siehe dazu: http://scalibq.wordpress.com/2012/0...tion-is-not-i-repeat-not-different-from-amds/

Diese Reihenfolge ist universell bei alle GPUs so. Doch die Nvidia Tesselatoren sind auf den SMX von Kepler verbaut und AMDs OIT fügt vor der Tesselation stage zusätzliche Details hinzu. AMDs Tesselator ist nicht verteilt und kann wahrscheinlich somit damit besser umgehen, während Nvidias Pipeline die zusätzlichen Informationen ja auf alle 14/15/16 Tesselatoren verteilen muss-und dafür wird es vermutlich keine Steuerbefehle geben im Code.

Ich muss deiner Theorie leider widersprechen. Zunächst einmal ist Order-Independent-Transparency viel mehr die Bezeichnung für eine Reihe von Algorithmen für ein Problem in der Computergrafik als für einen konkreten Algorithmus. Das Problem ist, dass Alpha-Blending eine nicht kommuntative Operation ist(die Reihenfolge in der die Farbwerte kombiniert werden ist entscheidend). Wenn man also z.B. 3 verschiedene transparente Objekte hat, ensteht je nach Render-Reihenfolge eine andere Farbe. Ein Lösungsansatz ist also die 3 Objekte einfach nach der Entfernung zur Kamera zu sortieren. Das ist aber zum einen sehr rechenaufwändig und zum anderen keine Lösung Falls die Objekte sich gegenseitig schneiden und so keine eindeutige Sortierung möglich ist.
Order-Indepent-Transparancy soll eben genau dafür sorgen, dass die transparenten Objekte in beliebiger Reihenfolge gerendent werden können und die Alpha-Blending-Operation dennoch in korrekter Reihenfolge ausgeführt werden.

Ein Lösungsansatz dazu ist Depth-Peeling(die von die verlinkte NVidia-Präsi zeigt eine verbesserte Version dieses Algorithmus). Dabei wird die gesamte Geometrie mehrfach gezeichnet. Bei jedem Schritt wird immer der Farbwert sowie die Entfernung des Pixels, der der Kamera am nächsten ist, gespeichert. Bei jedem weiteren Schritt werden immer die Entfernungen des vorherigen Schritts verwendet um alle Pixel zu verwerfen, die bereits erfasst wurden(die Entfernung ist kleiner/gleich der Entfernung aus dem vorherigen Schritt).
Man erhält am Ende eine Reihe von Farbbildern die sozusagen die Tiefenschichten der Szene darstellen. Im ersten Bild sind also alle Pixel die der Kamera am nächsten sind, dann die, die am zweitnächsten sind usw. Am Ende muss man nur diese Bilder nacheinander mit Alpha-Blending verrechnen um das endgültige Bild zu erhalten.

Die Technik von AMD geht einen völlig anderen Weg, da es ein neues Feature von DirectX 11 nutzt, die sogenannten Append-/Consume-Buffer(sozusagen Bilder mit Listen pro Pixel, also ein Pixel kann beliebig viele Farbwerte speichern). Dabei muss die Geometrie nur ein einziges mal gerendert werden und anstatt nur einen Farbwert pro Pixel, pro Renderingpass speicher zu können, ist es nun möglich eine Liste von Farbwerten zu speichern. Man rendert also im wesentlichen die Geometrie merkt sich dabei die Farbe mit zugehörigen Tiefenwert in einer Liste für jeden Bildschirm-Pixel. In einem zweiten Schritt muss man nur jede Pixel-Liste der Tiefe nach sortieren und die Farben entsprechend mit Alpha-Blending verrechnen. Vorteil dieser Technik ist es, dass die Geometrie nur einmal gerendert werden muss und lediglich der Pixel-Shader etwas aufwendiger ist.

Die Technik funktioniert aber auf absolut jeder Hardware die DirectX 11(bzw. auch mit OpenGL 4.2) unterstützt und ist nicht AMD-exklusiv. Außerdem läuft die Technik vollständig im Pixel-Shader ab, weswegen sie auch keinen Einfluss auf die Tesselierung hat. Das Problem muss also an einer anderen Stelle entstehen.

Grüße

Marcel

 

[sompe]

Gibt es die gleichen Probleme bei der Fermi Architektur?