Artikel Neuer Artikel: GPGPU-Computing - ein Überblick für Anfänger und Fortgeschrittene

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.446
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=6095&w=o" border="1" alt=""></center>
Der Begriff GPGPU (General Purpose GPU) Computing - also allgemeine Aufgaben vom Grafikchip statt vom Hauptprozessor berechnen zu lassen - taucht seit einiger Zeit immer häufiger auf, sobald es um Grafikkarten geht, auch hier auf Planet 3DNow! Versprochen werden von den Herstellern Leistungssteigerungen um bis zum Faktor 10.

Wir zeigen heute auf Planet 3DNow! was GPGPU-Computing eigentlich ist, wie es funktioniert und worauf man als Programmierer achten muss. Dabei ist es uns gelungen, den vermutlich besten Mann für diese Aufgabe zu gewinnen, der momentan verfügbar ist: Gipsel, der bereits <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=2&id=1235574712">vor einigen Monaten</a> in Eigenregie einen GPU-Client für das Distributed Computing Projekt Milkyway@home entwickelt hat.

Der Artikel enthält sowohl grundlegende Betrachtungen für Einsteiger, wie auch detaillierte Struktur- und Codebetrachtungen, sodass sich auch fortgeschrittene CPU-Programmierer vermutlich nicht langweilen dürften:<blockquote><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=362621"><b>GPGPU-Computing - ein Überblick für Anfänger und Fortgeschrittene</b></a></blockquote>Viel Vergnügen beim Lesen und vielen Dank an Gipsel für die Mühe das komplexe Thema für uns "Normalsterbliche" einigermaßen verständlich aufzudröseln...
 
WOW, was für ein Text. Muss eingestehen die letzten Seiten bezüglich Programierung usw. überflogen zu haben, da das nun wirklich nicht mein Gebiet ist.

Danke für den Artikel, der andren Programmieren hoffentlich Appentit macht sich die GPU nicht nur zur Entspannung zu benutzten.

@Admins: Kann man die Artikel bzw. die Verlinkung zu diesem nicht direkt den Autoren zuordnen? Auf der HP steht "11:36 - Autor: Nero24" genauso wie hier. Ich kann ihn Gipsel aufgrund des Themas sofort zuordnen, aber andre übersehen ggf. den kleinen Text in der Ecke bzw. die Danksagung.
 
Zuletzt bearbeitet:
@Admins: Kann man die Artikel nicht direkt den Autoren zuordnen? Auf der HP steht "11:36 - Autor: Nero24" genauso wie hier. Ich kann ihn Gipsel aufgrund des Themas sofort zuordnen, aber andre übersehen ggf. den kleinen Text in der Ecke bzw. die Danksagung.
Hi,

der Artikel ist ja Gipsel zugeordnet. Siehe im Artikel:
http://www.planet3dnow.de/vbulletin/showthread.php?t=362621
oben rechts: "von Gipsel".

Auf der Newsseite sowie im Kommentare-Thread der News steht natürlich immer der Autor, der die News dazu geschrieben hat - und das war in diesem Fall ich. Alles klar? ;)
 
Ja, ist einleuchtend.

Freut mich das in letzter Zeit Artikel von Leuten aus dem Forum lesen zu können. Weiter so

TAL9000
 
Hallo

@Gipsel: Vielen Dank für den Artikel! ;D

vorweg: Ich kennen mich mit der Materie nicht besonders aus!

Die Programmierbsp. habe ich nicht ganz verstanden.
Ich dachte bisher, dass ein GPGPU-Programm aus zwei Teilen besteht, nämlich Kernel (eigentliches Programm bzw. Rechenaufgabe auf der GPU) und Host (Ablaufsteuerung, Definition der Streams, Kernel aufruft).
Wo war bei dir der Host und was ist ein Reduzierkernel?

Der Funktionswerte-Kernel wird in 6 VLIW-Instruktionen für die GPU übersetzt. Davon entfallen schon 4 auf die Bestimmung der x- und y-Werte.

Warum werden hier 4 und nicht 2 VLIW-Instruktionen benötigt? Sind das nicht jeweils nur einfache Additionen mit 1? Oder bin ich hier zu beschränkt?

Vielleicht kann mich ja jemand aufschlauen.
DANKE
 
Die Programmierbsp. habe ich nicht ganz verstanden.
Ich dachte bisher, dass ein GPGPU-Programm aus zwei Teilen besteht, nämlich Kernel (eigentliches Programm bzw. Rechenaufgabe auf der GPU) und Host (Ablaufsteuerung, Definition der Streams, Kernel aufruft).
Wo war bei dir der Host und was ist ein Reduzierkernel?
Überall wo nicht "kernel" davorsteht ist Code, der auf dem Host (CPU) ausgeführt wird. Das ist die Ablaufsteuerung (in dem einfachen Beispiel reichen wirklich die wenigen Zeilen).

Ein Reduzierkernel reduziert ganz allgemein die Größe eines Streams, d.h. der Ausgabestream ist kleiner als das was reingeht. Die Summation aller Werte ist die extremste Form davon. Ein Stream geht rein und nur ein einzelner Wert kommt raus.

Warum werden hier 4 und nicht 2 VLIW-Instruktionen benötigt? Sind das nicht jeweils nur einfache Additionen mit 1? Oder bin ich hier zu beschränkt?
Im Prinzip besitzt jeder Thread ein paar Register, in der die sogenannten Thread-IDs (oder auch Block/Wavefront-ID usw. bei Compute-Shadern) stehen. Bei einem Pixelshader sind das einfach die x-y-Koordinaten (bzw. die u-v Texturkoordinaten in einer Grafikanwendung). Genau die werden von indexof() (index als Fließkommawert) bzw. instance()-Funktionen (Rückgabe als Integerwert) zurückgegeben (bei höherdimensionalen Streams führen die auch noch die "Adress-Translation" aus und geben dann noch z- und w-Koordinaten zurück). Daß da mehr als 2 Instruktionen benötigt, liegt daran, daß die Thread-IDs in Wirklichkeit Integerwerte sind (ganze Zahlen), die dann aber als float benötigt werden (und mit indexof auch entsprechend angefordert werden). Die müssen also noch entsprechend umgewandelt werden. Da ist auch keine Rechnung dabei, das ist nur die Umwandung und dann die Zuweisung. Da muß man auch nicht den Schleifenzähler um eins erhöhen, daß ist ja gerade der Unterschied zu CPUs, daß man implizit alle Rechnungen zusammen aufruft.

Edit: Das was Dr@ direkt hierunter zitiert hat, war "work in progress" und beschreibt den Vorgang eher für Compute Shader. Dort erhält man mit instance() wirklich nur eine lineare Thread-ID und muß die x-y-Koordinaten dann selbst ausrechnen (je nach gewähltem Layout der Daten). Bei einem Pixelshader übernimmt die Hardware das Mapping (und das Memory-Tiling).
 
Zuletzt bearbeitet:
Im besitzt jeder Thread ein paar Register, in der die sogenannten Thread-IDs stehen. Aus denen kann man dann die x- und y- (potentiell noch z- und w bei höherdimesnionalen Streams) Koordinaten berechnen. Genau das machen die indexof() (index als Fließkommawert) bzw. instance()-Funktionen (Rückgabe als Integerwert). Daß das mehr als 2 Instruktionen benötigt, liegt daran, daß die Thread-IDs in Wirklichkeit Integerwerte sind (ganze Zahlen), ich die aber als float benötige. Die müßen also noch entsprechend umgewandelt werden.

OK vielen Dank!!!

Ich hatte die notwendige Datentypumwandlung vergessen und übersehen, dass die x y Werte aus den Arrayindices gewonnen werden (zu sehr aufs CPU-Bsp. fixiert löl)
 
Wie kann man denn Gipsel "danke" sagen? Per Button geht das Danke an Nero? Dann eben so: Danke Gipsel. ;)
 
Links neben einem Beitrag nes Users gibts unten in der Mitte ne kleine Wagge - damit kann man auch bewerten und da Gipsel bereits hier geantwortet hat, einfach das Antwortposting von Gipsel bewerten und damit Danke sagen ....
 
geiler artikel - nun muß ich ihn nur noch fünf mal lesen, um ihn ausreichend zu verstehen ;)

die sache mit der grafikkartenprogrammierung reizt mich so sehr, wie schon lange nichts mehr. angefixt wurde ich durch die diskussionen um gispels boinc-projekt. da ist dieser artikel genau das, was ich brauche...

D A N K E !
 
Links neben einem Beitrag nes Users gibts unten in der Mitte ne kleine Wagge - damit kann man auch bewerten und da Gipsel bereits hier geantwortet hat, einfach das Antwortposting von Gipsel bewerten und damit Danke sagen ....

Der Tipp ist gut, kam aber zu spät. ;)
 
Wow, das is ja fast schon ein P3D-Paper ;-)
 
Ich hab mich erst heute Abend hingesetzt und den Artikel aufmerksam gelesen.
Und ich muss sagen, super Arbeit Gipsel!
Es ist trotz der schwierigen Sachlage gelungen den Ablauf auch für Laien ansatzweise zu verständlich zu erläutern. Zumindest denke ich, dass ich den Unterschied nun verstanden habe ;D
 
kann mir jemand nen link geben oder sagen, welche DC projekte von einer GPU machbar wären und welche nicht?
 
Zur Zeit:
Für ATI Karten: Folding@Home und Milkyway@Home
Für NVIDIA Karten: Folding@home, Aqua@home, GPUGRID, SETI@Home und Lattice.
Für genauere Angaben, welcher kartentyp genau etc einfach mal ins DC-Unterforum reinschauen ;)
Viele weitere DC Projekte planen GPU Berechnungen demnächst auch anzubieten.
 
danke, wäre theoretisch jedes projekt mit GPU möglich?
 
danke, wäre theoretisch jedes projekt mit GPU möglich?
Nein.
Ein paar mehr wahrscheinlich schon (z.B. QMC, die SIMAP HMMR-Anwendung, Primegrid, das inzwischen eingestellte 3x+1). Allerdings ist nicht jedes Problem gleich gut dafür geeignet, so daß es bei einigen Projekten im Moment eher aussichtslos ist.
 
Warum habe ich den Artikel erst jetzt gesehen. *noahnung*

Klasse, einfach nur Klasse.
Danke!

Vielleicht wäre dieser Thread im F@H-Forum nicht uninteressant: http://foldingforum.org/viewtopic.php?f=51&t=10442&start=0
In dem Thread bei Folding hast Du es ja schon ganz richtig erkannt. Der Nachteil der ATIs dort begründet sich durch die Nichtverwendung des LocalDataShares (der funktioniert wirklich genauso wie nvidias Local Memory). Daß nur die HD4000er Serie das unterstützt ist eigentlich auch gar kein Problem. Einfach zwei Kernel schreiben (einen für HD2000 und HD3000, den anderen für HD4000er) und in Abhängigkeit des Supports von LDS dann entsprechend aufrufen.
 
Olah, super Artikel!
Bei solchen artikeln währe es jetzt noch super wnn man den noch zusätzlich auf ein Druckerfreundliches Format bringen könnte.
Oder habe ich die funktion einfach nur übersehen?

lg, braindoc
 
Olah, super Artikel!
Bei solchen artikeln währe es jetzt noch super wnn man den noch zusätzlich auf ein Druckerfreundliches Format bringen könnte.
Oder habe ich die funktion einfach nur übersehen?

lg, braindoc

Nein, diese Funktion ist leider nicht freigeschaltet, was mich auch schon bei manch längerem Artikel etwas geärgert hat...
 
Zurück
Oben Unten