News Nvidia Tesla P100: GP100 als großer Pascal soll „All In“ für HPC-Markt gehen

pipip schrieb:
Die Mixed Precision ist ja vorhanden, betrifft aber die SP zu HP. Das heißt du kannst eine 32Bit Operation oder mit der selben Einheit 2 x 16 Bit Berechnung machen. NV möchte wohl in Zukunft weiterhin die anderen Karten ohne große DP-Performance auf den Markt bringen. Dort werden die Zusatzu-Einheiten für DP wahrscheinilich einfach nicht vorhanden sein. Weitehrin wird man aber HP berechnen lassen können (außer es wird per Software oder was auch immer beschnitten).
...

Dass es bei SP-HP mixed ist, ist ja offensichtlich. Dennoch ist es genau nicht das, was ich persönlich erwartet hätte. Unter mixed precision hatte ich mir eben einen DP-SP-Mix vorgestellt und nichts neues, was man dann mit SP mixt. Aber nun gut, wenn immer alles so wäre, wie ich es erwarte, wäre es ja langweilig. :D
Dein Gedanke zur Begründung ist da sehr interessant. Ein "echter" mixed-Chip hätte zunächst ja mindestens den "Nachteil", dass man dann auf allen Karten DP-Leistung bekommt. Gut möglich, dass Nvidia einfach die Möglichkeit wollte, Customer-Karten bei der DP-Leistung zu beschneiden, damit die professionellen Anwender für DP-Power halt die teuren Tesla und Co kaufen müssen.

Nai schrieb:
Vielleicht noch ein etwas anderer Gedankengang dazu: NVIDIAs Lösung wie bei Kepler und Pascal mit speziellen Einheiten kann FP-DP und SP gleichzeitig berechnen. Mixed-Precission Lösungen wie bei AMDs GCN können entweder SP oder DP berechnen. Da in einem Programm in der Regel nie alle Befehle FP-DP sind, kann erstere Lösung unter Umständen vorteilhafter sein.

Noch ein Gedankengang: Wenn man SP und DP gleichzeitig kann, dann könnte man mit mixed-precision DP-Einheiten ja theoretisch die SP-Leistung verdreifachen (1 SP-Berechnung auf einer SP-Einheit und 2 auf einer DP-Einheit).
 
Zuletzt bearbeitet:
Geniales Teil. 4096 Bit Interface, da lachen die HPC Programmierer Herzen!
 
Für den Endkunden werden sie die DP Einheiten einfach Streichen. Damit schrumpft der Chip wieder deutlich, wird günstiger und sicher auch effizienter. Kann mir nicht vorstellen, dass der Chip so in den Endkunden markt kommt. Wobei, vielleicht ja wie bei der ersten Titan. Dann haben sie wieder ein Unterscheidungsmerkmal zwischen der Titan und den normalen Geforce Chips.

Die Taktraten sehen aber sehr lecker aus. Da wird man sich mit Custom Karten sicher den 1800mhz annähern. Bin dann mal gespannt, was AMD da nachlegt. Rein von der SP leistung wird das kein problem, selbst die Furx X liegt ja jetzt schon bei 8,6Tflops.
 
tic-tac-toe-x-o schrieb:
Wenn man mal davon ausgeht, dass die normalen Kunden den selben Chip (wahrscheinlich mit teildeaktivierte Einheiten) bekommen, dann ist das schon wichtig...

die veranstaltung hatte aber nicht den zweck, kunden abseits des hpc-marktes zu informieren.
 
ix.tank schrieb:
...Bei NV sind die Shaderprozessoren in Warps gegliedert und die haben ihren eigenen Sheduler und können unabhängige Threads ausführen und demnach auch verschiedenen Ausführungspfaden folgen und das ist seit der 8800 GTX so...

Nicht die "Shaderprozessoren" werden zu Warps zusammengefasst, sondern die die vom Programmierer vorgesehene Anzahl an Threads. Diese Warps werden dann vom Scheduler mit 3 States versehen. Das genaue Scheduling ist für die Programmierung allerdings egal, solange man die Threadzahl 32 im Kopf behält und danach seinen Code richtet (wenn es geht). Andernfalls wird der Warp nicht mehr parallel verarbeitet, sondern die Threads werden seriell verarbeitet (und das wäre schlecht)...
 
Nicht die "Shaderprozessoren" werden zu Warps zusammengefasst

Okay damit wäre bewiesen ich sollte zwischen 2 und 3 Uhr nichts mehr posten. Ich hab mich da sehr unglücklich ausgedrückt. Die einzelnen ALUs werden zu SMs (bei AMD CUs) zusammengefasst und jede CU besitzt einen eigenen Warp-Scheduler wollte ich schreiben ... habe ich aber leider nicht.

Aber jetzt doch noch mal zurück zu meiner eigentlichen Frage. Da ich die AMD-Nomenklatur nicht kannte dachte ich ja bis gestern Abend, die ACEs entsprächen den Warp-Schedulern von NV. Das ist ja offensichtlich nicht der Fall. Sie entsprechen ehr der Giga-Thread-Engine und befeuern damit die einzeln CUs. Und daraus ergibt sich meine noch offene Frage wo soll jetzt der Vorteil der ACEs (es wurde kurz ohne Begründung in den Raum geworfen sie wären schneller und flexibler, aber etwas genauer hätte ich es dann schon gerne)?

http://www.anandtech.com/show/9124/amd-dives-deep-on-asynchronous-shading

Dort steht aber zum Beispiel die Anzahl der Queues im Mixed-Mode (und auch Pure-Compute-Mode) ist bei Maxwell-2 deutlich höher als bei AMD. Ansonsten steht leider nicht viel mehr vergleichendes in dem Artikel.
 
@ix.tank
Der Hauptvorteil besteht darinnen, dass die ACEs Graphik- und Compute-Aufgaben gleichzeitig berechnen können, während die Gigathread-Engine bei Maxwell aller Wahrscheinlichkeit nach Graphik- und Compute-Aufgaben nicht gleichzeitig berechnen kann. Da bei Graphik-Aufgaben oft die Fixed-Function-Stufen der Rasterpipeline die Performance limitieren sind währenddessen die CUs auch oft schlecht ausgelastet. Dies lässt sich umgehen, indem man die ansonsten untätigen CUs in der Zwischenzeit mit Compute-Aufgaben füttert, eben wofür Async-Compute vorgesehen ist.

@Hopsekäse
Noch ein Gedankengang: Wenn man SP und DP gleichzeitig kann, dann könnte man mit mixed-precision DP-Einheiten ja theoretisch die SP-Leistung verdreifachen (1 SP-Berechnung auf einer SP-Einheit und 2 auf einer DP-Einheit).
Es wäre sicher möglich die DP-Einheiten so zu gestalten, dass sie auch SP beherrschen. Bei so einem Chipdesign gibt es im allgemeinen kein richtiges "gut" oder "schlecht", sondern eher nur ein "Dieses Design ist schlechter für Fall A dafür besser für Fall B". . . .

@pipip
Speziell was ich interessant finde, ob HP in Gaming an Relevanz gewinnen könnte und falls ja, wieso man das nicht schon früher eingeführt hat ? Wäre cool, wenn man so mehr Performance aus Karten holen könnte !
HP war nie wirklich weg. ("Farb"-)Texturen und ("Farb")-Framebuffer sind oft HP. TUs sind bei HP doppelt so schnell wie bei SP. Alternativ lassen sich zum Beispiel 3D-Modelle in HP abspeichern und beim Zeichnen wieder zu SP konvertieren. (wobei man hier eher kleine Integertypen verwendet)

Eventuell später noch mehr . . .
 
Zuletzt bearbeitet:
Der Hauptvorteil besteht darinnen, dass die ACEs Graphik- und Compute-Aufgaben gleichzeitig berechnen können, während die Gigathread-Engine bei Maxwell aller Wahrscheinlichkeit nach Graphik- und Compute-Aufgaben nicht gleichzeitig berechnen kann.

Doch kann Maxwell 2.0 (also GTX 970/980...) sogar mit deutlich mehr Queues, siehe Tabelle des Artikels den ich verlinkt habe. Daher sehe ich hier keinen Vorteil.

Und noch kurz ein Kommentar zu HP und Deep-Learning, man kann durch aus auch mit HP genau arbeiten. Ganz Trivial wäre sie einfach als 10Bit SInts zu interpretieren, aus den Bits des Exponenten kann man aber auch noch etwas herausholen, wenn man will.
 
Doch kann Maxwell 2.0 (also GTX 970/980...) sogar mit deutlich mehr Queues, siehe Tabelle des Artikels den ich verlinkt habe. Daher sehe ich hier keinen Vorteil.
Maxwell "sollte" es gemäß NVIDIAs Aussagen unterstützen - es sei nur noch nicht in den Treibern implementiert worden. Da NVIDIA es bislang nicht implementiert hat (und es meines Erachtens nicht schwierig zu implementieren sein sollte), scheint mir diese Aussage unglaubwürdig.

Kurze Frage, aber könnte man dann nicht durch die ACE wieder den CU-Units gewisse Codes zuordnen, die dann mit 64 oder 32 Bit Berechnet werden können ?
Ich habe schon verstanden, dass man das eigentlich über die Waves befüllt, aber das Async Compute ist ja quasi eine tiefere Ebene oder ?
Wie meinst du das genau?
 
Maxwell "sollte" es gemäß NVIDIAs Aussagen unterstützen - es sei nur noch nicht in den Treibern implementiert worden. Da NVIDIA es bislang nicht implementiert hat (und es meines Erachtens nicht schwierig zu implementieren sein sollte), scheint mir diese Aussage unglaubwürdig.

(Maxwell 2.0)

Mag sein, allerdings wird mir das dann doch etwas zu spekulativ :). Hab mal ein wenig gegoogelt vor einem halben Jahr gab es viele Artikel dazu aber nichts konkretes. Was ich auf die schnelle nicht gefunden habe, ist etwas aktuelles oder etwas, das bestätigt, dass es aktuell geht oder nicht geht. Hast du evtl. eine Quelle zur Hand?

Ich habe schon verstanden, dass man das eigentlich über die Waves befüllt, aber das Async Compute ist ja quasi eine tiefere Ebene oder ?

Nein die ACEs liegen vor den CUs sind also Effektiv der "oberste Hardware Scheduler".
 
Maxwell kann Graphics und Compute nicht gleichzeitig ausführen Stand jetzt. Nvidia behauptet zwar seit September, dass sie das per Treiber nachliefern aber bis jetzt kam da nix und da kommt auch nix mehr. Sie können mehrere Compute ausführen aber eben nicht Graphics und Compute.
 
Es wäre doch mal schön von den Redaktionen das Thema Asynchronous Shader nicht im Sand verlaufen zu lassen, sondern genau das jetzt persönlich vor Ort anzusprechen.
Emails kann man vielleicht ignorieren, persönliche Gesprächspartner weniger.
 
Nun Nvidia schweigt sich ja offiziell zu Async Shaders aus und versucht die Sache totzuschweigen. Dass Nvidia das per Treiber lösen muss statt mit Hardware sieht man ja schon an der Reaktion zu Ashes:

https://twitter.com/PellyNV/status/702556025816125440

Man fragt sich dabei nur, ja warum Nvidia das im Treiber nicht aktiviert :freak:
 
Nvidia hat sogar gesagt, dass es keine GeForce Karte gen wird, die auf dem gp100 basiert.
Die Stellen wohl gerade einen Chip fertig und werden den wohl irgendwann Mitte Mai Anfang Juni präsentieren.
Aber wenn der Chip noch nicht fertig ist, dann werden die wohl später ihre Karten auf dem Markt verkaufen (also verfügbar sein, kein paperlaunch) als amd. Wird interessant sich das anzuschauen.

Quelle: gamestar
 
Komisch kisser, wie erklärst du dann den Sachverhalt vom 08.03.2016
http://www.pcgameshardware.de/Direc...-Treiber-Async-Compute-Steam-Overlay-1188324/
: Wir müssen an dieser Stelle ein paar Berichtigungen und Ergänzungen am Artikel vornehmen. Zuerst einmal ist die Aussage des Oxide-Entwicklers "Kollock" nicht nur vom 15. Februar und damit veraltet, sie wurde auch bereits am 24.2. von Sean Pelletier von Nvidia widerlegt. Nvidia bietet bisher keine Unterstützung von DX12 Async Compute über den Grafikkarten-Treiber, daran hat sich bis zuletzt nichts geändert, wie eine erneute Rückfrage bei Nvidia Deutschland ergab. Die GTX-9-Serie unterstütze zwar Async Compute, das sei aber "derzeit nicht im Treiber implementiert", so Nvidia gegenüber PC Games Hardware. Sollte sich daran etwas ändern, werde man das entsprechend ankündigen.
 
Zurück
Oben