Archiv verlassen und diese Seite im Standarddesign anzeigen : Auslagerung in die Shader-ALUs gut?
=Floi=
2010-02-11, 23:59:22
Hallo
bei ati wie bei nv werden immer mehr spezielle funktionen in die shader ausgelagert. (AA, teilweise tessellation etc. physx, OCL und CS sollte man auch noch dazu zählen) wie ist das zu sehen? bei ati sind die shader kein problem und auch bei nv wird man diese einheiten weiter skalieren. ich finde diese richtung ja auch besser und flexibler, aber wie sehr ihr es? Sollte man die transistoren doch lieber in fest verdrahtete einheiten stecken?
Tesseract
2010-02-12, 01:11:21
fixed functions units neigen immer dazu entweder über- oder unterfordert zu werden und genau da liegt das problem.
ich finde das gut so. so haben entwickler mehr freiräume und die auslastung sollte auch besser sein.
Naja, es kommt halt immer darauf an wie gut sich die Aufgabe über die SPs realisieren lassen. Als Beispiel seien hier mal die Videodekoder auf den aktuellen Grafikkarten erwähnt. Auf der HD2900 gab es einen Bug bei dem Dekoder, so dass die Videodekodierung über die Shader realisiert wurde, was deren Stromverbrauch extrem in die Höhe getrieben hat. Bei allen aktuellen Grafikkarte kannst du dagegen die GPU dank der festen Dekoder mit solchen Videos kaum noch aus der Ruhe bringen.
fixed functions units neigen immer dazu entweder über- oder unterfordert zu werden und genau da liegt das problem.
ich finde das gut so. so haben entwickler mehr freiräume und die auslastung sollte auch besser sein.
Jo der Vorteil ist dagegen, dass die fixed function Units die Arbeit sehr effizient verrichten, und die Shader für andere Arbeiten frei bleiben.
Was auch noch in den aktuellen Grafikchips verbaut wird, sind z.B. die Videobeschleuniger, die die ganzen Codecs entschlüsseln.
Das braucht fast keinen Strom, über die Shader wäre das ein Stromverbrauchsgrab.
Ist halt wie so häufig eine Designentscheidung mit den üblichen Vor- und Nachteilen.
Undertaker
2010-02-12, 10:55:38
Hallo
bei ati wie bei nv werden immer mehr spezielle funktionen in die shader ausgelagert. (AA, teilweise tessellation etc. physx, OCL und CS sollte man auch noch dazu zählen) wie ist das zu sehen? bei ati sind die shader kein problem und auch bei nv wird man diese einheiten weiter skalieren. ich finde diese richtung ja auch besser und flexibler, aber wie sehr ihr es? Sollte man die transistoren doch lieber in fest verdrahtete einheiten stecken?
Ein simpler Trade-off: Wiegt die höhere Performance einer FF-Einheit die die niedrigere durchschnittliche Auslastung auf? Ergo, was bringt bei gleicher Fläche und Verbrauch die höhere Leistung. Das wird sich kaum pautschal beantworten lassen - auch in Zukunft wird vieles dezidiert bleiben und anderes zusammengefasst. Müsste also am konkreten Beispiel diskutiert werden. ;)
Hallo
bei ati wie bei nv werden immer mehr spezielle funktionen in die shader ausgelagert. (AA, teilweise tessellation etc. physx, OCL und CS sollte man auch noch dazu zählen) wie ist das zu sehen? bei ati sind die shader kein problem und auch bei nv wird man diese einheiten weiter skalieren. ich finde diese richtung ja auch besser und flexibler, aber wie sehr ihr es? Sollte man die transistoren doch lieber in fest verdrahtete einheiten stecken?
Kommt schwer darauf an wie schnell die entsprechende Softwarelösung ist, wie viel Platz die FF-Unit benötigt und was Das für den Gesammtverbrauch bedeutet.
GPUs bestehen auch heute noch zu großen Teilen aus FF, da es schwer ist die Funktionen(z.B der, der TMU) performant in Software zu rechnen.
deekey777
2010-02-12, 11:22:35
Naja, es kommt halt immer darauf an wie gut sich die Aufgabe über die SPs realisieren lassen. Als Beispiel seien hier mal die Videodekoder auf den aktuellen Grafikkarten erwähnt. Auf der HD2900 gab es einen Bug bei dem Dekoder, so dass die Videodekodierung über die Shader realisiert wurde, was deren Stromverbrauch extrem in die Höhe getrieben hat. Bei allen aktuellen Grafikkarte kannst du dagegen die GPU dank der festen Dekoder mit solchen Videos kaum noch aus der Ruhe bringen.
Das kann ich aber irgendwie nicht glauben.
Die ganzen Videoprozessoren und UVDs wurde nicht deswegen in die Grafikchips integriert, weil der Stromverbrauch sonst hoch wäre, sondern darum, weil es sehr schwer ist, Shader für Videodecoding zu schreiben.
Der R600 hatte einfach kein UVD (wie der G80 keinen VP2), sondern den Videoprozessor seiner Vorgänger.
Spasstiger
2010-02-12, 12:21:52
Mein R600 beherrscht definitiv keine Videobeschleunigung von H.264 oder VC-1.
AMD ging wohl davon aus, dass sich die Käufer ohnehin nur CPUs in den Rechner stecken, die leistungsstark genug für Software-Decoding sind. :freak:
Am Threadtitel stört mich der Begriff Shader-ALUs ein wenig. Heutige Grafikkarten haben keine speziellen Shader-ALUs mehr, sondern universelle Rechenwerke. Es ist also nicht so, dass "Shader-ALUs" zweckentfremdet werden, wenn sie für Computing genutzt werden, sondern die ALUs sind für Berechnungen alller Art ausgelegt.
AnarchX
2010-02-12, 12:55:37
Mein R600 beherrscht definitiv keine Videobeschleunigung von H.264 oder VC-1.
Doch, aber nicht im vollem Umfang: http://www.computerbase.de/artikel/hardware/grafikkarten/2007/bericht_avivo_hd_purevideo_hd_vergleich/2/#abschnitt_gpubeschleunigung
Spasstiger
2010-02-12, 13:02:49
Hm, dann war ich bislang zu doof, einen passenden Player/Decoder zu finden. Ich hab fast immer über 80% CPU-Auslastung bei H.264-HD-Videos. Sowohl mit PowerDVD (GPU-Beschleunigung aktiv) als auch mit dem Media Player Classic Home Cineme (für DXVA konfiguriert).
HD-DVDs und Youtube HD @ 1080p laufen aber soweit flüssig, zumindest wenn ich den Prozessor übertaktet habe.
Das kann ich aber irgendwie nicht glauben.
Die ganzen Videoprozessoren und UVDs wurde nicht deswegen in die Grafikchips integriert, weil der Stromverbrauch sonst hoch wäre, sondern darum, weil es sehr schwer ist, Shader für Videodecoding zu schreiben.
Der R600 hatte einfach kein UVD (wie der G80 keinen VP2), sondern den Videoprozessor seiner Vorgänger.
Entschlüsselung/Dekomprimierung läuft auf dem UVD (das alleine kostet rund 40-50% der Rechenzeit), der Rest auf den ALUs, zumindest bei den Radeons ab RV6xx (Ausnahme R600).
Außer mein Gedächtnis spielt mir einen Streich. :D
RavenTS
2010-02-13, 12:49:14
Ein simpler Trade-off: Wiegt die höhere Performance einer FF-Einheit die die niedrigere durchschnittliche Auslastung auf? Ergo, was bringt bei gleicher Fläche und Verbrauch die höhere Leistung. Das wird sich kaum pautschal beantworten lassen - auch in Zukunft wird vieles dezidiert bleiben und anderes zusammengefasst. Müsste also am konkreten Beispiel diskutiert werden. ;)
Allerdings scheint der Trend ja dahin zu gehen immer mehr Aufgaben (GPU-Computing, Physik-Engines, Video-Coding, vielleicht bald Raytracing) auf die GPU zu übertragen, was dann durchaus für eine höhere Flexibilität sprechen würde...
Allerdings scheint der Trend ja dahin zu gehen immer mehr Aufgaben (GPU-Computing, Physik-Engines, Video-Coding, vielleicht bald Raytracing) auf die GPU zu übertragen, was dann durchaus für eine höhere Flexibilität sprechen würde...
Das schon. Man kann (fast) Alles in den ALUs rechnen.
Man könnte wohl einen Grafikchip bauen, der Alles in SW ausführt.
Nur wäre dieser wohl sehr langsam, da Funktionen wie z.B der Texturfilter in SW sehr langsam ist.
Man kann eigentlich nicht sagen, dass immer mehr in die Shader ausgelagert wird.
Die "Grundbausteine" der GPU sind eigentlich immer noch die gleichen FixedFunction-Einheiten. Diese werden von den Shader-ALUs (noch) nicht ersetzt sondern nur ergänzt.
Die Frage hatte doch Intel schon mit Larrabee beantwortet. Es frißt derart viel Leistung fixed function units einzusparen und in Software auszuführen, daß das schönste Chipdesign für den Popo ist.
Also es bleibt wie es ist. Es wird nur solange in SW gerechnet bis HW sich als effizienter erweist oder billiger zu produzieren ist.
Die Frage hatte doch Intel schon mit Larrabee beantwortet. Es frißt derart viel Leistung fixed function units einzusparen und in Software auszuführen, daß das schönste Chipdesign für den Popo ist.
Also es bleibt wie es ist. Es wird nur solange in SW gerechnet bis HW sich als effizienter erweist oder billiger zu produzieren ist.
Das stimmt sicher nicht.
In den letzten Jahren wurde immer mehr FF abgeschafft und Beschränkungen(VS/PS) aufgehoben.
Warum Intels Chip nicht so funktioniert wie er soll weis hier niemand und gehört bestenfalls in das Spekuforum.
Andersrum wäre der letzte Satz wohl richtig.
Das schon. Man kann (fast) Alles in den ALUs rechnen.
Streich das fast.
Spasstiger
2010-02-14, 16:01:39
Gibt es denn einen Software-Rasterizer, der auf den GPU-ALUs läuft? Für die Praxis wäre es natürlich irrelevant, aber für akademische Zwecke sicherlich sehr interessant. So könnte man z.B. abschätzen, wieviele Transistoren man zusätzlich in die universellen Rechenwerke investieren müsste, um die Fixed-Function-Hardware gleichwertig zu ersetzen.
Gibt es denn einen Software-Rasterizer, der auf den GPU-ALUs läuft? Für die Praxis wäre es natürlich irrelevant, aber für akademische Zwecke sicherlich sehr interessant. So könnte man z.B. abschätzen, wieviele Transistoren man zusätzlich in die universellen Rechenwerke investieren müsste, um die Fixed-Function-Hardware gleichwertig zu ersetzen.
Man müsste sich eher Fragen, wie es aussehen würde, wenn man das gesammte Diespace und Transistorenbudget der FF komplett in ALUs investieren würde.
Der Stronverbrauch würde natürlich ausufern, aber nur um es einmal mit Kompressorkühlung etc zum Laufen zu bringen währe schon interessant.
Ailuros
2010-02-15, 08:45:09
Gibt es denn einen Software-Rasterizer, der auf den GPU-ALUs läuft? Für die Praxis wäre es natürlich irrelevant, aber für akademische Zwecke sicherlich sehr interessant. So könnte man z.B. abschätzen, wieviele Transistoren man zusätzlich in die universellen Rechenwerke investieren müsste, um die Fixed-Function-Hardware gleichwertig zu ersetzen.
LRB; ca. 2.5Mrd. Transistoren unter 45nm mit 32 cores. 3D Leistung schaetzungsweise ~5850 Nivaeu. TMUs sind noch ff auf dem Ding.
Von dem Zeug kann man natuerlich nichts so leicht abrechnen da die eingeschaetzte 3D Leistung von LRB keineswegs nur von rasterizing abhaengig ist.
Gestohlene Formel fuer das ff vs. programmable dilemma:
It depends on what the area of a fixed-function unit is, times its (expected) utilization, vs the performance (and perhaps complexity) of not using fixed-function.
Raster units sind nach wie vor relativ klein. Deshalb sehe ich momentan keinen besonderen Grund in diesem Bereich zu sparen. Kommt IMO ein 32-core LRB an die hypothetische Tesselations-Effizienz von Fermi mit seinen 4 ff raster units ran? Ich wuerde nein sagen.
Fermi hat momentan 128SPs/GPC/raster unit. Irgendwann in der Zukunft wenn die Anzahl der GPCs und/oder die Anzahl der SPs/GPC radikal steigt koennte es durchaus Sinn machen dass noch mehr ff hw entfaellt u.a. auch die raster units. Fermi's cluster bzw. SMs sind noch nicht "unabhaengig" genu um sie als "cores" zu bezeichnen, aber unter dieser verdrehten Logik haette Fermi 16 cores.
LRB's sw rasterizer war IMHO eine zu fruehzeitige Design-Entscheidung. Hier haperte es an so manchen anderen Stellen dass man das bisschen hw fuer den raster nicht haette sparen sollen (u.a. zu schwache SIMDs, x86 Ballast, ringbus Bloedsinn etc etc.)
Ich denke AMD hätte beim rv870 schon noch ein paar Funtionen in SW ausführen können, da Sie ja fast schon traditionell ein Rechenleistungsübergewicht (relativ zu NV) haben.
Haben sie ja auch, z.B. die Parameter-Interpolation findet jetzt in den ALUs statt (wobei NVIDIA das auch macht).
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.