Archiv verlassen und diese Seite im Standarddesign anzeigen : Multithread GPUs ATI vs. nVidia
Demirug
2005-07-22, 19:44:38
Es scheint als hatten beiden eine ähnliche Idee gahabt. Nebem der bekannten ATI Patentschrift ( http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US2005068325&F=0) gibt es inzwischen auch eine von nVidia (http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US2005138328&F=0) zu diesem Thema.
Die Pipes sind tot lang leben die Threads. ;)
dildo4u
2005-07-22, 19:46:34
Wofür macht man das eigentlich kann man das so besser vermarkten?
stav0815
2005-07-22, 20:07:30
Wofür macht man das eigentlich kann man das so besser vermarkten?
welchen Unterschied macht ne Pipe zu nem "Thread" ?
ist das neuerdings schneller ? :|
Und bekommt meine neue GPU Hyperthreading?
Und wann ersetzt meine GPU meine CPU?! :| ;(
Neomi
2005-07-22, 21:37:29
welchen Unterschied macht ne Pipe zu nem "Thread"
ist das neuerdings schneller ? :|
Und bekommt meine neue GPU Hyperthreading?
Wenn eine normale Pipeline (bzw. Quad) beispielsweise aus einer Textur sampelt, dauert es eine Weile, bis das Ergebnis da ist. In der Zeit können je nach Implementierung schonmal die nachfolgenden Instruktionen ausgeführt werden, sofern die nicht vom Ergebnis der Texturinstruktion abhängig sind. Sind sie es, ist Warten angesagt, dabei verpufft wertvolle Rechenzeit ungenutzt. Wenn die GPU aber Threads verarbeiten kann, kann in dieser Zeit ein ganz anderer Pixel (bzw. Pixelquad) zumindest schonmal teilweise verarbeitet werden. Das ist quasi dazu da, Leerlaufzeiten zu eliminieren.
Und wann ersetzt meine GPU meine CPU?! :| ;(
Niemals nicht und nimmer.
Ailuros
2005-07-23, 12:38:10
Es scheint als hatten beiden eine ähnliche Idee gahabt. Nebem der bekannten ATI Patentschrift ( http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US2005068325&F=0) gibt es inzwischen auch eine von nVidia (http://v3.espacenet.com/textdoc?DB=EPODOC&IDX=US2005138328&F=0) zu diesem Thema.
Die Pipes sind tot lang leben die Threads. ;)
Mir ist schon klar worauf Du hinauswillst ;)
Das Zeug durchzulesen wird mir nicht viel bringen, ausser dass ich wieder nur 1/10-el verstehe und mein Gehirn zum rauchen bringe....
Das NV-Patent scheint sich aber auf eine ganz bestimmte Problematik mit mehreren theads zu beziehen, oder lese ich "out of order" falsch aus dem Titel raus?
Aqualon
2005-07-23, 15:00:36
Soweit ich die Description verstehe geht es in dem Patent von Nvidia nur darum, dass Anweisungen nicht notwendigerweise sequentiell abgearbeitet werden, sondern alle erst in einem Buffer landen und der Dispatcher dann auswählt, welche Anweisung als nächstes drankommt (wenn eine abgearbeitet ist, rutscht die nächste Anweisung des jeweiligen Threads an die entsprechende Stelle im Buffer). Das komplette Patent les ich dann später, aber nette Handzeichnung am Anfang des Dokuments ;)
Aqua
Quasar
2005-07-23, 15:04:16
Das wäre bei Nvidia aus dringender nötig, als bei ATi. Und wenn sowas in ihre Pipelines integriert würde (speziell die Pixeldinger), dann würden wir uns vermutlich ziemlich umgucken. :)
ShadowXX
2005-07-23, 15:15:55
Das wäre bei Nvidia aus dringender nötig, als bei ATi. Und wenn sowas in ihre Pipelines integriert würde (speziell die Pixeldinger), dann würden wir uns vermutlich ziemlich umgucken. :)
Die Aussage passt aber nur auf das jetzige Design....die Patente werden wohl sowieso erst Anwendung in folgenden Generationen finden und dann werden die Karten wohl sowieso neu Gemischt sein.
Quasar
2005-07-23, 15:30:30
Ja sicher passt sie auf das jetzige Design - woher soll ich auch das nächste oder übernächste kennen oder gar beurteilen, was denen dann noch jeweils gut täte?
Da aber in LH anscheinend keine Trennung mehr von VS und PS vorgeschrieben ist, könnte man diese Erfindung IMO auch dazu benutzen:
a) Pixel- und Vertexthreads auf die entsprechenden, non-unified Einheiten aufzuteilen. Transparent für die API.
b) Leerlaufzeiten besonders in den Pixelpipelines vermeiden, wie sie aktuell wohl recht stark noch auftreten. Das würde die Effizienz IMO stark verbessern und Nachteile, die man sich mit der jetzigen Aufteilung der Einheiten ggü. einem echten Unified-Design einhandeln würde, vermindern helfen.
Allerdings habe ich weder alles gelesen bisher, noch all das, was ich gelesen habe, auch zu 100% verstanden.
Tigerchen
2005-07-23, 15:31:13
Schrecklich dieser Trend sich jedes Detail einzeln patentieren zu lassen.
Herrje, können die sich nicht mal Visio oder ähnliches leisten?
[COLOR="#000088"]
Schrecklich dieser Trend sich jedes Detail einzeln patentieren zu lassen.
Verstehe ich jetzt nicht ganz. Auf welcher Ebene sollte das Patent denn sein? Einen ganzen Chip zu patentieren ist IMO recht sinnlos (wenn auch informativ ;)).
GPUs waren doch schon immer multi-threaded. Auch fixed-function units sind/waren Rechenwerke, die unterschiedliche Befehle bzw. mehrere Aufgaben ausführen (und aufgrund der Latenzen der ALUs multi-threaded sind.) Was ist das Besondere/Spezielle an diesen Patenten?
Schrecklich dieser Trend sich jedes Detail einzeln patentieren zu lassen.
Patente zu schreiben bzw. lesen war schon immer Knochenarbeit. Der innovative Gehalt tendiert oft gegen Null. Patente lassen sich (soweit ich weiss) durch minimalste Abwandlungen leicht aushebeln und dienen vor allem dazu, sich bei Streitigkeiten gegenseitig verklagen zu können.
GPUs waren doch schon immer multi-threaded. Auch fixed-function units sind/waren Rechenwerke, die unterschiedliche Befehle bzw. mehrere Aufgaben ausführen (und aufgrund der Latenzen der ALUs multi-threaded sind.) Was ist das Besondere/Spezielle an diesen Patenten?
Dass die Reihenfolge der Abarbeitung der Threads dynamisch bestimmt wird.
Beispiel: Die Vertex Shader bei NVidia arbeiten AFAIK immer an drei Eckpunkten (Threads) gleichzeitig. Aber die Threads kommen immer in einer festen Reihenfolge dran, und alle nacheinander zur Abarbeitung desselben Befehls, bevor es an den nächsten geht.
Bei diesem Patent hast du nun einen Puffer, in dem die anstehenden Threads jeweils mit ihrem nächsten Befehl stehen. Eine Einheit stellt fest welche Threads bereit zur Ausführung sind und welche noch auf Ergebnisse warten. Nun wird eine Anzahl bereiter Threads ausgewählt (so viele wie Ausführungseinheiten vorhanden sind) und deren anstehende Befehle ausgeführt, während eine andere Einheit die jeweils nachfolgenden Befehle dieser Threads im Puffer "nachfüllt".
So kann es durchaus mal vorkommen, dass nicht immer nur die Threads 1 - 2 - 3 - 1 - 2 - 3 - etc. ausgeführt werden, sondern vielleicht auch mal 1 - 1 - 1 - 3 - 3 - 2 - 1 - 1 - 2 oder ähnlich. Je nach den Anforderungen der Threads und vor allem den Latenzen beim Texturfetch.
a) Pixel- und Vertexthreads auf die entsprechenden, non-unified Einheiten aufzuteilen. Transparent für die API.
ob die shader-einheiten unified sind oder nicht ist immer transparent für die API. diese bekommt nur mitgeteilt dass der chip PS und VS nach version x.x unterstützt. wie viele einheiten jetzt intern vorhanden sind und ob diese dynamisch aufgeteilst sind bzw. der eine rechenwerke vom anderen benutzen kann ist für die API irrelevant. wichtig ist nur dass er konforme shader rechnen kann, wie ist egal.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.