Junge, ist das ein großes Thema.
Zunächst beginne ich mit dem Offensichtlichen: Da Sie die Funktion (jede Funktion) von der CPU aufrufen, muss sie zumindest teilweise auf der CPU laufen. Die Frage ist also, wie viel Arbeit auf der CPU und wie viel auf der GPU erledigt wird.
Zweitens muss die CPU eine Kommandobeschreibung vorbereiten, damit die GPU einen Befehl ausführen kann. Die minimale Menge hier ist ein Befehlstoken, das beschreibt, was zu tun ist, sowie die Daten für die auszuführende Operation. Wie die CPU die GPU auslöst, um den Befehl auszuführen, ist auch etwas wichtig. Da die meiste Zeit dies teuer ist, macht die CPU es nicht oft, sondern bündelt Befehle in Befehlspuffern und sendet einfach einen ganzen Puffer für die GPU.
All dies zu sagen, dass die Weitergabe von Arbeit an die GPU keine freie Übung ist. Diese Kosten müssen gegen das Ausführen der Funktion auf der CPU (egal worüber wir reden) stehen.
Wenn Sie einen Schritt zurück machen, müssen Sie sich fragen, warum Sie überhaupt eine GPU benötigen. Tatsache ist, dass eine reine CPU-Implementierung die Aufgabe erfüllt (wie AshleysBrain erwähnt). Die Leistung der GPU kommt von seinem Design zu handhaben:
- spezialisierte Aufgaben (Rasterung, Blending, Texturfilterung, Blitten, ...)
- stark parallel Workloads (DeadMG wird in seiner Antwort darauf zeigt) , wenn eine CPU eher für die Arbeit mit single-threaded arbeitet.
Und das sind die Leitprinzipien zu folgen, um zu entscheiden, was in den Chip geht. Alles, was davon profitieren kann, sollte auf der GPU laufen. Alles andere sollte auf der CPU sein.
Es ist übrigens interessant. Einige Funktionen des GL (vor der Einstellung meist) sind nicht wirklich klar abgegrenzt. Display-Listen sind wahrscheinlich das beste Beispiel für eine solche Funktion. Jeder Treiber kann beliebig viel von dem Anzeigelistenstrom an die GPU (typischerweise in Form eines Befehlspuffers) für eine spätere Ausführung schieben, solange die Semantik der GL-Anzeigelisten beibehalten wird (und das ist etwas schwer von ) im Allgemeinen). Bei einigen Implementierungen wird nur eine begrenzte Teilmenge der Aufrufe in einer Anzeigeliste in ein berechnetes Format verschoben und der Rest des Befehlsstroms auf der CPU einfach wiedergegeben.
Die Auswahl ist eine andere, bei der unklar ist, ob es einen Wert für die Ausführung auf der GPU gibt.
Schließlich muss ich sagen, dass es im Allgemeinen wenig Korrelation zwischen den API-Aufrufe und der Menge der Arbeit auf der CPU oder der GPU gibt. Eine Zustandseinstellungs-API neigt dazu, nur eine Struktur irgendwo in den Treiberdaten zu modifizieren. Der Effekt ist nur sichtbar, wenn ein Draw oder ähnliches aufgerufen wird.
Ein Großteil der GL-API funktioniert so. An diesem Punkt ist die Frage, ob glEnable(GL_BLEND) auf der CPU oder GPU ausgeführt wird, ziemlich bedeutungslos. Es kommt darauf an, ob die Mischung auf der GPU stattfindet, wenn Draw aufgerufen wird. In diesem Sinne Most GL Eintrittspunkte werden überhaupt nicht beschleunigt.
Ich könnte auch ein bisschen auf Datentransfer erweitern, aber Danvil berührt es.
Ich werde mit dem kleinen "s/w Pfad" beenden. In der Vergangenheit musste der GL nach den Spezifikationen arbeiten, unabhängig davon, welche Hardware-Spezialfälle es waren.Das bedeutete, dass, wenn die h/w nicht eine bestimmte GL-Funktion behandelte, sie es emulieren oder vollständig in Software implementieren musste. Es gibt zahlreiche Fälle, aber eine, die eine Menge Leute getroffen hat, ist als GLSL auftauchte.
Da es keine praktische Möglichkeit gab, die Code-Größe eines GLSL-Shaders zu schätzen, wurde entschieden, dass der GL eine beliebige Shader-Länge als gültig annehmen sollte. Die Implikation war ziemlich klar: Entweder implementiere ich h/w, das Shader mit beliebiger Länge - die zu dieser Zeit nicht realistisch waren - implementiere oder eine s/w Shader-Emulation implementiere (oder, wie einige Hersteller es wünschten, einfach nicht konform zu sein). Also, wenn Sie diese Bedingung auf einen Fragment-Shader ausgelöst haben, war die Wahrscheinlichkeit, dass die ganze Ihres GL auf der CPU ausgeführt wurde, auch wenn Sie eine GPU-Standort Leerlauf hatte, zumindest für diese zeichnen.
Es gibt nichts zu schockieren. Sie rufen 'glTranslate' nicht für jeden Vertex oder jedes Fragment auf, und es ist sowieso nur eine Matrixmultiplikation, so dass es normalerweise keinen Leistungseinbruch gibt, wenn Sie es auf der CPU ausführen. – Thomas
@Thomas: Sie sind völlig richtig. Aber am Anfang fällt es den Leuten schwer, über die Grafik-Rendering-Pipeline nachzudenken, und wo der Vertex-Shader mit 'glTranslate()' sitzt. Nach einer Weile wird es klarer, aber am Anfang dachte ich "Oh, das muss GPU-beschleunigt werden", daher die Frage. –
Ich dachte, dass T & L für Transformation & Lighting steht, was durch die Grafikkarte beschleunigt wurde. –