News Falsche Spezifikationen: Nvidia entschädigt US-Käufer der GeForce GTX 970

[Nai]

@ chatstar
Direct X 12 kennt nur unabhängige Schlangen und kein Async Compute. Die unabhängige Schlangen können aber dafür verwendet werden um Async Compute, und das schlägt unter anderem Microsoft selbst vor, auszunutzen.

 

[Traxton]

...Weil ja die Verarsche von Kunden sehr viel schlimmer ist, als das Ausbeuten und menschenverachtende Behandeln von Arbeitern. Manche Menschen haben echt die richtigen Prioritäten..

Ich habe mal geschaut wo die Chips von AMD (Polaris, 14nm GlobalFoundries) und NVidia (Pascal, 16nm TSMC) anscheinend produziert werden.

Demnach kommen die Chips von AMD aus den USA und die Chips von NVidia aus China.

Das ganze gilt unter der Annahme, dass der Wikipedia Artikel aktuell ist.
Quelle: Wiki:List of semiconductor fabrication plants
Die US Fab von TSMC kann ich ausschließen, da die "nur" bis 160nm produzieren.
Quelle: WaferTech LLC
GlobalFoundries Quelle: GlobalFoundries Manufacturing

 

[janeeisklar]

Microsofts Programming Specifications zu DX12 zeichnen ein ganz eindeutiges Bild, AC meint Parallel und sobald du mehr als nur die 3D Queue nutzt, nutzt du eben auch AC.
Wenn man es ohne AC machen will steckt man eben alles in die 3D Queue und macht es damit halt synchronous wie eben DX11.

Und natürlich ist der Programmierer (API Anwender) selbst für die Synchronität der Nebenläufigkeiten verantwortlich. -Wie bei jedem, ernst zu nehmendem, parallelen Ansatz.

Bezüglich Maxwell:
Und es ist nicht komisch das sie laufen, es ist doch vielmehr komisch wie sie laufen.

Vulkan geht ebenso von einem asynchronously queues Modell aus.

EDIT:
Natürlich geht DX12 von "unabhängigen" Queue aus, sonnst wäre parallel ja nur schwer möglich

 

[ampre]

@ Galatian
Wie bereits vorhin geschrieben: Es macht doch überhaupt keinen Sinn ein Performance Feature wie Async Compute in einen 3D-API-Standard aufzunehmen. Ein API-Standard wie DX12 schreibt nur vor, was eine bestimmte Eingabe für Ausgaben erzeugen muss. Er schreibt aber nicht vor wie eine Funktionalität von der Hardware implementiert sein muss oder wie schnell eine Funktionalität sein muss. (Anmerkung am Rande: Aus dem Grund tauchte in den OpenGL Spezifikationen bis zu OpenGL Version 3.3 nicht einmal der Begriff GPU auf) Diese Definition eines Standards geschieht einfach aus dem Grund, damit der Standard von möglichst viel Hardware auch unterstützt werden kann.

Na ja muss aber nicht gerade der Zugriff Standardisiert werden? Die software xyz schickt den Code an die GPU und die GPU muss diesen verarbeiten können. Da muss die API doch auch wissen wie es abgearbeitet wird?

Ergänzung (29. Juli 2016)

1. Aus dem Grund kann eine Anwendung Async Compute auch nur implizit über mehrere unahängige Schlangen verwenden. Es gibt keinen Schalter in DX 12 um Async Compute an oder aus zu schalten. Deshalb muss eine Anwendung, sofern sie Async Compute nicht implizit verwenden will, die Befehlsordnung in den Schlangen dementsprechend umgestalten. Eben das machen die Async Compute Schalter, die es in diversen Spielen so gibt.

2. Async Compute ist kein funktionales Feature, sondern ein reines Performance Feature: Ein (korrektes) DX12 Programm liefert immer das korrekte Ergebnis, unahängig davon ob ein Performance Feature wie Async Compute vorhanden ist oder nicht. Im Gegensatz dazu ist z.B. Tessellation ein funktionales Feature: Ist es nicht vorhanden so kann die GPU diverse Shader gar nicht oder nicht korrekt ausführen. Das Programm liefert also ein anderes Ergebnis oder stürzt ab. Aus diesem Grund würde es gar keinen Sinn ergeben, ein Performance Feature wie Async Compute für DX12 GPUs vorzuschreiben.

3. NVIDIAs Treiber beherrschen den funktionalen Teil von DX 12 in dieser Hinsicht, nämlich mehrere unahängige Schlangen, weshalb NVIDIA GPUs auch den DX12 Standard erfüllen. Aus dem Grund läuft auch jedes (korrekte) DX12 Programm auf ihnen, unabhängig davon ob Async Compute unterstützt wird oder nicht.

4. Und was soll diese Emulation bzw. Software Lösung von Async Compute darstellen? Ich habe hier immer so das Gefühl, dass das andauernd in jedem Forum wiedergekaut wird, ohne dass jemand wüsste, was man sich darunter überhaupt vorstellen soll. Allein von den Begrifflichkeiten ergeben die Begriffe meines Erachtens keinen Sinn.

1.+4) Ich dachte mir die Anwendung gibt Async Compute Code aus und der Treiber wandelt per CPU diese dann in seriellen Code um weil Nvidia dies besser beherrscht. Deshalb auch das Wort das Async nur Emuliert wird

2.) Natürlich ist es nur ein Performance Feature. Aber solche Feautre sparen Chipfläche und steigern gleichzeitig die Leistung und Chipfläche ist zur zeit sehr rar.

3.) Beherrschen Ja. Aber halt nicht in Hardware. Hier muss wohl die CPU die Arbeit machen. Was bringt mir ein Performance Feature wenn es keine Performance bringt weil es von einer Lahmen Komponente erledigt wird.

 

[Nai]

@ janeeisklar
Wie bereits erwähnt, es gibt keine öffentliche DX 12 Spezifikationen, sondern nur die DX 12 Reference und den DX 12 Programming Guide. Und im Programming Guide beschreibt Microsoft selbst, wie ein Programmierer über die unabhängigen Schlangen Async Compute, sofern vorhanden, verwenden kann:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn899217(v=vs.85).aspx
Dass Async Compute eine Voraussetzung für eine DX 12 Support ist, steht aber nirgendwo.

Auch taucht Async Compute nirgendwo in der Vulkan Spec auf, sondern nur folgendes:
"Queue operations on different queues have no implicit ordering constraints, and may execute in any order. Explicit ordering constraints between queues can be expressed with semaphores and fences."
Dementsprechend ist Async Compute auch keine Voraussetzung für den Vulkan Support.

Und es ist nicht komisch das sie laufen, es ist doch vielmehr komisch wie sie laufen.

Wie es läuft tut nichts für den Support zu sache, sondern nur dass es läuft.

 

[janeeisklar]

"Queue operations on different queues have no implicit ordering constraints, and may execute in any order. Explicit ordering constraints between queues can be expressed with semaphores and fences."

^^ Wilkommen in der Welt der Parallelen Programierung.
Welche "implicit ordering" und/oder "execute order" ohne "semaphores and fences" würde den nach deine Meinung für ein `paralleles Model sprechen?

 

[Nai]

An so einem Lehrstuhl hocke ich gerade bereits

Es geht darum, dass die API keine Aussagen trifft wie zwei unterschiedliche Schlangen abgeabreitet werden. Angenommen es gibt zwei Schlangen A, B. Dann kann es zum Beispiel folgende Reihenfolge bei der Abarbeitung der Befehle geben:
A,A,A,A,B,B,B,B (Ein Beispiel dafür was eine GPU ohne Async Compute macht)
B,A,B,A,A,B,B,A (Ein Beispiel dafür was eine GPU mit Async Compute macht)
B,B,B,B,A,A,A,A
All das ist laut API zulässig, weshalb es eine Implementierung auch so machen darf.

 

[janeeisklar]

...
Es geht darum, dass die API keine Aussagen trifft wie zwei unterschiedliche Schlangen abgeabreitet werden.
...

Doch macht sie: asynchronously wenn du mehr als die 3D Queue benutzt.
Und wenn du es synchronous haben willst, dann nutz nur eine Queue und zwar die 3D Queue.

Aber nochmal: Welche "implicit ordering" und/oder "execute order" ohne "semaphores and fences" würde den nach deiner Meinung für ein "paralleles" Model sprechen?

 

[Nai]

@ janeeisklar
Aus dem Zitat folgt, dass eine Implementierung der API unterschiedliche Schlangen außerhalb der Synchronisation in belieibiger Reihenfolge abarbeiten darf. Dabei spielt keine Rolle für den API Support, ob die Schlangen parallel oder sequentiell abgearbeitet werden, also ob Async Compute unterstützt wird oder nicht. Und um das Beispiel von vorhin nocheinmal anzuführen: Das ganze verhält sich ziemlich ähnlich zu mehreren Threads auf einer Einkern CPU. Ein Programm kann mehrere Threads selbst auf einer Einkern CPU verwenden. Die Threads werden nicht wirklich parallel, sondern je nachdem wie das OS sie schedult, in nicht näher definierter Reihenfolge sequentiell abgearbeitet. Einen Performance Vorteil wird man hier von mehreren Threads idr nicht haben. Dennoch unterstützt eine Einkern CPU (über das OS) sämtliche Thread Bilbiotheken, wie PThreads, Windows Threads, oder C++ Threads.

 

[Ganzir]

Ein Fehlereingeständnis habe es seitens Nvidia allerdings nicht gegeben.

War zu erwarten, dann werde ich auch weiterhin nichts mehr von denen kaufen.

 

[janeeisklar]

@ janeeisklar
Aus dem Zitat folgt, dass eine Implementierung der API unterschiedliche Schlangen außerhalb der Synchronisation in belieibiger Reihenfolge abarbeiten darf.

Anders geht es Parallel/Asynchronous ja auch nicht.

Dabei spielt keine Rolle für den API Support, ob die Schlangen parallel oder sequentiell abgearbeitet werden, also ob Async Compute unterstützt wird oder nicht. Und um das Beispiel von vorhin nocheinmal anzuführen: Das ganze verhält sich ziemlich ähnlich zu mehreren Threads auf einer Einkern CPU. Ein Programm kann mehrere Threads selbst auf einer Einkern CPU verwenden. Die Threads werden nicht wirklich parallel, sondern je nachdem wie das OS sie schedult, in nicht näher definierter Reihenfolge sequentiell abgearbeitet. Einen Performance Vorteil wird man hier von mehreren Threads idr nicht haben. Dennoch unterstützt eine Einkern CPU (über das OS) sämtliche Thread Bilbiotheken, wie PThreads, Windows Threads, oder C++ Threads.

Siehst Du, du gibts dir nun selbst die "Erklärung" warum Maxwell grundsätzlich DX12 ausführen kann. Und warum sie eher "komisch" laufen.
Dem Beispiel folgend: Die EinkernCPU sollte Nvidia aber nicht als MultiCoreCPU verkaufen.

 

[CD]

War zu erwarten, dann werde ich auch weiterhin nichts mehr von denen kaufen.

Und wenn AMD noch ne ähnliche Show abzieht dann kannst garkeine Grafikkarten mehr kaufen.

Leute, Computer sind für die meisten hier nur ein Hobby, und ein relativ günstiges obendrauf. Und es war ja auch nicht grad so als wäre ne 970 zu garnix zu gebrauchen gewesen, sondern sie war in manchen Situationen - nämlich dann wenn die ersten 3.5 GB Speicher belegt waren - langsamer als man aufgrund der Specs erwartet hat.

Am schlimmsten sind zwar die blinden Fanboys, die *nur* von Firma X kaufen, aber die Hater, die 1x vergrault wurden und nie wieder verzeihen, sind fast genauso schlimm.


Rennt einfach nicht an Tag 1 los und kauft (oder noch schlimmer: bestellt vorab) ungesehen irgendetwas. Wartet ein paar Wochen und Testberichte ab, und kauft einfach das Produkt das am besten auf eure Anforderungen passt, ganz ohne Fanboy- oder Hater-Brille.

 

[Nai]

@janeeisklar
Wie bereits gefühlte 30 mal erwähnt: API Support sagt nur aus, ob ein Programm, das die API verwendet, läuft oder nicht läuft, nichts über die Geschwindigkeit. Und eben hierum geht es ja bei unserer Diskussion, ob NVIDIA DX 12 unterstützt, was gemäß dieser Definition und weil es DX12 "grundsätzlich" ausführen kann erfüllt ist.

Analogerweiser kann man sich auch einen DX12 Softwarerenderer für eine CPU schreiben, wo nichts Hardware beschleunigt ist. Auch dieser Renderer würde komplett den DX12 Standard erfüllen, und müsste dafür nicht einmal mehr als einen Thread verwenden.

Außerdem hinkt deine Analogie: NVIDIA bewirbt mit dem Slogan DX 12 Support einen API Support, was gemäß oben tatsächlich efüllt ist, und keine Hardwareeigenschaft, wie die bestimmte Anzahl an Kernen in deiner Analogie. NVIDIAs Vorgehen wäre in diesem Fall ähnlich zu dem obigen Beispiel, wenn jemand eine Einkern CPU mit dem Slogan "unterstützt die Windows API" bewerben würde, die eben unter anderem auch Windows Threads beinhalten würde.

 

[janeeisklar]

@janeeisklar
Wie bereits gefühlte 30 mal erwähnt: API Support sagt nur aus, ob ein Programm, das die API verwendet, läuft oder nicht läuft, nichts über die Geschwindigkeit. Und eben hierum geht es ja bei unserer Diskussion, ob NVIDIA DX 12 unterstützt, was gemäß dieser Definition und weil es DX12 "grundsätzlich" ausführen kann erfüllt ist.

Ja auf einer SingelCoreCPU können nacheinander/sequentiell verschiedene Threads "laufen". Aber egal mit welcher API, es wird daraus nie eine MultiCoreCPU.

Außerdem hinkt deine Analogie: NVIDIA bewirbt mit dem Slogan DX 12 Support einen API Support, was gemäß oben tatsächlich efüllt ist, und keine Hardwareeigenschaft, wie die bestimmte Anzahl an Kernen in deiner Analogie. NVIDIAs Vorgehen wäre in diesem Fall ähnlich zu dem obigen Beispiel, wenn jemand eine Einkern CPU mit dem Slogan "unterstützt die Windows API" bewerben würde, die eben unter anderem auch Windows Threads beinhalten würde.

Ach so, dir geht es also nicht um den technischen Aspekt sondern lediglich um Nvidia ansehen. Das erklärt natürlich einiges.
Naja, für mich beschreibst du damit ziemlich genau wie Nvidia Bauernfängerei betreibt.

Edit---

Analogerweiser kann man sich auch einen DX12 Softwarerenderer für eine CPU schreiben, wo nichts Hardware beschleunigt ist. Auch dieser Renderer würde komplett den DX12 Standard erfüllen, und müsste dafür nicht einmal mehr als einen Thread verwenden.

Womit er dann, wie Maxwell, auch "komisch" laufen würde.

 

[chatstar]

Am schlimmsten sind zwar die blinden Fanboys, die *nur* von Firma X kaufen, aber die Hater, die 1x vergrault wurden und nie wieder verzeihen, sind fast genauso schlimm.

Bei NVIDIA hatr lügen aber schon System, war ja nicht das erste mal!

 

[Galatian]

@ chatstar
Direct X 12 kennt nur unabhängige Schlangen und kein Async Compute. Die unabhängige Schlangen können aber dafür verwendet werden um Async Compute, und das schlägt unter anderem Microsoft selbst vor, auszunutzen.

Vielen Dank für deine Inputs bislang Nai...ich stimme dir in einigen Posts auch überein. Allerdings ist genau der Punkt den du hier ansprichst eben NICHT durch Maxwell erfüllt. Hier aus der Hardwareluxx-Analyse:

Auch wenn GPUView zwei separate Queues andeutet (gemischt mit Direct- und Compute-Prozessen), so werden diese letztendlich in einer einzige Hardware-Queue zusammengeführt

Es bleibt dabei: die Art und Weise wie Maxwell (nur per Treiber) mit Asynchronous Compute umgeht bleibt schlampig und eher ein Gimmick um zu sagen "me too!". Damit zu werben finde ich falsch. Das wäre wie als würde ich ein Karte bauen und dir Versprechen sie macht auch deine Steuererklärung 2017 genauso gut wie die der Konkurrenz und dann stellt sich nachher raus, dass sie maximal den Steuerbescheid einlesen kann.

 

[janeeisklar]

...
3.) Beherrschen Ja. Aber halt nicht in Hardware. Hier muss wohl die CPU die Arbeit machen. Was bringt mir ein Performance Feature wenn es keine Performance bringt weil es von einer Lahmen Komponente erledigt wird.

Das ist Geil
Stell dir vor du drückst den TurboBoost und Kit macht eine fast Vollbremsung. Da meint der NvidiaTechniker: "Das Auto ist nicht explodiert also ist alles wie gewünscht ->"API konform". Hammer, einfach nur Hammer

 

[Endriel]

Und genau deshalb kann NVidia machen was sie wollen. Ist doch wurscht, welchen Mist die Abziehen, die Kunden kaufen weiterhin schön ihre Produkte.

Ja, weil es keine Alternative gibt. Und nein, komm mir nicht mit AMD, das ist noch viel größerer Schrott.

 

[chatstar]

Und nein, komm mir nicht mit AMD, das ist noch viel größerer Schrott.

Schrott ist nur diese dumme Aussage!

 

[Nai]

@ Galatian
Es ging hier aber bei meinen Argumenten nicht um den Async Compute Support bei NVIDIA an sich, sondern ob das Vorhandensein von Async Compute für einen DirectX 12 Support entscheidend ist

@ Janeeisklar

Ach so, dir geht es also nicht um den technischen Aspekt sondern lediglich um Nvidia ansehen. Das erklärt natürlich einiges.
Naja, für mich beschreibst du damit ziemlich genau wie Nvidia Bauernfängerei betreibt.

Du hast hier ins Spiel gebracht, was NVIDIA als was verkaufen darf oder was nicht. Hier habe ich nur richtig gestellt, dass dieser Support aus der Werbung gemäß der Definition des API-Supports erfüllt ist. Wenn das für dich bereits bedeutet, dass es mir lediglich um NVIDIAs Ansehen geht, dann ist die Diskussion eigentlich bereits vorbei.

Womit er dann, wie Maxwell, auch "komisch" laufen würde.

Ein Softwarerenderer verhält sich nicht "komisch", er ist nur langsamer, genauso wie eine Karte ohne Async Compute Support unter Umständen langsamer sind. Und wie bereits auch schon 100 mal gesagt: Die Geschwindigkeit und vor allem die Geschwindigkeit von diversen Features fließt nicht in den Support von einer API mit rein, unter anderem weil das zum Teil zu grotesken Situationen führen wurde. Vielleicht noch ein paar Beispiele/Gedankengänge dazu:
Wieso sollte man zum Beispiel man einer Geforce 980 GTX den DX 12 Support absprechen, nur weil sie kein Async Compute unterstützt? Weil sie deshalb in diversen Use Cases zu langsam ist? Müsste man dann nicht auch allen langsameren AMD Karten wie einer R7 250 den DX 12 Support, unabhängig davon ob sie Async Compute besitzen oder nicht, absprechen? Denn die verhalten sich ja auch "komisch", wenn sie zu langsam sind. Oder will man alternativ den DX 12 Support ausschließlich von der Async Compute Performance abhängig machen? Dann würde man in der Tat die deutlich schnellere Geforce 980 GTX vom DX 12 Support ausschließen, während die R7 250, welche trotz Async Compute deutlich langsamer wäre, weiterhin den Standard erfüllen würde. Aber was für einen Sinn hätte diese Art des künstlichen Ausschlusses einer Karte, die , obwohl sie ein bestimmtes Performance Feature nicht unterstützt, dennoch in der Regel schneller als andere Karten mit eben diesen Performance Feature ist?

Man muss aber auch nicht bei Async Compute Schluss machen, sondern kann man das mit den benötigten Performance Features bzw. der Performance von Features weiter ausbauen: Wie verhält es sich mit der Tesselation Performance von AMD Karten unter DX 11? Ist sie nicht auch zu niedrig bzw. "komisch" um die Karte mit DX11 Support zu bewerben? Und erst diese komischen Mali GPUs. Die verhalten sich auch "komisch", weil sie Tesselation komplett in Software implementieren. Besitzen die dann auch keinen DX 11 Support? Auch implementiert zum Beispiel GCN Cube maps in Software. Unterstützen GCN GPUs dann überhaupt irgendeinen DX Standard in dem Cubemaps vorgeschrieben sind? Des Weiteren kann ich mit 4 Zeilen Shadercode die Compute Performance von AMD Karten halbieren, ohne dass NVIDIA-Karten darunter merklich leiden würden. Besitzen nun AMD Karten keinen Support für APIs, wo Compute Shader vorkommen?


Ich hoffe es ist nun so langsam ersichtlich, wieso man einen API Support nicht an der Performance von einem bestimmten Feature festlegt. . . .


Vielleicht noch abschließend ein weiteres Beispiel aus der CPU Welt: Haswell CPUs unterstützen AVX 2 und damit SIMD-Gather Instruktionen. Jedoch werden diese Gather Instruktionen nur durch Microcode emuliert, und sind damit nicht viel schneller als normale skalare Ladebefehle. Sollte man nur deshalb den Haswell CPUs bereits den AVX 2 Support absprechen, obwohl er alle Programme mit AVX 2 Instruktionen ausführen kann?