Warum ist Nvidias Performance/Watt besser ?

[gruffi]

Ist ehh total überbewertet das Feature Level 12_1. Praktisch nur die 980 Ti und Titan X unterstützen das bisher.

Und auch nur ROV, was sowieso noch keiner verwenden wird. GCN unterstützt CR.

 

[Locuza]

Laut y33H@ hat ein AMD Ingenieur auf Nachfrage bestätigt, dass beide Features fehlen.
Einen validen Gegenbeweis kannst du sowieso nicht erbringen.
Also wie wäre es wenn wir die Aussage von "GCN unterstützt CR", auf "ich glaube GCN unterstützt CR" ändern?

 

[mariahellwig]

Meine Güte, wie kann man sich an FL nur so festbeißen. Einen Quasselthread braucht das Forum eben...
Vielleicht sollte man dazu mal erwähnen dass, nVidia gerade mal OpenCL 1.2 unterstützt.

 

[isigrim]

Zum Glück hat nvidia schon länger eine Shader-basierte Lösung für Conservative Rasterization vorgestellt. Insofern lässt sich das vorerst wohl durch einen workaround "beheben" (Wohl mit Performance-Nachteilen).

ROVs scheinen eine andere Hausnummer und wirklich was zu bringen für die Pixel-Pipelines wenn sie denn mal breit implementiert sind. Da Intel das seit der Haswell-GPU unterstützt, dürfte es eigentlich beim Marktanteil schon ziemlich verbreitet sein.
Aber inwiefern unterscheidet sich die ROV-Implementierung in DX12.1 von Intels OpenGL Erweiterung (GL_INTEL_fragment_shader_ordering)? Die wird ja wohl von AMD ab GCN und seit OpenGL 4.3 unterstützt oder? (Siehe auch hier)

Vielleicht sollte man Graham Sellers mal fragen, wie gut die workarounds sind. Möglicherweise hilft RB Tier 3, dass der Performance Hit nicht so groß ausfällt.

 

[Locuza]

Realisieren lässt sich alles von den neuen Features.
Für den praktischen Gebrauch ist eine ordentliche Hardware-Implementierung allerdings unerlässlich.

Die Extension wird von AMD unterstützt, Andrew von Intel hat es getestet und meinte es würde extrem langsam ablaufen.
Die WDDM2 Treiber von AMD melden kein ROV Support zurück.
Also selbst wenn die Möglichkeit für AMD mit Workarounds besteht, so hat AMD darauf verzichtet.

 

[isigrim]

"Ordentlich" ist so eine Sache. Schneller wenn in Hardware, ja klar, sonst würde es niemand verdrahten. Die Frage ist, wie groß ist der Performance Hit.

Wer ist Andrew von Intel? Ist das der, der in Deutschland Sergio von Smirnoff ist? Meinst du Andrew Lauritzen? Dann wäre ich für einen Link dankbar, falls es ein anderer Andrew ist, auch.

Es sind zwei verschiedene Paar Stiefel, ob man eine Erweiterung in OpenGL transparent unterstützt oder ob man einen Workaround (?) als DX-Feature deklariert. Mir geht es um die technischen Aspekte dahinter. Das einzige konkrete, was ich dazu gefunden habe ist das hier:

A possible approach for how AMD is implementing this extension is using the GDS memory (64KB of cache with built-in atomic operations shared across execution units). Tahiti (Radeon HD7900 ASIC) has 32 execution units, each working on 16 * 16 pixels tile for a total of 8192 pixels at a time (32 * 16 * 16).
Hence, the GDS has 8 bytes per pixel which implies that trashing the cache will be very quick without screen space coherence. With atomic exchange, a wavefront would have to spin on beginFragmentShaderOrderingINTEL waiting for GDS changes preventing the launch of further shader
invocation arrays to hide the wait. Southern Islands being capable to have up to 10 shader invocation array live per execution unit we are limiting ourselves to 1/10 of the GPU peak performance. Without careful profiling, using this extension will be particularly slow on AMD hardware.

(Quelle: PDF, S. 25)
Das würde dann vielleicht auch erklären, warum es nicht als DX-Feature deklariert wird. Bei OpenGL könnte das aber speziell im professionellen Bereich auch unter Performance-Einbußen nützlich sein.

 

[Locuza]

Bei Intel gibt es nur einen einzigen Menschen mit dem Namen Andrew.
Ich habe Andrew Lauritzen gemeint.

Last time I tried that extension on AMD it was incredibly slow... like it took 300ms to render a single trivial test frame when enabled with no overlap/contention at all. That may have just been some buggy initial code but unless someone has run - for instance - the Intel sample on GCN lately and determined that it's actually fast now, I wouldn't count on this being particularly usable... certainly they'd have to do better to legitimately claim hardware support in my opinion.

https://forum.beyond3d.com/threads/directx-12-the-future-of-it-within-the-console-gaming-space-specifically-the-xb1.55487/page-40#post-1823113

Welche genaue Zielführung strebst du an, mit dem technischen Aspekt dahinter?
Einfach nur das Wissen selber?

Edit: Unter OGL mit praktischer Geschwindigkeit wäre es natürlich interessant.

Intel hat übrigens ein Forschungspapier um das Thema Conservative Rasterization.
Sie haben irgendeinen Software-Algorithmus erstellt und dann eine Abschätzung gegenüber einer möglichen Hardware-Implementation bei jedem IHV aufgestellt. Es war glaube ich Hawaii vs. Kepler GK110 und ein Haswell Ableger.
Bei der Software-Implementierung schnitt GCN sehr gut ab.
Wie groß die vermutete Kluft zwischen Soft vs. Hardware ist weiß ich dagegen nicht mehr genau.
Bei Interesse suche ich das Paper.

 

[isigrim]

Danke!

Ja, genau, mir geht´s rein ums Wissen. Denn das Thema ist so ein typischer "Ich argumentiere mir Halbwissen"- und Buzzword-Dropping-Bereich. Jeder meint er könnte was dazu sagen, aber kaum jemand weiß, wovon er spricht. Und wenn ich was hasse, dann Worthülsen.

Bei Intels Forschungen zu Conservative Rasterization meinst du wahrscheinlich das hier oder?

BTW: Andrew Grove wäre auch ein Kandidat gewesen, obwohl der dafür inzwischen vielleicht ein bisschen zu alt ist

 

[Locuza]

Genau, die Ergebnisse auf Seite 9 in der Tabelle.

 

[isigrim]

Da hat man dann auch die Antwort. CR in Software kostet pro frame zwischen 12,4 ms und 80,9 ms. Das ist schon einiges.

 

[gruffi]

Laut y33H@ ...

Hab schon besser gelacht. Fakt ist, dass AMD CR schon seit längerem softwaresetig unterstützt. Und seit Tonga (GCN Gen3) soll es auch hardwareseitig unterstützt werden.

Bei dem ganzen quote-war verliere ich langsam auch den Überblick, aber es ging um diesen Beitrag:
http://www.planet3dnow.de/vbulletin/threads/422742-Warum-ist-Nvidias-Performance-Watt-besser?p=5021863&viewfull=1#post5021863

Darauf folgend habe ich die 3D-Center Tabelle gepostet, die im Schnitt Maxwell weiterhin eine bessere Perf/Watt bescheinigt.

Und wie wir festgestellt haben, beinhaltet die Tabelle zum einen falsche Werte und zum anderen ist sie ziemlich unseriös aufgestellt. Also was willst du damit grossartig anfangen? Sowas ist einfach unbrauchbar.

Bei Hardware.fr verbraucht das zweite Fiji Sample 301W.

Irrelevant, weil zum einen keine AMD Referenz und zum anderen nur ein einziges Spiel, ohne Nachvollziehbarkeit der Effizienz. Aber wie gesagt, Hardware.fr ignoriert man genauso wie TPU am besten. Die sind klar pro Nvidia eingestellt. Faire Vergleiche sollte man da nicht erwarten.

Nvidias Mitarbeiter sagt deutlich ...

Meine Güte, das wurde doch alles schon diskutiert. Warum wärmst du den gleichen Quark immer wieder erneut auf? Was Nvidia sagt, ist belanglos. Der Entwickler muss sich dazu äussern. Nur die wissen genau, wie die Engine PhysX nutzt, sonst niemand. Und der Entwickler hat bisher eben nirgendwo klar dementiert, dass GPU PhysX genutzt wird.

Ich finde es an der Stelle nur schade, dass Nvidia viele coole Features nicht geschafft hat zu implementieren

Habe das mal der Wahrheit entsprechend korrigiert. AMD unterstützt im Moment anscheinend nur ein einziges (!) Feature hardwareseitig nicht. Bei Nvidia sind es deutlich mehr.

und wir zusätzlich noch GCN1/2 GPUs im Angebot haben. Was man ansonsten Nvidia immer vorgeworfen hat, den Fortschritt verzögern, trifft jetzt leider auch auf AMD zu.

Unsinn. AMD hat alleine mit Mantle mehr Fortschritt in die Branche gebracht als alle anderen in den letzten 5 Jahren zusammen. Es ist nach wie vor Nvidia, die den Fortschritt verhindern, indem sie proprietäre und teure Technologien durchzusetzen versuchen und auf existierende Standard pfeifen (siehe Adaptive Sync vs G-Sync) oder indem sie dem Stand der Technik nur hinterherrennen (zB bindless Architektur oder HBM), und stattdessen lieber damit beschäftigt sind, Entwickler zu schmieren, damit Spiele auf der Hardware der Konkurrenz ausgebremst werden.

Ich denke es ist klar das ich auf die yields und Komplexität abziele und darauf aufbauend, eben die zu erwartende Vorgehensweise bei der Einführung eines großes die auf einen relativ unerprobten Fertigungsprozess.
Bei Tonga trifft das alles nicht zu.

Das sind doch auch alles nur Ausflüchte und haben mit der eigentlichen Aussage nichts zu tun. Du hast behauptet, dass Tonga der erste Chip gewesen sei, bei dem so lange nach dem Launch immer noch kein vollwertiger Chip auf dem Markt ist. Und das war er mitnichten. Was die Ursachen dafür sind, ist doch völlig belanglos für die Aussage gewesen.

Ich wäre einer in der ersten Reihe, welcher jubeln würde, falls Gen 3 wirklich CR/TR3 unterstützt.

Was hast du denn ständig mit deinem TR3? Wie oft muss man eigentlich noch wiederholen, dass das keine Voraussetzung für FL12_1. Einzig TR2 ist Voraussetzung für DirectX 12. Was von AMD unterstützt wird.

Der Sprung von FL11.1 auf FL12.0 besteht aus 3 nötigen Features.

Der Sprung von FL11_1 auf FL12_0 besteht aus wesentlich mehr. Und das weisst du ganz genau.

Und der letzte Abschnitt beinhaltet eine interessante Ansicht.
MS hätte sich auch async compute aufsparen können, bis Intel es unterstützt und W10 anläuft.
Oder Binding-Tier 3 gar nicht in das Binding-Model aufnehmen, bis W10 angelaufen ist und die anderen es implementiert haben.
Aber lass mich raten, dass ist alles gar nicht vergleichbar.

Wenn du das weisst, wieso erwähnst du es dann erst? Richtig, verschiedene Tiers ist was anderes als spezielle Features. Das lässt sich in der Tat nicht vergleichen. Soll man Resource Binding Tier 1 und 2 in FL12_0 aufnehmen und sich Tier 3 für 12_1 aufsparen? Schwachsinniger ginge es wohl kaum noch.

Mit TR3 kommen 3D-Koordinaten dazu, entsprechend finden sich mögliche Anwendungen bei der Voxel-Berechnung, eben Sachen mit grafischem Volumen.

Wow, das wird Nvidia ja richtig helfen, bei all den ganzen Voxel-Engines im Moment. Wenn das mal keine guten Nachrichten für ein Comanche Remake sind.

Ich sehe das Kepler effizienter ist, aber die DP-Lösung hat dabei keinen nennenswerten Anteil.

Das ist aber nur deine Meinung, die mehr als fragwürdig ist. Der Hauptgrund, warum Kepler effizienter wurde, ist, dass man die CUDA Kerne deutlich verschlankt hat. Und ein signifikanter Teil war, dass man Computing Funktionalität gestrichen hat. Ua eben DP, was mir bisher so nicht bekannt war. Ich wusste nur, dass man die Integer ALUs gestrichen hatte.

Offenbar zeigen die Kunden, Microsoft und Sony, dass bei AMD noch Luft nach oben existiert.

Da beweist du aber äusserst viel Phantasie. Davon steht in der Aussage jedenfalls nichts.

 

[isigrim]

Es macht echt keinen Spaß mehr hier zu lesen, wenn ständig Anschuldigungen und Behauptungen hin und her geschoben werden.

@gruffi
Wo ist der Verweis dass GCN 1.2 CR unterstützt...? Ich hab gesucht, aber nichts konkretes gefunden.

 

[y33H@]

Fakt ist, dass AMD CR schon seit längerem softwaresetig unterstützt. Und seit Tonga (GCN Gen3) soll es auch hardwareseitig unterstützt werden.

Ach, jez reden wir von Software ... für GCN 1.2 widersprichst du AMD: Kein CR und kein ROV in Hardware.

Aber wie gesagt, Hardware.fr ignoriert man genauso wie TPU am besten. Die sind klar pro Nvidia eingestellt. Faire Vergleiche sollte man da nicht erwarten.

Alle Welt ist pro NV, nur du bist das kleine Gallier-Dorf, herrlich.

Und der Entwickler hat bisher eben nirgendwo klar dementiert, dass GPU PhysX genutzt wird.

Die Die Slightly Mad Studios sagen, PhysX läuft der CPU: http://forum.projectcarsgame.com/showthread.php?26370-Project-CARS-On-AMD-GPUs-Clarification

AMD unterstützt im Moment anscheinend nur ein einziges (!) Feature hardwareseitig nicht. Bei Nvidia sind es deutlich mehr.

Kein CR und kein ROV in Hardware ... NV kann kein Binding Tier 3.

 

[Locuza]

Hab schon besser gelacht. Fakt ist, dass AMD CR schon seit längerem softwaresetig unterstützt. Und seit Tonga (GCN Gen3) soll es auch hardwareseitig unterstützt werden.

Ich weiß gruffi, es kann nicht sein, was nicht sein darf.
Entsprechend lügt und biegt jeder, welcher Aussagen tätigt, die in dein Weltbild nicht passen:

- Nvidia sagt es wird kein GPU-PhysX bei Project Cars verwendet --> irrelevant was Nvidia sagt, der Entwickler hat keine explizite Aussage veröffentlicht, wo GPU-PhysX direkt dementiert wird.
- Ein AMD Ingenieur hat einem Golem Journalisten bestätigt, dass beide Features fehlen (CR und ROVs) --> schon mal besser gelacht
- Ein Table mit Verbrauchsmessungen von 6 Publikationen zeigen im Schnitt einen geringeren Verbrauch bei Nvidia an --> unseriös aufgestellt, unbrauchbar. PCGH, hardware.fr, TPU und vermutlich auch heise zählen nicht.


Es ist schön das AMD faktisch CR softwareseitig seit längerem unterstützt.
Nvidia hat das laut dem Artikel auch schon seit der Geforce FX geschafft:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter42.html

Und noch einmal, aufgrund welcher Basis soll GCN Gen 3 CR auch hardwareseitig unterstützen?
Immer noch aufgrund der VC-News voller Fehler?

Schon eigenartig das meine Argumentationskette mit Links zu Beiträgen, Videos, seitenlangen PDFs zur Theorie und Praxis keine überzeugende Darstellung repräsentieren, egal zu welchem Thema, aber so eine News bisher als als Grundlage herhalten muss, dass GCN Gen 3 CR unterstützt.
Wirklich ironisch das du so eine verbissene Haltung bei der nötigen Beweisführung pflegst, selber aber überhaupt nichts brauchbares liefern kannst.

Und wie wir festgestellt haben, beinhaltet die Tabelle zum einen falsche Werte und zum anderen ist sie ziemlich unseriös aufgestellt. Also was willst du damit grossartig anfangen? Sowas ist einfach unbrauchbar.

Sie beinhaltet praktisch keine falschen Werte.
Nur bei hardware.fr wurde ein Durchschnitt errechnet.
Dein Einwurf wieso man das bei der 980Ti nicht gemacht hat, kann man damit beantworten, dass das EVGA Modell keine Referenz-Karte darstellt.
Welche beim Rating übrigens noch eine bessere Perf/Watt besitzt als das Referenz-Modell.
An dieser Stelle wird 3DC wohl kaum die EVGA Performance mit dem Verbrauch der Referenzkarte gemixt haben.
Bei BF4 verbrauchen Fury X und 980 Ti grob ähnlich viel Strom, bloß springt mehr Performance bei der Nvidia-Karte heraus.
Ja, beim Luxx ist die Fury X schneller gewesen, aber einen passenden Verbrauchswert haben wir an dieser Stelle nicht gehabt.
Bei der reinen Verbrauchsmessung, durch welche Anwendung auch immer, steht 50W mehr auf der Fury X Waage:
http://www.hardwareluxx.com/index.php/reviews/hardware/vgacards/35798-reviewed-amd-r9-fury-x-4gb.html?start=6

Aber da das alles nicht gilt, mache ich einfach das gleiche wie bei vermutlich 5 weiteren Diskussionsthemen, ich warte ab und lass die Wahrheit auf uns zukommen.
Also ht4u und Toms HW waren die mit der genauesten Messung, richtig?
Ich hoffe die sind auch seriös, weil ansonsten bleibt echt nicht mehr viel übrig...

Irrelevant, weil zum einen keine AMD Referenz und zum anderen nur ein einziges Spiel, ohne Nachvollziehbarkeit der Effizienz. Aber wie gesagt, Hardware.fr ignoriert man genauso wie TPU am besten. Die sind klar pro Nvidia eingestellt. Faire Vergleiche sollte man da nicht erwarten.

Es sind zwei Spiele, die perf/watt hat man unter 1440p errechnet.
Was ist an dem zweiten Sample keine AMD Referenz?

Meine Güte, das wurde doch alles schon diskutiert. Warum wärmst du den gleichen Quark immer wieder erneut auf? Was Nvidia sagt, ist belanglos. Der Entwickler muss sich dazu äussern. Nur die wissen genau, wie die Engine PhysX nutzt, sonst niemand. Und der Entwickler hat bisher eben nirgendwo klar dementiert, dass GPU PhysX genutzt wird.

Weil du an deinem Quark sehr zu hängen scheinst.
Würde der Entwickler GPU-PhysX verwenden, könnte man das nachstellen und die Menschen haben auch nachgemessen, aber vermutlich funktioniert die Einstellung bei der Systemsteuerung sowieso nicht und das ganze läuft immer auf der GPU.
Bei deinem ersten Beitrag dazu hast du geschrieben, dass ProjeCars ein "GameMurks" verkrüppeltes Spiel sei und vermutlich GPU-PhysX der Hauptgrund für das schlechte abschneiden bei AMD sein.
Der Entwickler hat bei seiner Rechtfertigung keine explizite Aussage fallen gelassen, bei welcher GPU-PhysX direkt ausgeschlossen wird, aber wenigstens das PhysX nur ein sehr kleiner Teil des Physik-Systems ist, unter 10% und das Project Cars kein GameWorks Produkt ist.
Entsprechend kann man dann wenigstens unter dieser Betrachtung sagen, dass PhysX nicht das Problem bei den AMD-GPUs darstellt.
Hier hast du aber auch schon eingeworfen, dass selbst 10% je nach Laufzeit viel ausmachen können.
Da habe ich entsprechend gefragt, wieso Project Cars dann auf den Konsolen mit 1,6 Ghz Jaguar-Cores halbwegs anständig läuft?
Ich glaub es ging zu Ende mit der Aussage, Konsolen interessieren nicht.

Habe das mal der Wahrheit entsprechend korrigiert. AMD unterstützt im Moment anscheinend nur ein einziges (!) Feature hardwareseitig nicht. Bei Nvidia sind es deutlich mehr.

Ich finde es schön das wir immerhin zu "anscheinend" gekommen sind.
Nicht mehr zur absoluten Ansicht das ich Märchen erzähle.
Natürlich wird aber auch bei diesem Zitat eine Gegenfrage nicht fehlen, welche Features fehlen Nvidia?
Da muss dir vieles einfallen, wenn es "deutlich mehr" sind.
Da TR3 scheinbar nicht gilt, würde ich dir natürlich auch gleich anraten bei AMD ebenso zu filtern, was dann in die Kategorie nicht passt.

Unsinn. AMD hat alleine mit Mantle mehr Fortschritt in die Branche gebracht als alle anderen in den letzten 5 Jahren zusammen. Es ist nach wie vor Nvidia, die den Fortschritt verhindern, indem sie proprietäre und teure Technologien durchzusetzen versuchen und auf existierende Standard pfeifen (siehe Adaptive Sync vs G-Sync) oder indem sie dem Stand der Technik nur hinterherrennen (zB bindless Architektur oder HBM), und stattdessen lieber damit beschäftigt sind, Entwickler zu schmieren, damit Spiele auf der Hardware der Konkurrenz ausgebremst werden.

AMD hat gewaltig zum Fortschritt beigetragen, ohne Widerwort.
Das jetzt aber auch Dinge fehlen, stimmt leider auch.
Bei G-Sync verstehe ich teilweise die Herangehensweise von Nvidia, aber außerhalb davon stellt Nvidia ihr hässliches Geschäftsgesicht zur Schau.
Es war übrigens G-Sync die erste Lösung mit dynamischen Refresh bei Monitoren.
Davor gab es zwar die eDP-Spec, aber dort wurde die Fähigkeit von keinem ausgenutzt.
Ich stimme natürlich auch nicht zu, dass Nvidia damit beschäftigt ist all die anderen auszubremsen und Entwickler zu schmieren.
Es gibt manipulative Handlungen von Nvidia, aber man kann nicht jede Situation pauschalisieren.
Und auf der anderen Seite, Nvidia macht Sachen, was machen die anderen?

Das sind doch auch alles nur Ausflüchte und haben mit der eigentlichen Aussage nichts zu tun. Du hast behauptet, dass Tonga der erste Chip gewesen sei, bei dem so lange nach dem Launch immer noch kein vollwertiger Chip auf dem Markt ist. Und das war er mitnichten. Was die Ursachen dafür sind, ist doch völlig belanglos für die Aussage gewesen.

Meine Aussage war, mit all den Umständen, dass Tonga der erste Chip ist, der so komisch auf den Markt geworfen wurde.
Man könnte teils den RV770 in den Ring werfen, welcher nie voll aktiviert auf den Markt erschienen ist.
Aber beim Desktop bietet AMD weder ein volles Shader-Array, noch ein volles Speicherinterface.

Was hast du denn ständig mit deinem TR3? Wie oft muss man eigentlich noch wiederholen, dass das keine Voraussetzung für FL12_1. Einzig TR2 ist Voraussetzung für DirectX 12. Was von AMD unterstützt wird.

Wie oft muss ich eig. noch fragen, warum wir uns hier auf FL12.1 beschränken?
Wenn wir das tun, dann kicken wir mal das Binding-Tier 3 von GCN raus, ist auch keine Voraussetzung.
Ich beziehe mich auf deine erste Behauptung, dass GCN das modernere Design ist, welches sich vor allem bei zukünftigen APIs auswirken soll.
Mein Einwurf an der Stelle war, dass es ein FL gibt und insgesamt 3 Features, welche AMDs GPUs nicht bieten.
So eindeutig scheint die Lage nicht zu sein.

[Und ja ich weiß, GCN Gen 3 unterstützt CR und TR3 ist keine Voraussetzung und es geht eig. nur um ROVs und die sind nicht besser, es geht auch anders.
Und wenn ROVs doch super sind, dann hat AMD sowieso schon lange Support dafür, weil erst dann relevant.
Dabei wäre die Annahme, dass Nvidia zu dem Zeitpunkt auch die restlichen Features anbietet vermutlich eh albern.]

Der Sprung von FL11_1 auf FL12_0 besteht aus wesentlich mehr. Und das weisst du ganz genau.

Ach wirklich?
http://8pic.ir/images/veemhqc286k5isfbl9i2.jpg

Wenn du das weisst, wieso erwähnst du es dann erst? Richtig, verschiedene Tiers ist was anderes als spezielle Features. Das lässt sich in der Tat nicht vergleichen. Soll man Resource Binding Tier 1 und 2 in FL12_0 aufnehmen und sich Tier 3 für 12_1 aufsparen? Schwachsinniger ginge es wohl kaum noch.

Weil ich natürlich schon abgeschätzt habe, dass du eine krude Ansicht haben wirst.
Sind Tiers jetzt ein Konstrukt, welches Features nicht zu einem speziellen Feature machen?
Conservative Rasterization bietet 3 Tiers an, Nvidia unterstützt, zu deinem Glück, scheinbar nur CR1.
Tiled Resources hat 3 Tiers, Nvidia unterstützt das höchste.
ROVs sind auch ein tolles Feature und keines der drei und vor allem gemeinsam, kann man einen geringen Funktionsumfang unterstellen.
Ansonsten könnte man das bei async-compute auch machen, dass hat nämlich keine Tiers und ist ein baseline Feature der DX12 API allgemein.
Du kannst natürlich gerne darlegen, was für beeindruckende Dinge dank async-compute möglich werden und was für Krimskrams lediglich durch CR1, ROVs und TR3 ermöglicht wird.

Wow, das wird Nvidia ja richtig helfen, bei all den ganzen Voxel-Engines im Moment. Wenn das mal keine guten Nachrichten für ein Comanche Remake sind.

Ich habe meinen Standpunkt schon klar gemacht. Ob das in absehbarer Zeit eine Bedeutung hat, wird vor allem an Nvidia liegen.
Und natürlich das im Vergleich RB3 als ein Vorteil für AMD herausspringen muss.
Ich bin gespannt auf mögliche Auswirkungen, könntest du dir welche vorstellen?

Das ist aber nur deine Meinung, die mehr als fragwürdig ist. Der Hauptgrund, warum Kepler effizienter wurde, ist, dass man die CUDA Kerne deutlich verschlankt hat. Und ein signifikanter Teil war, dass man Computing Funktionalität gestrichen hat. Ua eben DP, was mir bisher so nicht bekannt war. Ich wusste nur, dass man die Integer ALUs gestrichen hatte.

Also ich sage dazu schlichtweg ALUs, CUDA Kerne sind eine unsinnige Erfindung von Nvidias Marketing.
Ich habe nicht mehr alles im Kopf, aber bei Kepler wurde der Hot-Clock abgeschafft, dass Cache-BW-Ratio pro ALU verringert (Compute-Einschnitt), ebenso wurde das ALU:TMU Verhältnis auf Seiten der TMUs gesenkt.

Nvidia hat jeweils viel an der Architektur verändert.
Meine Meinung, dass man sich lieber Chips mit gleicher Architektur, aber unterschiedlichem DP-Ratios anschauen sollte, anstatt verschiedene Architekturen mit entsprechend aberhunderten Veränderungen, ist sicher nicht mehr als fragwürdig, wenn man ein Gefühl dafür bekommen will welchen Anteil DP an den Effizienzwerten hat.

Die Integer-ALUs hat man nicht gestrichen:

SMX Processing Core Architecture
Each of the Kepler GK110 SMX units feature 192 single?precision CUDA cores, and each core has fully
pipelined floating?point and integer arithmetic logic units.

Seite 9:
http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf

Da beweist du aber äusserst viel Phantasie. Davon steht in der Aussage jedenfalls nichts.

Ahh, wer hat dann die jeweiligen Compiler bei den Konsolen geschrieben?
Wieso fallen dort die Ergebnisse deutlich besser aus, als das was bei AMD auf dem PC herauskommt?

 

[gruffi]

@gruffi
Wo ist der Verweis dass GCN 1.2 CR unterstützt...? Ich hab gesucht, aber nichts konkretes gefunden.

Wurde zuvor schon mal verlinkt, siehe hier.

- Nvidia sagt es wird kein GPU-PhysX bei Project Cars verwendet --> irrelevant was Nvidia sagt, der Entwickler hat keine explizite Aussage veröffentlicht, wo GPU-PhysX direkt dementiert wird.

Korrekt.

- Ein AMD Ingenieur hat einem Golem Journalisten bestätigt, dass beide Features fehlen (CR und ROVs)

Schon klar, das hat er. So wie John Fruehe einst bestätigt hat, dass Bulldozer mehr IPC als K10 hat.

- Ein Table mit Verbrauchsmessungen von 6 Publikationen zeigen im Schnitt einen geringeren Verbrauch bei Nvidia an --> unseriös aufgestellt, unbrauchbar.

Korrekt. Dass die Tabelle falsch berechnete Werte enthält, wurde ja nachgewiesen. Dass du trotzdem behauptest, da würde irgendwas brauchbares angezeigt werden, ist schon recht dreist. Bedenklicher finde ich allerdings, dass du extremen Nvidia Fanboy Seiten wie Hardware.fr oder TPU glaubst, aber Seiten wie CB oder THG nicht, obwohl die gemessen an der Performance keine grundlegend geringere Leistungsaufnahme bei Nvidia zeigen, und dass obwohl zB CB ja auch alles andere als pro AMD ist.

Und noch einmal, aufgrund welcher Basis soll GCN Gen 3 CR auch hardwareseitig unterstützen?
Immer noch aufgrund der VC-News voller Fehler?

Um dich mal zu zitieren, ich weiss Locuza, es kann nicht sein, was nicht sein darf. Entsprechend lügt und biegt jeder, welcher Aussagen tätigt, die nicht in dein Weltbild passen. Auf jeden Fall glaube ich VC hier mehr als jemandem, der in der Vergangenheit durch Unwissenheit, Ignoranz und bewussten Falschaussagen oft genug negativ gegenüber AMD aufgefallen ist. Der steht nicht grundlos bei mir auf Ignore.

Schon eigenartig das meine Argumentationskette mit Links zu Beiträgen, Videos, seitenlangen PDFs zur Theorie und Praxis keine überzeugende Darstellung repräsentieren, egal zu welchem Thema, aber so eine News bisher als als Grundlage herhalten muss, dass GCN Gen 3 CR unterstützt.

Dumm nur, dass deine "Argumentationskette" rein gar nichts zu AMD's CR Implementierung zeigt. Was also soll da überzeugen? Bisher hast du eigentlich nur durch Ausflüchte geglänzt, die zum eigentlichen Thema bzw zu den gestellten Fragen nichts beigetragen haben, oder durch Behauptungen, die du nicht belegen konntest durch entsprechende Quellen. Sowas nenne ich typische Pseudo-Fanboy-Argumentation. Entweder hältst du dich ans Thema und akzeptierst, dass es in gewissen Punkten im Moment keine zuverlässigen Informationen gibt, und lässt deine unbewiesenen Behauptungen bleiben. Oder ich kann dich weiterhin nicht ernst nehmen.

Sie beinhaltet praktisch keine falschen Werte.

Doch, das tut sie. Das habe ich dir sogar vorgerechnet.

Bei der reinen Verbrauchsmessung, durch welche Anwendung auch immer, steht 50W mehr auf der Fury X Waage:
http://www.hardwareluxx.com/index.php/reviews/hardware/vgacards/35798-reviewed-amd-r9-fury-x-4gb.html?start=6

Nein, tut es nicht, da das Gesamtsystemmessungen sind. Für die Grafikkarten selbst ist es weniger. Ausserdem steht da nicht, was getestet wurde. Insofern bleiben solche Diagramme einfach wertlos. Und aus Effizienzsicht sowieso, da unterschiedliche PT verwendet werden. Die Custom GTX 980 Ti mit höherem PT braucht mehr als die Fury X. Die Temperatur und Lautstärke sind bei der Fury X auch weitaus besser. Das ignorierst du natürlich ebenso ständig.

Es sind zwei Spiele, die perf/watt hat man unter 1440p errechnet.

Und warum postest du dann nur eine Leistungsaufnahme, die nicht mal von der AMD Referenzkarte stammt? Mal davon abgesehen sagen auch zwei Spiele herzlich wenig. Erst recht bei so fragwürdigen Ergebnissen wie bei hardware.fr. HT4U hat die Leistungsaufnahme vor Jahren mal über etliche Spiele gemessen. Wenn man das über verschiedene Auflösungen und Einstellungen hinweg macht, und ebenso die dazugehörigen FPS hat, kann man einigermassen zuverlässige Erkenntnisse gewinnen. Leider macht das niemand. Insofern kann man die Situation Im Moment nur grob bewerten. Und da geben sich beide Karten bei gleichem PT quasi nichts oberhalb von 1080p. Ausser man legt Wert auf pro Nvidia Seiten wie hardware.fr.

Was ist an dem zweiten Sample keine AMD Referenz?

Gegenfrage, wo siehst du, dass die zweite Karte ein Pressesample von AMDs Referenz ist? Ich sehe davon nichts.

Weil du an deinem Quark sehr zu hängen scheinst.

Erstens ist es dein Quark. Und zweitens hänge ich alles andere als daran. Es wäre nur langsam mal angebracht, dass du Fakten akzeptierst.

Würde der Entwickler GPU-PhysX verwenden, könnte man das nachstellen und die Menschen haben auch nachgemessen

Und die Messungen zeigen eben einige deutliche Unterschiede. Insofern bestärkt das nur die Vermutung, dass auch die GPU für PhysX verwendet wird. Aber toll, dass du weiter in dem Quark rumrührst, obwohl wir ja schon an dem Punkt waren, dass definitiv was unlauteres hinter den Kulissen vorgeht, egal ob es jetzt an PhysX liegt oder nicht.

Der Entwickler hat bei seiner Rechtfertigung keine explizite Aussage fallen gelassen, bei welcher GPU-PhysX direkt ausgeschlossen wird, aber wenigstens das PhysX nur ein sehr kleiner Teil des Physik-Systems ist, unter 10% und das Project Cars kein GameWorks Produkt ist.

Was ansich schon eine ziemlich dreiste Lüge ist. "Project Cars" nutzt PhysX, egal ob CPU oder GPU. Damit ist es auch ein Gameworks Titel. Schliesslich ist PhsX Teil von Gameworks.

Hier hast du aber auch schon eingeworfen, dass selbst 10% je nach Laufzeit viel ausmachen können.
Da habe ich entsprechend gefragt, wieso Project Cars dann auf den Konsolen mit 1,6 Ghz Jaguar-Cores halbwegs anständig läuft?
Ich glaub es ging zu Ende mit der Aussage, Konsolen interessieren nicht.

Da sieht man mal, wie wenig du Beiträge eigentlich liest oder deren Inhalt verstehst. Ich habe nicht gesagt, dass Konsolen nicht interessieren. Ich sagte, dass die Vergleichbarkeit für unterschiedliche GPUs bei den Konsolen fehlt und man somit überhaupt nicht beurteilen kann, wie gut oder schlecht "Project Cars" auf Konsolen läuft. Ausserdem ist es keine identische Codebasis zum PC. Auch das lässt keine Rückschlüsse auf die PC Version zu.

Ich finde es schön das wir immerhin zu "anscheinend" gekommen sind.
Nicht mehr zur absoluten Ansicht das ich Märchen erzähle.

Das hat beides nichts miteinander zu tun. Das "anscheinend" bezieht sich darauf, dass wir selbst zu ROVs noch keine zuverlässigen Informationen haben. Keine Sorge, du behauptest schon noch genügend Märchen, ohne entsprechende Nachweise.

Natürlich wird aber auch bei diesem Zitat eine Gegenfrage nicht fehlen, welche Features fehlen Nvidia?

Wurde doch alles schon mehr als genügend genannt, Nvidias Architektur ist nicht bindless, unterstützt keine Async Shaders, SAD4 und Conservative Depth werden nur emuliert, keine Atomic Counters usw. Und wenn du dich so sehr auf TR3 versteifst, dann solltest du auch nicht verschweigen, dass AMD ein höheres Typed UAV Tier unterstützt. So oder so, es hinterlässt schon einen ziemlich verzweifelten Eindruck, wenn man sich wie du auf 1-2 Features bei Nvidia versteift, aber nahezu alles bei AMD verschweigt.

Das jetzt aber auch Dinge fehlen, stimmt leider auch.

Das sind erstens aber keine Sachen, die jetzt schon dringend gebraucht werden. Und zweitens fehlt bei der Konkurrenz immer noch mehr. Deshalb zu behaupten, AMD würde den Fortschritt verhindern, ist absoluter Irrsinn. Der Fokus beim Fortschritt liegt im Moment sowieso bei den neuen APIs (Vulkan / DirectX 12). Die müssen erst mal auf den Markt kommen und auch verwendet werden. Die Hardware dafür steht schon länger bereit, gerade bei AMD. Wenn DirectX 12.1 mal relevant wird, in vielleicht frühestens 2 Jahren, dann können wir immer noch darüber diskutieren, wer welches Feature unterstützt.

Es war übrigens G-Sync die erste Lösung mit dynamischen Refresh bei Monitoren.

Nein. Das war Adaptive Sync.

Aber beim Desktop bietet AMD weder ein volles Shader-Array, noch ein volles Speicherinterface.

Im iMac gibt's Tonga mit allen Shadern. Das ist Desktop.

Wie oft muss ich eig. noch fragen, warum wir uns hier auf FL12.1 beschränken?

Weil es da konkret um FL12_1 ging, also CR und ROVs, wo du immer wieder deplatziert TR eingeworfen hast.

Mein Einwurf an der Stelle war, dass es ein FL gibt und insgesamt 3 Features, welche AMDs GPUs nicht bieten.

Was nach wie vor falsch ist. Einzelne Tiers sind auch nicht das gleiche wie Features. AMD unterstützt jedenfalls TR als Feature. Alles darüber hinaus sind nur Tiers.

Ach wirklich?
http://8pic.ir/images/veemhqc286k5isfbl9i2.jpg

Du weisst schon, dass DirectX 12 nicht nur FL12_0 ist? Das meiste wurde schon mit FL11_3 eingeführt. Es ging dabei aber auch nicht nur um die Features ansich, sondern um die gesamte API. Der Sprung von DirectX 11.1 zu DirectX 12 ist ziemlich gewaltig. Der Sprung von DirectX 12 zu DirectX 12.1 ist dagegen vergleichsweise gering.

Sind Tiers jetzt ein Konstrukt, welches Features nicht zu einem speziellen Feature machen?

Tiers sind jedenfalls keine Features. Es sind und bleiben Tiers.

ROVs sind auch ein tolles Feature

Nicht wirklich. Es führt einen serialisierten Algo ein, der entgegen der Natur paralleler Architekturen ist. OIT konnte man auch bisher. Und solange der Effizienzgewinn von ROVs nicht nachgewiesen wurde, bleibe ich da skeptisch. Viel interessanter und spannender finde ich Async Shaders und CR, da es im Gegensatz zu ROVs bezüglich Performance und visuelle Qualität einiges bringen kann. Aber du darfst natürlich gerne vorführen, welche beeindruckenden Effizienzverbesserungen sich durch ROVs bewerkstelligen lassen. Mal davon abgesehen hat TR immer noch nichts mit FL12_1 zu tun.

Ich habe meinen Standpunkt schon klar gemacht. Ob das in absehbarer Zeit eine Bedeutung hat, wird vor allem an Nvidia liegen.

Nein, wird es nicht. Es wird einzig an Microsoft/Khronos und an den Entwicklerstudios liegen.

Die Integer-ALUs hat man nicht gestrichen

Per se nicht, das hat auch keiner gesagt. Wenn du es schon nicht weisst, dann achte doch zumindest darauf, auf was du antwortest und was du zitierst. In dem Nvidia PDF ist die Rede vom gesamten SMX Block, nicht von einzelnen CUDA Kernen. Ein CUDA Kern sah bei Fermi noch so aus:

http://images.anandtech.com/doci/7793/cudacore.jpg

DP FP und Integer wurde bei Kepler entfernt. Die vor allem für Spiele relevanten CUDA Kerne beherrschen also nur noch SP FP. DP und Integer wurden bei Kepler in separate CUDA Kerne ausgelagert. Daher stieg die Anzahl der Kerne auch auf das Dreifache. Aus einem SP FP, DP FP und Integer CUDA Kern wurden quasi 3 CUDA Kerne gemacht. Wie ich zuvor schon sagte, ein CUDA Kern wurde deutlich verschlankt. Das hilft die Effizienz bei spezifischen Workloads zu steigern. Man kann damit aber nicht alle Workloads effizient verarbeiten. Oder anders formuliert, Computing-Effizienz wurde für Grafikeffizienz geopfert.

Ahh, wer hat dann die jeweiligen Compiler bei den Konsolen geschrieben?

Ja wer denn? Wieso habe ich das Gefühl, dass du auch das nicht wirklich weisst?

 

[isigrim]

Ich denke, ich werde morgen mal eine Mail an Graham Sellers aufsetzen und ihn zum Stand von Conservative Rasterization und Rasterized Ordered Views bei GCN befragen. Wäre das hier ein Lösung?

So schlecht wie du meinst, ist die Computing-Effizienz von Maxwell nicht. (siehe z.B. Luxmark-Werte) Das betrifft eigentlich nur DP.

 

[y33H@]

Wurde zuvor schon mal verlinkt, siehe hier.

Videocardz schreibt gerne mal Unfug. AMDs Aussage ist eindeutig und bisher konntest du (wie erwartet) nicht das Gegenteil beweisen.

Schon klar, das hat er. So wie John Fruehe einst bestätigt hat, dass Bulldozer mehr IPC als K10 hat.

Meine Quelle ist nicht JF.

Gegenfrage, wo siehst du, dass die zweite Karte ein Pressesample von AMDs Referenz ist? Ich sehe davon nichts.

Es gibt derzeit sowohl für die Presse als auch für Endkunden einzig das Referenz-Design, was PC Partner fertigt.

Und die Messungen zeigen eben einige deutliche Unterschiede. Insofern bestärkt das nur die Vermutung, dass auch die GPU für PhysX verwendet wird.

Ein Typ, der bei Reddit Schwachsinn postet gegen mehrere Redaktionen, die es sauber geprüft und als falsch aufgezeigt haben.

Es wird in Project Cars kein GPU-PhysX verwendet!

 

[BoMbY]

Hat jemand eine R9 285 oder Fury X unter Windows 10 am laufen? Dann könnte man mit diesem Tool mal schauen, was das aktuell zum "ConservativeRasterizationTier" sagt.

 

[Locuza]

Schon klar, das hat er. So wie John Fruehe einst bestätigt hat, dass Bulldozer mehr IPC als K10 hat.
[]
Um dich mal zu zitieren, ich weiss Locuza, es kann nicht sein, was nicht sein darf. Entsprechend lügt und biegt jeder, welcher Aussagen tätigt, die nicht in dein Weltbild passen. Auf jeden Fall glaube ich VC hier mehr als jemandem, der in der Vergangenheit durch Unwissenheit, Ignoranz und bewussten Falschaussagen oft genug negativ gegenüber AMD aufgefallen ist. Der steht nicht grundlos bei mir auf Ignore.

Oh, seit John Fruehe gilt vermutlich das Gesetz, dass jeder AMD Mitarbeiter Unwahrheiten verbreitet.
Was stellt überhaupt noch eine legitime Quelle dar?

Natürlich kommen Fälle vor wo nicht immer die Wahrheit gesagt wird, aber ich möchte doch lieber Anhaltspunkte wo die Wahrscheinlichkeit groß ist.
Bei VC ist sie es definitiv nicht, WhyCry schreibt sowohl unter ROVs, als auch bei CR Unsinn und da schon mindestens ein Teil nicht stimmt, ist die News entsprechend zu bewerten.

AMD hat offiziell bestätigt das FL12.1 nicht unterstützt wird.
Daraus ergibt sich ein mindestens ein fehlendes Feature, ROVs oder CR.
Wie bist du darauf gekommen das es die ROVs sein müssen, welche nicht unterstützt werden?

Das beides fehlt, da akzeptiere ich den Anhaltspunkt, dass es Marc von einem AMD Ingenieur bestätigt wurde.
Bei den ersten Beta-Treibern für W10 hat es bei Tonga keinen Support für beide Features gegeben:
http://images.anandtech.com/reviews/video/dx12/fls/285.png

Nvidia hat es dagegen schon am Anfang geschafft.
http://images.anandtech.com/reviews/video/dx12/fls/GTX980.png
https://forum.beyond3d.com/threads/direct3d-feature-levels-discussion.56575/page-4#post-1833996

Es wäre natürlich großartig, wenn es mal jemand bei Tonga/Fiji wiederholen könnte mit den neusten Treibern.
Ich habe jedenfalls keine Hoffnung das noch das Lämpchen bei CR oder den ROVs aufleuchtet.

Korrekt. Dass die Tabelle falsch berechnete Werte enthält, wurde ja nachgewiesen. Dass du trotzdem behauptest, da würde irgendwas brauchbares angezeigt werden, ist schon recht dreist. Bedenklicher finde ich allerdings, dass du extremen Nvidia Fanboy Seiten wie Hardware.fr oder TPU glaubst, aber Seiten wie CB oder THG nicht, obwohl die gemessen an der Performance keine grundlegend geringere Leistungsaufnahme bei Nvidia zeigen, und dass obwohl zB CB ja auch alles andere als pro AMD ist.

Wenn ich den Durchschnitt von allen 5 Werten errechne, kommt für Fury X 272,4W heraus und nicht die 284W die in der Tabelle stehen.
Bei der 980Ti 233,4 W und nicht die 237W.
Entsprechend verwirrend ist das ganze und du hast Recht das dort falsche Werte stehen, die jeweils einzelnen Verbrauchswerte wurden allerdings korrekt abgeschrieben und siehe da, von 5 Werten verbraucht die Fury X 4 mal mehr.
Natürlich hat das aber eine relativ geringe Aussage, weil wir wollen ja die Perf/Watt abschätzen.

Das hat Hardware.fr ausgerechnet bei BF4 und Anno2070, dass ist aber eine extreme Nvidia Fanboy Seite, ebenso wie TPU und CB ist natürlich auch nicht pro AMD.
Heiliger bimbam, woher kommt dieser Nvidia Fanboytum bei den Redaktionen?

Aber ich schweife ab, konzentrieren wir uns auf Toms Hardware, die einzige legitime Seite (noch? ).
Da sollte ja ein Follow-Up mit Perf/Watt erscheinen, der liebe Herr hat aber schon Teaser auf 3DC verlinkt, die du ja auch schon mitbekommen hast:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10689024&postcount=1870

9 Werte, 8 für Nvidia, 1 für AMD.
Zugegeben unter Full-HD geht der Gewinn immer nur knapp aus.
Unter UHD gewinnt aber Nvidia dagegen stark.
Da haben wir ja das Power-Limit von Nvidia, wo ich gesagt habe es würde doch auch für AMD Sinn machen es restriktiver anzusetzen.
Du meintest aber, man kann das Power-Target bei AMD senken oder die Frame-Limit Funktion verwenden.

Dazu:

Die Fury X verballert ohne echtes Power Limit massig Energie, ohne dass man das in FPS sieht. Das ist wie mit Gigabytes Gaming G1 Karten, die am Ende vielleicht 2% schneller sind, aber 15% mehr schlucken.

Der [FPS-Limiter] produziert leider sporadische Framedrops zusammen mit dem Arbitrator, um die verlustleistung unten zu halten. Das klappt noch nicht wirklich.

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10689045#post10689045
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10689054#post10689054

In der Praxis nachgemessen funktioniert das wirklich nicht prima:

Das geht von 267 Watt runter bis auf 170 Watt, aber die Min Frames sind albern und es hoppelt. Bei -20% und 256 Watt sehe ich das vertretbare Minimum. das Power Limit bringt echt nichts

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=564554&page=95

Was meint der gute Herr noch so zum Thema?

Endlich mal einer, der das Diagramm RICHTIG interpertiert

Power Target ist nicht Power Limit. Nvidia richtet es filigraner, bei AMD bleibt immer irgend etwas auf der Strecke. Leider. Es macht keinen Sinn, das Power Limit auf weniger als -10% einzurichten. Das hoppelt fast immer, nicht erst seit Fury. Bei Maxwell kannst Du übers Power Target indirekt eine ausgewogene Spar-Karte herstellen (siehe meine 80W GTX 960), machst Du das mit einer Radeon, gehen die min FPS auf Grundeis. Da bleibt nur, manuell runterzutakten und die Spannungen abzusenken. Wobei letzteres bei Fury nicht geht.

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10689293#post10689293

Fazit: Ein weiter Fanboy ist geboren, ein weiterer Sieg für Nvidia.
Bleibt uns nur noch Computerbase übrig, die trotzt contra AMD-Einstellung bei Ryse objektiv über alle anderen >10 Werte der restlichen Redaktionen hinaus Fury X eine gleich gute, wenn nicht leicht bessere Perf/Watt attestieren.

Und damit:

Mit der Fury sollte sich nun auch das Thema erledigt haben, dass Nvidia besser bei Performance/Watt ist.

Soviel zu den Spielen, bei Compute haben wir soweit ich das mitbekommen habe einen Messpunkt unter Luxmark der objektiv dafür spricht, dass AMD über 50% mehr Perf/Watt unter der Disziplin heraushaut.

Dumm nur, dass deine "Argumentationskette" rein gar nichts zu AMD's CR Implementierung zeigt. Was also soll da überzeugen? Bisher hast du eigentlich nur durch Ausflüchte geglänzt, die zum eigentlichen Thema bzw zu den gestellten Fragen nichts beigetragen haben, oder durch Behauptungen, die du nicht belegen konntest durch entsprechende Quellen.
Sowas nenne ich typische Pseudo-Fanboy-Argumentation. Entweder hältst du dich ans Thema und akzeptierst, dass es in gewissen Punkten im Moment keine zuverlässigen Informationen gibt, und lässt deine unbewiesenen Behauptungen bleiben. Oder ich kann dich weiterhin nicht ernst nehmen.

Oh mein Gott nein, sollte diese Behauptung stimmen, dann haben wir extrem viel gemeinsam.

Die Temperatur und Lautstärke sind bei der Fury X auch weitaus besser. Das ignorierst du natürlich ebenso ständig.

Ist das fiepen wirklich besser?
Nein im ernst, die kühleren Temperaturen und wenn es Chargen ohne Fiep/Pumpprobleme gibt, ist es schön so etwas zu haben.
Ich ignoriere es nur ständig, weil ich mich jeweils nur auf die Perf/Watt konzentriert habe.

Und warum postest du dann nur eine Leistungsaufnahme, die nicht mal von der AMD Referenzkarte stammt?

Ich weiß du spottest jetzt wieder, aber es werden bisher nur Referenzkarten geliefert.
Quelle: Golem Redakteur Marc Sauter.

Edit: PCGH:

Die ursprünglichen, lauten R9 Fury X stammten alle von PC Partner, der die Grafikkarten eigentlich für Tests von der Fachpresse im Auftrag von AMD zusammengebaut hat. Um eine zeitnahe Verfügbarkeit nach der Veröffentlichung ("Time to market") zu gewährleisten, wurden viele Modelle aus dieser Charge per Luftfracht in den weltweiten Einzelhandel gebracht. Erst die nächsten Produktionsläufe kommen per kostenoptimierten Schiffweg in den Handel – und genau das scheint mittlerweile auch passiert zu sein.

http://www.pcgameshardware.de/AMD-Radeon-R9-Fury-X-4G-Grafikkarte-260708/News/Neue-Pumpe-ohne-Fiepen-1163701/

Aber wir haben oben den Test von Toms Hardware, dort haben sich keine Auswirkungen bei einem höheren Power-Target gezeigt.
Also könnte ein Hersteller theoretisch nur bei der Spannung gepfuscht haben.

Erstens ist es dein Quark. Und zweitens hänge ich alles andere als daran. Es wäre nur langsam mal angebracht, dass du Fakten akzeptierst.

Ich solle den Fakt akzeptieren, dass es nicht Fakt ist, dass kein GPU-PhysX verwendet wird?

Und die Messungen zeigen eben einige deutliche Unterschiede. Insofern bestärkt das nur die Vermutung, dass auch die GPU für PhysX verwendet wird. Aber toll, dass du weiter in dem Quark rumrührst, obwohl wir ja schon an dem Punkt waren, dass definitiv was unlauteres hinter den Kulissen vorgeht, egal ob es jetzt an PhysX liegt oder nicht.

Die Messungen von wem?

Von dem User?
https://www.reddit.com/r/pcgaming/comments/36aoir/project_cars_is_physx_really_running_on_gpu_a/

Oder den ganzen Haufen hier?

http://cdn.overclock.net/0/0d/0dcb6241_zM0z932.jpeg

http://cdn.overclock.net/6/67/675ad0c6_CPUGPUPhysX_ann3.PNG

http://cdn.overclock.net/5/5a/5a1a7e1d_pcars_testi2_annotated.PNG

http://cdn.overclock.net/f/fe/fe04dee7_CPUPhysX2.png

https://www.reddit.com/r/pcmasterra...roject_cars_does_not_use_gpu_physx_on_nvidia/

https://www.youtube.com/watch?v=Vb5qRJG0zFo

Oder PCGHs und Golems eigene Nachmessung:

Der Physik haben wir noch einmal gesondert auf den Zahn gefühlt, da Vermutungen laut wurden, dass Nvidia mittels Physx einen Teil der Physik-Berechnungen auf die GPU auslagern und so einen Vorteil erzielen könnten. Dies ist nicht der Fall, auch mit einer Nvidia-GPU werden die Physx-Berechnungen zum aktuellen Stand durch die CPU vorgenommen.

http://www.pcgameshardware.de/Project-CARS-PC-238576/Specials/Benchmark-Test-1158026/

Vielleicht gibst du mir 5 Cent für die Aussage dieses Slightly Mad Mitarbeiters bei den Steam-Foren?

It's just CPU, we do not use GPU based physx...

https://steamcommunity.com/app/234630/discussions/0/613957600541659871/?insideModal=1#c613957600543261874

Vermutlich muss ich hier noch eine ganze Doktorarbeit, wenn nicht besser 3 verlinken, um eine legitime Beweisführung gegen paar Bullshitwerte und Verschwörungstheorien zu haben.

Und hey, mir ging es auch nicht absolut darüber das Nvidia 100% unschuldig und überall ist, sondern um die Aussage das GPU-PhysX der Hauptschuldige für das schlechte abschneiden der Radeons ist.
Und ich hoffe das verdammte Thema hat sich damit erledigt, dass Spiel verwendet kein GPU-PhysX.

Was ansich schon eine ziemlich dreiste Lüge ist. "Project Cars" nutzt PhysX, egal ob CPU oder GPU. Damit ist es auch ein Gameworks Titel. Schliesslich ist PhsX Teil von Gameworks.

Es nutzen über hunderte von Spielen PhysX, alles Gameworks Titel jetzt?
Bioshock Infinite hat PhysX als Physikgrundlage genommen und war ein Titel unter AMDs Gaming Evolved Programm.
AMD hat einen GameWorks Titel gesponsert?
Wie verrückt ist das denn.

Vielleicht gibt es doch eine feinere Unterscheidung, wann man von einem GameWorks Produkt sprichst und wann nicht.
Oder gilt das nur ab jetzt für sämtliche Spiele, also seitdem es den Begriff GameWorks gibt und auf der Seite auch PhysX aufgelistet wird?

Da sieht man mal, wie wenig du Beiträge eigentlich liest oder deren Inhalt verstehst.

Ich versuche mir mehr Mühe zu geben, aber ich habe kein positives Gefühl das es beim gegenseitigem Verständnis besser klappen wird.

Keine Sorge, du behauptest schon noch genügend Märchen, ohne entsprechende Nachweise.

Also Märchen sind ja wirklich Auswüchse der Phantasien, welche Behauptungen habe ich aufgestellt ohne wenigstens Anhaltspunkte dafür zu haben?
Wenn es um wasserfeste Alibis zu jedem Mordfall geht, die habe ich leider tatsächlich nicht.

Wurde doch alles schon mehr als genügend genannt, Nvidias Architektur ist nicht bindless, unterstützt keine Async Shaders, SAD4 und Conservative Depth werden nur emuliert, keine Atomic Counters usw. Und wenn du dich so sehr auf TR3 versteifst, dann solltest du auch nicht verschweigen, dass AMD ein höheres Typed UAV Tier unterstützt. So oder so, es hinterlässt schon einen ziemlich verzweifelten Eindruck, wenn man sich wie du auf 1-2 Features bei Nvidia versteift, aber nahezu alles bei AMD verschweigt.

Nvidias Architektur ist teilweise bindless, unterstützt Async Shaders und zu SAD4 und conservative depth habe ich nichts brauchbares gefunden, aber etwas unbrauchbares, die Tabelle:
http://i.imgur.com/aAqqZYo.png

Ich habe von Anfang an RB3 eingeworfen, später auch noch PS specified stencil reference value und die zusätzlichen UAV-Formate, die GCN unterstützt.
Die übergreifenden Feature-Optionen findet man übrigens hier:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn770364%28v=vs.85%29.aspx

Das sind erstens aber keine Sachen, die jetzt schon dringend gebraucht werden. Und zweitens fehlt bei der Konkurrenz immer noch mehr. Deshalb zu behaupten, AMD würde den Fortschritt verhindern, ist absoluter Irrsinn. Der Fokus beim Fortschritt liegt im Moment sowieso bei den neuen APIs (Vulkan / DirectX 12). Die müssen erst mal auf den Markt kommen und auch verwendet werden. Die Hardware dafür steht schon länger bereit, gerade bei AMD. Wenn DirectX 12.1 mal relevant wird, in vielleicht frühestens 2 Jahren, dann können wir immer noch darüber diskutieren, wer welches Feature unterstützt.

Welche Dinge werden denn jetzt schon dringend gebraucht?
Eben nicht die, welche Nvidia und Intel unterstützen, richtig?
Natürlich kann man behaupten das AMD Fortschritt verzögert, tun sie ja auch.
Tut Nvidia auch, tut Intel auch.
Tut jeder der nicht optimal 100% des möglichen unterstützt.

Man muss natürlich nicht total radikal sich auf etwas fokussieren, aber es sind tolle Features spezifiziert, wo es schön wäre frühzeitig Kundenvolumen aufzubauen.
Du hast natürlich völlig Recht, dass die neuen APIs selber zuerst auf den Markt kommen müssen und verwendet werden.
Es gibt auch ohne die höchsten FLs und optionalen Features eine Menge Dinge die Entwickler tun können und wahrscheinlich auch zuerst tun werden.
Ich möchte zum Schluss noch einmal darauf hinweisen, dass es bisher kein DX12.1 gibt, es kommt wenn, dann irgendwann mal später, mit welchen Änderungen auch immer.

Nein. Das war Adaptive Sync.

Die Adaptive Sync Spec auf welche FreeSync zugreift, wurde erst nach G-Sync in den DP-Standard aufgenommen.
Und bei eDP hat es auch keiner davor verwendet.

Vielleicht habe ich mich erneut nicht wasserdicht ausgedrückt.

Im iMac gibt's Tonga mit allen Shadern. Das ist Desktop.

Ich muss mich wirklich genauer ausdrücken.
Gemeint habe ich natürlich eine dGPU bzw. SKU die ich einzeln erwerben kann.
Nicht die mobile m295X, die nur in Fertiggeräten verbaut wird.

Weil es da konkret um FL12_1 ging, also CR und ROVs, wo du immer wieder deplatziert TR eingeworfen hast.

Ging es das? Entsprechend interessiert TR3 dann nicht.

Was nach wie vor falsch ist. Einzelne Tiers sind auch nicht das gleiche wie Features. AMD unterstützt jedenfalls TR als Feature. Alles darüber hinaus sind nur Tiers.

Dann unterstützt ja Intel Resource-Binding als Feature. RB2 und 3 sind dann lediglich nur Tiers.
Man kann sich jetzt streiten, ob man eine Funktionsabstufung einzeln als Feature bezeichnet.

Du weisst schon, dass DirectX 12 nicht nur FL12_0 ist? Das meiste wurde schon mit FL11_3 eingeführt. Es ging dabei aber auch nicht nur um die Features ansich, sondern um die gesamte API. Der Sprung von DirectX 11.1 zu DirectX 12 ist ziemlich gewaltig. Der Sprung von DirectX 12 zu DirectX 12.1 ist dagegen vergleichsweise gering.

Ich weiß es, weißt du das es überhaupt kein FL11.3 gibt?
Du hast das Thema Lobbyarbeit angesprochen, da FL12.1 nur zwei neue Features erfordert.
Mein Einwurf war, dass FL12.0 auch nur drei erfordert und wir dort von einer 11 auf eine 12 springen und nicht eine Nachkommastelle erhöhen.
Jetzt geht es auf einmal um die gesamte API.
Und hier auch wieder, DX-Version != FL-Version, entsprechend gibt es kein DX12.1.

Es gibt bisher nur DX11, DX11.1, DX11.2, DX11.3 und DX12.
Das davor zähle ich mal nicht auf.
Bis DX11.1 gab es ein entsprechendes Feature-Level mit der gleichen Nummerierung.
Ab DX11.2 kam aber kein neues FL hinzu, es blieb bei FL11.1 mit optionalen Features.
DX11.3, welches parallel zu DX12 entwickelt wird, führt auch kein neues FL ein.
Sondern abermals optionale Features.

Ein Beweis darf natürlich nicht fehlen:
https://msdn.microsoft.com/en-us/library/windows/desktop/ff476329%28v=vs.85%29.aspx

Der Sprung von DX11.1 auf DX12 ist natürlich gewaltig, aber das ist nicht gleichzusetzen mit dem Sprung von FL11.1 auf FL12.0.
(Es gibt wie gesagt DX11.2 und DX11.3, aber kein FL11.2 oder FL11.3)
FL11.0/1 gibt es unter beiden APIs, FL12.0/1 nur unter DX12, dort werden aber "nur" 3 Features für FL12.0 gegenüber FL11.1 zwingend benötigt und 2 für 12.1 gegenüber FL12.0.

Tiers sind jedenfalls keine Features. Es sind und bleiben Tiers.

Wenn du das so beschreiben möchtest gerne, für die Praxis hat das jedes mal eine etwas andere Relevanz.

Nicht wirklich. Es führt einen serialisierten Algo ein, der entgegen der Natur paralleler Architekturen ist. OIT konnte man auch bisher. Und solange der Effizienzgewinn von ROVs nicht nachgewiesen wurde, bleibe ich da skeptisch. Viel interessanter und spannender finde ich Async Shaders und CR, da es im Gegensatz zu ROVs bezüglich Performance und visuelle Qualität einiges bringen kann. Aber du darfst natürlich gerne vorführen, welche beeindruckenden Effizienzverbesserungen sich durch ROVs bewerkstelligen lassen. Mal davon abgesehen hat TR immer noch nichts mit FL12_1 zu tun.

"ROVs sind ein tolles Feature".
Antwort: Nicht wirklich



Ich habe dir fette PDFs verlinkt, ich habe dir ein Interview mit Johan Andersson verlinkt, dem Technical Director der Frostbite Engine, der bei AMD stark mitgeholfen hat Mantle zu realisieren und auf die Frage welche Features er sich für die Zukunft gerne wünschen würde, hat er mit ROVs geanwortet:

Johan: That's a fun question. We have a pretty long list of all the stuff we typically go through and then talk to them with, but one very concrete thing we’d like to see, and actually Intel has already done this on their hardware, they call it PixelSync, which is their method of synchronizing the graphics pipeline in a very efficient way on a per-pixel basis.You can do a lot of cool techniques with it such as order-independent transparency for hair rendering or for foliage rendering. And they can do programmable blending where you want to have full control over the blending instead of using the fixed-function units in the GPU. There’s a lot of cool components that can be enabled by such a programability primitive there and I would like to see AMD and Nvidia implement something similar to that as well. It's also very power-efficient and efficient overall on Intel's hardware, so I guess the challenge for Nvidia and AMD would be if they were able to do that efficiently because they have a lot of the different architectures there. So that's one thing.

http://www.tomshardware.com/reviews/johan-andersson-battlefield-4-interview,3688-2.html

Ich kann dir noch dutzende Beiträge von sebbi und anderen Entwicklern dazu verlinken.
Und ROVs sind nicht ein spezielles Feature einzig und allein für OIT.
OIT stellt "lediglich" eines der Paradebeispiele für die mögliche Verwendung da.
Man kann damit auch mehr anstellen.

Man kann sich auch Grid 2 anschauen, es verwendet PixelSync:
http://www.computerbase.de/2013-07/intel-iris-pro-5200-grafik-test/7/

Visuell und für die Performance stellt CR, ROV und TR3 eine Bereicherung dar.
Async Compute tut es auf der Performance und Programmier-Seite, was dann natürlich auch zu einem Budget führt welches man visuell investieren kann.
Auch sehr cool.

Nein, wird es nicht. Es wird einzig an Microsoft/Khronos und an den Entwicklerstudios liegen.

Eh? MS hat es spezifiziert, wie es bei Vulkan aussehen wird ist natürlich spannend.
Natürlich liegt es an den Entwicklerstudios, aber wie bei Gaming Evolved und GameWorks/The way blaba, wird der IHV durch Partnerschaften versuchen können Features in Spiele zu integrieren.
Wenn Nvidia sich also anstrengt *hust*, richtig schmiert, dann spielt es in dem ein oder anderem Spiel vielleicht eine Rolle.
Oder Nvidia macht nichts und die Entwickler machen dann auch für Jahre nichts, bis sich eine entsprechende Hardware-Basis etabliert hat.

DP FP und Integer wurde bei Kepler entfernt. Die vor allem für Spiele relevanten CUDA Kerne beherrschen also nur noch SP FP. DP und Integer wurden bei Kepler in separate CUDA Kerne ausgelagert. Daher stieg die Anzahl der Kerne auch auf das Dreifache. Aus einem SP FP, DP FP und Integer CUDA Kern wurden quasi 3 CUDA Kerne gemacht. Wie ich zuvor schon sagte, ein CUDA Kern wurde deutlich verschlankt. Das hilft die Effizienz bei spezifischen Workloads zu steigern. Man kann damit aber nicht alle Workloads effizient verarbeiten. Oder anders formuliert, Computing-Effizienz wurde für Grafikeffizienz geopfert.

Die Kerne stiegen nicht deswegen auf das dreifache an.
Der GF114 hat kein DP: SP Ratio von 1:2 wie der GF100/10 implementiert.
Der GK104 ist sogar noch um ~ 60mm² kleiner, als der GF114 und hat über 4 mal so viele ALUs.
Die DP-Logik hat in der Klasse nur einen sehr geringen Anteil vom die-size ausgemacht.
Auch beim GK110, welcher 1:3 implementiert hat, war es nicht gigantisch.

Ein Kern wurde deutlich entschlackt, ein Kern ist deutlich effizienter geworden, ein Kern ist nicht so gut beim Computing, DP hat daran aber keinen großen Anteil.
Es ist auch interessant zu lesen das DP-Math = Computing darstellt, SP-Math aber scheinbar nicht mehr dazugehört.

Ja wer denn? Wieso habe ich das Gefühl, dass du auch das nicht wirklich weisst?

Wer sollte da sonst dafür verantwortlich sein?
Und spielt das ganze eine Rolle?
Das es am PC nicht so gut funktioniert, spielt eine für AMD.

 

[WindHund]

Oh, seit John Fruehe gilt das Gesetzt das jeder AMD Mitarbeiter Unwahrheiten verbreitet.
Was stellt überhaupt noch eine legitime Quelle dar?

Okay klar, natürlich kommen Fälle vor wo nicht immer die Wahrheit gesagt wird, aber ich möchte doch lieber Anhaltspunkte wo die Wahrscheinlichkeit groß ist.
Bei VC ist sie es definitiv nicht, WhyCry schreibt sowohl unter ROVs, als auch unter CR Unsinn.
Entsprechend beurteile ich die ganze News.

AMD hat offiziell bestätigt das FL12.1 nicht unterstützt wird.
Daraus ergibt sich ein fehlendes Feature, ROVs oder CR.

DX11.2 = Tier 2
DX12 = Tier 3
Binding oder Bonding, egal Hauptsache voran!
OGL 4.3 = Vulkan
CfX FS included...

 

[BoMbY]

Habe gerade mal die Fury X mit -35% TDP getestet, also von 275 * 0,65 = 178,75. Damit komme ich immer noch auf einen FireStrike Extreme Wert von 7008. Normal war 7133, und mit der R9 290X 5118.

Edit: -36% und 1000 MHz Takt: 6869. Also wenn das hinkommt, dann dürfte die R9 Nano wirklich noch einiges an Leistung bringen.

 

[Houston2603]

Skaliert mit dem Takt (OC )wohl nicht so recht (Leistung > fiji) ... aber Stromaufnahme/abnahme hingegen schon. Die Nano wäre, wenn sie früher gekommen wäre, am besten bei dem 970-4GB-Gate wie warme Semmel weggegangen... egal. Bin auf die Nano gespannt.

 

[BoMbY]

Also das Memory-OC scheint doch zu funktionieren und was zu bringen. Insgesamt scheint das auch gar nicht schlecht zu skalieren. Mit 1103/550 MHz gegenüber 1050/500 MHz:

 

[Wu134]

Also das Memory-OC scheint doch zu funktionieren und was zu bringen. Insgesamt scheint das auch gar nicht schlecht zu skalieren. Mit 1103/550 MHz gegenüber 1050/500 MHz:

Hast du Speicher- und Chiptakt erhöht? Deine Angaben sind widersprüchlich. Der Gewinn könnte auch vom erhöhten Chiptakt kommen.

Gruß

 

[BoMbY]

Hast du Speicher- und Chiptakt erhöht? Deine Angaben sind widersprüchlich. Der Gewinn könnte auch vom erhöhten Chiptakt kommen.

Gruß

Das was ich gepostet habe, bezieht sich generell auf die Skalierung beim Übertakten, das Memory-OC war eigentlich nur ein Hinweis. Alleine 50 MHz beim Speicher bringen knapp über 2% beim 3D Mark, übertaktet man Speicher und Chip bekommt man wie oben gezeigt eine ordentliche Skalierung.