Die Zukunft von GPU-Compute im Desktop-Bereich - Die PCGH-Redaktionskolumne
In der allwöchentlichen Redaktions-Kolumne textet ein PCGH-Redakteur über Hardware- oder Software-Themen, die ihn in der vergangenen Woche bewegt haben. Zum Abschluss dieser Woche spricht Grafikkartenredakteur Carsten Spille über die Zukunft von GPU-Compute im Consumer- bzw. Desktopbereich.
In der allwöchentlichen Redaktions-Kolumne textet ein PCGH-Redakteur über Hardware- oder Software-Themen, die ihn in der vergangenen Woche bewegt haben. Zum Abschluss dieser Woche spricht Carsten Spille über GPU-Compute im Desktop-Bereich und über die Probleme, die sich hier offenbar auftun.
Echte Grafikprozessoren haben konventionelle Prozessoren in Sachen Rechenleistung pro Chip, pro Quadratmillimeter und pro Watt längst überholt und verbreiten sich zudem seit circa 5,5 Jahren im Desktopbereich. Doch trotz alledem sind wirklich massentaugliche Programme, welche die GPU-Rechenkraft sinnvoll nutzen, noch immer Mangelware. Nun kann man sagen, dass Nvidias Cuda-Initiative aufgrund ihrer Beschränkung auf einen GPU-Hersteller die Entwickler genauso davon abgehalten hat wie AMDs (spät erfolgter) Konter, offene Standards zu bevorzugen, welcher eher einem Lippenbekenntnis gleicht - denn offener Standard bedeutet offenbar nicht notwendigerweise, dass auch alle Plattformen mit einem passenden Treiber unterstützt werden.
Doch das wahre Problem liegt auch darin, dass GPU-Compute scheinbar im Desktop-Bereich und in Programmen, welche auch für die Masse zu Hause sinnvoll ist, nur unzureichend nutzbar ist. Denn nicht nur die Rechenkraft, sondern auch die tatsächlich erreichbare Leistung spielt eine Rolle. Ganz im Gegensatz übrigens zum Supercomputer-Bereich oder in Workstations, wo entsprechend angepasste Programme, die durch GPUs eine Beschleunigung um eine oder mehrere Größenordnungen erfahren, schon lange verbreitet sind.
Wie schon des öfteren in PCGH getestet, kommt bei Videoumwandlung, welche zunächst nicht wie propagiert die Shaderleistungs umsetzt, sondern offenbar Teile des Videodekoders nutzt, oder auch kürzlich beim Komprimieren mit Winzip 16.5, wo im Test trotz aller Bemühungen die Leistungsdifferenz zwischen Spitzenmodell und unterer Mittelklasse nur marginal war, nur ein Teil der Leistung überhaupt beim Anwender an. Das mag zum einen an liebloser Programmierung liegen, welche in manchen Fällen eher den Eindruck erweckt, der Software-Entwickler wolle sich lediglich Vermarktungszuschüsse der Hardware-Hersteller sichern (und sei es nur in Form kostenloser, zusätzlicher Öffentlichkeitsarbeit). Andererseits muss man aber auch konstatieren, dass eben nicht alle Problemstellungen sich (derzeit) sinnvoll mit einem Zusatzprozessor wie der GPU beschleunigen lassen. Das hat einen Grund: GPUs sind spezialisiert auf hohen parallelen Durchsatz und schwächeln daher insbesondere bei seriellen Problemen - und darauf lässt sich der Rest vom Schützenfest zurückführen. Denn um Ressourcen bestmöglich zu nutzen, müssen bei komplexen Aufgaben oft Teilberechnungen zwischen GPU und CPU hin- und hergeschoben werden, was zusätzlich Zeit kostet und sich daher erst ab einer gewissen Größenordnung an Rechenaufwand überhaupt lohnt.
Wie schon angesprochen, sind speziell dafür ausgelegte Programme durchaus in der Lage, die GPU-Rechenleistung sinnvoll umzusetzen, doch je weiter man sich dem Elektro-Großmarkt-Niveau nähert, desto weniger kommt davon beim Kunden an - oder desto größer die Einschränkungen, welche man damit in Kauf nehmen muss. Manche Adobe-Produkte gehen mit gutem Beispiel voran, allerdings vornehmlich in den teuren Versionen, die kaum ein Privatanwender benötigt und daher kauft (der augenscheinlich großen Verbreitung von Photoshop zum Trotz …). Je "privater" ein Programm wird, desto eingeschränkter sind die Möglichkeiten - hier denke ich vor allem an Video-Umwandler, die mit GPU-Beschleunigung nur wenige, eng umrissene Voreinstellungsoptionen bieten und zudem - wie auch die Beschleunigung des Web-Browsers - inzwischen von winzigen, in APUs, CPUs und GPUs integrierten Spezialschaltkreisen übernommen werden.
Ich denke, hier sind auch AMD und Nvidia gefragt um die Software-Entwickler anzustoßen und auch für den Privatbereich sinnvolle Anwendungen auf den Markt zu bringen - auch und gerade für anspruchsvolle Enthusiasten. Die Integration von DX11-Compute in einige Spiele ist, wie Nvidias Cuda-basierte Physx-Bibliothek, zwar ein Anfang, wird auf Dauer aber nicht genügen.
Bleibt Grafikchips daher entgegen der Hoffnungen von Nvidia und insbesondere AMD, welche Abseits von Steckkarten stark auf den APU-Express setzen, der Status eines unverzichtbaren Co-Prozessors auf absehbare Zeit versagt oder wird sich das Verteilungsproblem in ein paar Jahren mit zunehmender Programmierbarkeit erledigt haben? Müssen leistungsfähige Grafikprozessoren gar in die Cloud ausgelagert werden, um massentauglich zu sein? Was meinen Sie?
Redaktions-Kolumne
In der allwöchentlichen Redaktions-Kolumne textet ein PCGH-Redakteur über Hardware- oder Software-Themen, die ihn in der vergangenen Woche bewegt haben und zwar jeden Sonntag um 13:15 Uhr.

.gif)
Kann diese mit GPUs beider Hersteller arbeiten?
Wenn ja, dann sollte das doch mal umgesetzt werden.
Theoretisch ja. Praktisch ist der Treibersupport stark verbesserungswürdig.
Aber es ist trotzdem die einzige Lösung, denn für eine erfolgreiche, einheitliche Lösung müssen neben Nvidia und AMD vor allem auch Intels Grafiklösungen angesprochen werden können.
Kann diese mit GPUs beider Hersteller arbeiten?
Wenn ja, dann sollte das doch mal umgesetzt werden.
+1
ich denke, dass eine einheitliche Schnittstelle und somit ein vereinfachter Programmieraufwand wohl das beste wäre.
So krude es wohl für AMD und nVidia klingen mag, wäre es wirklich am besten, wenn sie sich bezüglich einer einheitlichen Programmiersprache zb. für Spielephysik unterhalten würden.
Verschiedene Programmiersprachen kosten eben mehr Mannstunden und genau dies möchte man ja vermeiden um die Kosten gering zu halten.
Ich denke, es wäre bestimmt möglich trotz verschiedener Architektur von AMD und nVidia eine einheitliche Schnittstelle zu entwerfen und der jeweilige Treiber übersetzt sie in den für den verwendeten Grafikchip verwertbare Befehle/Instruktionen.
mfg
Stefan