Gibt es "programmierbare" GPUs,die je nach Spiel Ressourcen an ROPs etc. verteilen?

[profdre]

Gibt es "programmierbare" GPUs,die je nach Spiel Ressourcen an ROPs etc. verteilen?

Moin,

meine Frage ist, ob moderne GPUs sich selbst durch flexible Ressourcenzuweisung der zu bewältigenden Aufgaben anpassen ? Es gibt ja deutliche Unterschiede in der Nvidia und der AMD Mikroarchitektur und diese führen bei vereinzelten Spielen auch zu deutlichen Performanceunterschieden trotz generell ähnlicher Leistungsfähigkeit. Zum Einen sind dafür Optimierungen der Engine verantwortlich, zum Anderen macht Spiel X vielleicht exzessiv Gebrauch von Tesselation, wodurch die Tesselation Engine überfordert wird. Durch einen höheren Takt der betreffenden Chipteile könnte man doch diesen Flaschenhals gezielt entschärfen? Oder ist es zu aufwändig, die einzelnen Teile des Chips unabhängig voneinander hoch- und runterzutakten? (Anderes Beispiel, die paar 100 Shadereinheiten der R9 290X gegenüber der R9 290 liefern nicht mal annähernd proportional zu ihrer Menge zusätzliche Performance, einfach weil die meisten Spiele offenbar nicht durch die Shader begrenzt werden)
Wenn es noch nicht umgesetzt wurde, wäre das doch eine Idee für deutliche Performancesteigerungen, da die GPU so besser ausgelastet werden könnte?

 

[profdre]

Keiner ne Ahnung? Dann lass ich mir das patentieren

 

[DragonTear]

Glaube du hast da ein par Denkfehler
Erstmal zur Idee, die Komponenten unabhängig von einander hoch und runter zu takten. Selbst wenn das Ginge, dadurch würden keine Flaschenhälse entschärft!
Normalerweise laufen die Komponenten ja schließlich mit maximalem Takt. D.h. es kommt nur ein Absenken von Taktraten in Frage, wenn Leistung grade mal nicht benötigt wird - das erhöht somit "nur"die Effizienz.
Soetwas in er Richtung macht tastächlich NV's Maxwell Architektur was neben dem Weglassen der DP(dual-precision)-Einheiten, ein weiterer Grund für die sehr hohe Effizienz ist.

Dein "programmierbar"-Ansatz ist keine so schlechte Idee. Es wäre schon toll wenn Komponenten sich "umwandeln" könnten, um grade das bereit zu stellen was grade gebraucht wird. Allerdings ist das in der Praxis nicht wirklich sinnvoll. Grafikkarten beziehen ihre Leistung ja grade daraus dass die Rechenprozesse fest in Transistoren gegossen sind. Im Gegensatz dazu gibt es CPUs. Diese verarbeiten einen Assemblercode und sind damit extrem vielseitig. Versuch aber mal ein Game mit einer CPU zu rendern... das geht schlichtweg nicht. Das merkt man auch wenn man sich die rohen FLOPs anschaut. Eine r9 290X schafft etwa 5600 Gigaflop. Wenn ich es noch richtig im Kopf habe, kommt ein aktueller i7 4790k nur auf etwa 250 Gigaflop. Also 1/20stel leistung trotz 1/5 so viel Transistoren.
Die Vielseitigkeit durch die benötigte Software-Zwischenschicht hat eben Nachteile.

Trotzdem, Ansätze gibt es! Intel hat mit Knights Landing eine Art "Rechenkarte" gebracht, die auf x86 Architektur wie CPUs basiert. Der Grund ist wohl, dass bei bestimmten Rechnungen mit extrem hoher Genauigkeit, diese Architektur wieder im Vorteil ist. Für Games ist das aber irrelevant.. NV hat für die Pascal Architektur im nächsten Jahr, sowas wie flexible SP(single-precision)-Einheiten versprochen, die sich bei bedarf zu DP-Einheiten zusammenlegen lassen (was nicht wirklich was richtig neues ist, denn AMD CPUs können dank der Modulbauweise (CMT), sowas ähnliches schon seit einigen Jahren).
Da DP-Leistung aber für Games kaum relevant wird, ist das wohl wieder nur dem Computingsektor vorbehalten.

 

[Phantomias88]

Asynchronous Shader sollen AMD-Grafikkarten weiter beschleunigen
Interessant an der Technik finde ich, Serielle Probleme aufteilen zu können.
Eine Tahiti hat. z.B 32 CoreUnits, eine Hawai 44 CU und eine R9 295X hat (2x44=) 88 CU.

 

[fdsonne]

Glaube du hast da ein par Denkfehler
Erstmal zur Idee, die Komponenten unabhängig von einander hoch und runter zu takten. Selbst wenn das Ginge, dadurch würden keine Flaschenhälse entschärft!
Normalerweise laufen die Komponenten ja schließlich mit maximalem Takt. D.h. es kommt nur ein Absenken von Taktraten in Frage, wenn Leistung grade mal nicht benötigt wird - das erhöht somit "nur"die Effizienz.
Soetwas in er Richtung macht tastächlich NV's Maxwell Architektur was neben dem Weglassen der DP(dual-precision)-Einheiten, ein weiterer Grund für die sehr hohe Effizienz ist.

Nicht wirklich. Im Grunde macht NV das genau so heute schon. Schimpft sich "Boost v2" und funktioniert bis auf die Tatsache, dass der Takt aller Einheiten hoch geht nach genau diesem Prinzip. Auch ist faktisch falsch, dass die Einheiten bei maximalem Takt laufen. Denn der Boost geht vom Basistakt aus, entsprechend einiger Regeln übertrifft die Karte diesen Takt allerdings um ganz paar Prozent (je nach Modell)
Ebenso ist das Konstrukt nicht wirklich was neues... Vor Kepler wurde bei NV der Shaderbereich mit einem Hotclock verstehen. Was heist, dass die Shadereinheiten einfach deutlich höher takten als der Rest. Bei Fermi war es doppelter Basistakt. Bei älteren Modellen gab es auch andere Taktverhältnise.


Im Prinzip hat man das Konstrukt wohl so wieder verworfen, weil durch den Hotclock die Effizienz geleidet hat und man nunmehr eben auf mehr Einheiten als mehr Takt setzt. Die höchsten Modelle (als OC Version) erreichten fast 2GHz Shadertakt damals mit dem G92, was schon ne Hausnummer ist/war.
Prinzipiel würde man das mit verschiedenen Taktdomains auch unterschiedlich takten können. Es gibt, soweit mein Stand dazu, sogar verschiedene Taktdomains... Allerdings hängen diese alle irgendwie miteinander zusammen, sprich ziehst du einen Wert hoch, zieht der Rest mit. Technisch wäre es aber wohl ohne viel Aufwand möglich, dort Unterschiedliche Taktraten reinzudrehen.

 

[DragonTear]

Nicht wirklich. Im Grunde macht NV das genau so heute schon. Schimpft sich "Boost v2" und funktioniert bis auf die Tatsache, dass der Takt aller Einheiten hoch geht nach genau diesem Prinzip. Auch ist faktisch falsch, dass die Einheiten bei maximalem Takt laufen. Denn der Boost geht vom Basistakt aus, entsprechend einiger Regeln übertrifft die Karte diesen Takt allerdings um ganz paar Prozent (je nach Modell)

Da hast du Recht, aber dieser "Basis Takt" ist doch nur ein willkürlich gesetzter Wert. Man kann das auch so betrachten, dass die Komponenten mit maximaler Leistung laufen könnten, aber eben der Takt gesenkt wird, um Effizienz zu erreichen.

Bei der Idee, Komponenten beliebig unterschiedlich schnell zu takten sehe ich allerdings noch ein Problem. Nämlich die Verbindung zwischen den Komponenten. Die berechneten Daten müssen von der einen Komponente zur anderen und wenn die nicht im Rhytmus takten, müsste es zu sonst vermeidbaren Wartezeiten kommen welche sich addieren, desto mehr Teile in Reihe geschaltet sind.
Deswegen müssen die Taktraten zumindest stark aufeinander abgestimmt sein.

 

[wargodofmetal]

Erstmal zur Idee, die Komponenten unabhängig von einander hoch und runter zu takten. Selbst wenn das Ginge, dadurch würden keine Flaschenhälse entschärft!

Könnte man nicht die ausgelasteten Teile dafür etwas schneller takten?

Ich denke, theoretisch wäre es möglich, ist in der Realität aber den Aufwand nicht wert. Die GPU müsste ja "live" die beste Kombination aus Takt und Wärmeentwicklung von X Komponenten ausknobeln, unter Berücksichtigung der maximalen Takte der einzelnen Komponenten, der Wärmeableitung, wechselnder Anforderungen innerhalb eines Spiels usw. Das ist nicht trivial.

Ein erster Schritt wäre, den Gesamttakt so zu regeln, dass eine Maximaltemperatur nicht überschritten wird. Auch das ist ja heute nur mit festen Abstufungen möglich.

 

[profdre]

Im Prinzip hat man das Konstrukt wohl so wieder verworfen, weil durch den Hotclock die Effizienz geleidet hat und man nunmehr eben auf mehr Einheiten als mehr Takt setzt. Die höchsten Modelle (als OC Version) erreichten fast 2GHz Shadertakt damals mit dem G92, was schon ne Hausnummer ist/war.
Prinzipiel würde man das mit verschiedenen Taktdomains auch unterschiedlich takten können. Es gibt, soweit mein Stand dazu, sogar verschiedene Taktdomains... Allerdings hängen diese alle irgendwie miteinander zusammen, sprich ziehst du einen Wert hoch, zieht der Rest mit. Technisch wäre es aber wohl ohne viel Aufwand möglich, dort Unterschiedliche Taktraten reinzudrehen.

Bezüglich Effizienzproblem meine ich auch gelesen zu haben, dass für derart hohe Shadertakte ein etwas anderer Fertigungsprozess (gibt ja z.B. den high performance Prozess) benötigt wurde und dieser halt von Haus aus eher auf Performance als auf Effizienz ausgelegt ist. Früher war aber die Fertigung so grob, dass man halt eher das Problem hatte, nicht genug Transistoren selbst auf dem größten Die unterzubringen, deswegen hatte sich Nvidia wohl für weniger Transistoren mit höherem Takt entschieden.

- - - Updated - - -

Könnte man nicht die ausgelasteten Teile dafür etwas schneller takten?

Ich denke, theoretisch wäre es möglich, ist in der Realität aber den Aufwand nicht wert. Die GPU müsste ja "live" die beste Kombination aus Takt und Wärmeentwicklung von X Komponenten ausknobeln, unter Berücksichtigung der maximalen Takte der einzelnen Komponenten, der Wärmeableitung, wechselnder Anforderungen innerhalb eines Spiels usw. Das ist nicht trivial.

Ein erster Schritt wäre, den Gesamttakt so zu regeln, dass eine Maximaltemperatur nicht überschritten wird. Auch das ist ja heute nur mit festen Abstufungen möglich.

Den letzten Satz verstehe ich nicht ganz. Es gibt doch bereits Targettemperaturen im grünen und roten Lager? Was genau meinst du mit festen Abstufungen? Den GPU-Takt? Der wird doch schon immer feiner gestuft?
Zu der "Live-Ausknobelung": Das sollte schon gehen, Intel schafft es ja auch sein TDP-Limit bei gleichzeitiger GPU und CPU-Auslastung einzuhalten und dabei ständig die Takte unabhängig voneinander je nach Auslastung anzupassen. Das müsste dann doch auch im Detail gehen, für jede spezielle Einheit der GPU separat. Wenn die Auslastung einer Einheit einen Grenzwert überschreitet, dann wird diese übertaktet, wenn die Auslastung gering ist, dann wird diese Einheit auf Diät gesetzt und bietet den restlichen Einheiten Temperatur- und Taktspielraum

 

[Tzk]

Das gibt dann wohl massive Probleme mit dem Sheduler, der den einzelnen Shadercores die Arbeit zuweist. Das ganze ist doch immer eine Kosten/Nutzen Sache.
Ich glaube kaum, dass sich eine solch aufwändige Regelung durch den Nutzen (mehr Eff. oder Leistung) rechtfertigen lässt. Das ist zugleich auch der Grund, warum man noch nicht so regelt.

Damals(tm) wurden eher hohe Takte bevorzugt, weil 1. viele Transistoren = viel Ausschuss bedeutet haben, 2. die Signalwege aufgrund der groben Fertigung zu lang wurden und 3. es einfach wirtschaftlicher war hoch zu takten statt breit zu bauen.

 

[fdsonne]

Bezüglich Effizienzproblem meine ich auch gelesen zu haben, dass für derart hohe Shadertakte ein etwas anderer Fertigungsprozess (gibt ja z.B. den high performance Prozess) benötigt wurde und dieser halt von Haus aus eher auf Performance als auf Effizienz ausgelegt ist. Früher war aber die Fertigung so grob, dass man halt eher das Problem hatte, nicht genug Transistoren selbst auf dem größten Die unterzubringen, deswegen hatte sich Nvidia wohl für weniger Transistoren mit höherem Takt entschieden.

Die ALUs waren ein Stück anders... Mit dem Wegfall der HotClocks hat NV die ALUs umgebaut. Man hätte auch damals mehr ALUs verbauen können. Ach hätte man damals andere Anordnungen nutzen können (bei NV), bspw. wie es AMD tat.
Das Problem von mehr ALUs ist einfach, dass die Skalierung obenraus idR nachlässt. Das ist beim Takt, speziell wenn er auf die ganze GPU wirkt, nicht so dramatisch.

Das gibt dann wohl massive Probleme mit dem Sheduler, der den einzelnen Shadercores die Arbeit zuweist. Das ganze ist doch immer eine Kosten/Nutzen Sache.
Ich glaube kaum, dass sich eine solch aufwändige Regelung durch den Nutzen (mehr Eff. oder Leistung) rechtfertigen lässt. Das ist zugleich auch der Grund, warum man noch nicht so regelt.

Warum? Dann koppelt man einfach den Scheduler da mit an und schon kann der entsprechend so agieren, wie es die ALUs notwendig machen. Da sehe ich weniger direkt ein Problem.

Damals(tm) wurden eher hohe Takte bevorzugt, weil 1. viele Transistoren = viel Ausschuss bedeutet haben, 2. die Signalwege aufgrund der groben Fertigung zu lang wurden und 3. es einfach wirtschaftlicher war hoch zu takten statt breit zu bauen.

Auch das sehe ich nicht so, da sich die Relationen nicht wirklich geändert haben. Vor allem der Part mit den Signalwegen... Eher ist es so, dass kleinere Fertigung dort tendentiell in Relation gesehen längere Wege ausmacht, einfach weil die Teile nicht mehr direkt nebeneinander sein müssen und somit in Relation zur Transistorgröße gesehen weitere Wege für die Anbindung untereinander haben könnten.
Wirtschaftlich gesehen ist das immer so eine Sache. Hoher Transistorcount = idR niedrigere Ausbeute aufgrund von mehr möglichen Fehlern.
Die Effizienz steigt schon immer mit breiteren/mehr Einheiten als mit höherem Takt.

Ebenso ist es bspw. auffallen, dass sich die Strukturen deutlich verkleinert haben, die vGPU Spannungen aber nicht wirklich gesunken sind.
Schau doch mal die aktuellen GPUs an. Da hast du immernoch 1,15-1,2V oder noch mehr drauf. Schon den R600 damals in 2007 gabs mit 1,05V im Vollausbau in 80nm. Er war ebenso relativ groß und bot viel "Breite".
Der hohe Takt ist einfach dahingehend geschuldet, dass man das Optimum rausholen will zwischen absoluter Leistung und Effizienz. Ebenso spielt die Packdichte da mit rein...