www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Ein- und Abschätzung zum Grafikkarten-CoPro-Thema


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Udo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte mir bitte jemand kurz eine Idee geben, wie man den Zeitbedarf für 
eine Berechung in einer Grafikkarte abschätzen kann, um zu sehen, wie 
sich Parallelisierung und Datenverschiebung auswirken?

Für reines C lassen sich die Zyklen ja recht gut gut schätzen, wenn man 
z.B. Laden, Elekemtarrechungen und Speichern abschätzt:

2Z Wert A aus RAM holen
1Z Wert C = A * A
2Z Wert B aus RAM holen
1Z Wert D = C + B
2Z Wert D als Ergebnis speichern

macht 8 Zyklen und somit für 768 Werte etwa 60us bei 100MHz

Für einen AVR sieht es freilich anders aus, als bei einem ARM oder DSP 
oder einer Plattform CPU, aber es wird mehr oder weniger in einer 
Schleife gerechnet und man kann es durch Variation schätzen.

Wei sieht das bei einer Grafikarte aus?

Wenn ich für 768 Werte jeweils die o.g. Formel Y(k) = A(k)*A(k) + B(k) 
rechnen will, wie lange daurt die Rechung, was ist dabei parallel und 
wie lange muss ich die Werte einladen?

Soweit ich weiss, können die Grafikchips nicht beliebige Auflösungen 
rechnen, sagen wir mal die Werte wären alle unterschiedlich und im 
Bereich von 16Bit Integer positv (0 ... 65536).

Können beim Einladen die 66MHz Bustakt angenommen werden oder kann hier 
auch parallel geladen werden, z.B: 8 Werte x 16 Bit auf 64 Bit auf 
einmal rein?  Das wären dann 768 / 4 * 2 Zyklen

Vor allem interessiert mich, wie die Parallelisierung ins Spiel kommt. 
Wenn ich die ersten Werte über den Bus geladen habe, dann könnte die 
Grafikarte ja schon losrechnen und hätte die ersten Werte schon fertig. 
Wieviele Rechnungen welcher Komplexität können da parallel ablaufen?

Aus meiner Sicht müsste sich für einen parallel abarbeitbaren Block 
sowas ergeben wie:

Elementarberechungszeit = Funktion (Formeltiefe; Formelbreite)

Sequenzialisierung =  Ganzzahl (gef. Auflösung / Grafikkartenauflösung)

Berechnungszeit je Block = Elementarberechungszeit * Sequenzialisierung

Zahl der Blöcke = Zahl der Daten / Parallelität

Zeit für alle Blöcke = Zahl der Blöcke *  Berechnungszeit je Block

Ein-ausschreibezeit =  Zahl der Daten  *  Bitbreite  /  Busbreite

Gesamtzeit = Zeit für alle Blöcke + Ein-ausschreibezeit (pipelined)

oder:

Gesamtzeit = Zeit für alle Blöcke + Zahl der Blöcke * 
Ein-ausschreibezeit (vollständig gelooped)

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Vor allem interessiert mich, wie die Parallelisierung ins Spiel kommt.
So wie du sie machst.

Autor: Udo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist natürlich eine unbefriedigende Antwort. Wie müsste man der 
Grafikkarte mitteilen, dass sie was rechnet und was hat man da zur 
Verfügung?

Gehen wir mal konkret davon aus, dass alle der 768 Kalkulationen 
unabhängig laufen können und sollen. Wieviele kann man da parallel 
reinladen?

Autor: Joerg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwo im Hinterkopf klingelt da c´t Artikel irgendwann in 2011, API 
Schnittstelle für solche Sachen von nVidia bei mir. Da stehen die Basics 
zur Grafikkartennutzung drin. Imho bekommste bei nVidia auch die API 
Doku auf der Webseite. Da es nicht meine Profession ist, hab ich den 
Artikel leider nicht geistig archiviert, war aber interessant zu lesen.

mfg
Joerg

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du 768 Cores hast, dann Alle. Aber da Sie ja Erst mal aus dem 
Hauptspeicher über den PCIe Bus muß wird hierdurch die Geschwindigkeit 
begrenzt.

Autor: Soundman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe schrieb:
> Wenn du 768 Cores hast, dann Alle.
Was meinst Du mit Cores? Irgendwo gibt es dort doch ein Limit bez. des 
Produkts aus Zahl und Grösse.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von M$ gabs da mal ne Vorstellung eines deren Software-Gurus. Ich glaube 
der Link kam hier von µC.net
Da gibts ein API, mit dem man normalen aussehenden C-Code automatisch in 
eine Variante für GPU umcompilieren lassen kann.

Zumindest war das hier schon öfters Thema. Also lesen.

Es gab auch mal ne Anfrage an den Programmierer von LTspice 
diesbezüglich obs Sinn machen würde, SPICE auf einer GPU laufen zu 
lassen. Sinngemäß war seine Antwort:
Nein, weil die FPU auf den heutigen CPUs extrem schnell ist und alles 
eher durch das I/O zeitlich begrenzt wird.
Er hat sich dafür einen internen Compiler ausgedacht, der den SPICE-Code 
auf alle Cores der CPU verteilen kann und einen Zwischencode benutzt.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Von M$ gabs da mal ne Vorstellung eines deren Software-Gurus. Ich glaube
> der Link kam hier von µC.net
> Da gibts ein API, mit dem man normalen aussehenden C-Code automatisch
> in eine Variante für GPU umcompilieren lassen kann.

http://herbsutter.com/2011/06/16/c-amp-keynote/

Guter Überblick über die verfügbaren Libraries und Sprachen
http://gpgpu.org/tag/programming-languages

> Zumindest war das hier schon öfters Thema. Also lesen.
>
> Es gab auch mal ne Anfrage an den Programmierer von LTspice
> diesbezüglich obs Sinn machen würde, SPICE auf einer GPU laufen zu
> lassen. Sinngemäß war seine Antwort:
> Nein, weil die FPU auf den heutigen CPUs extrem schnell ist und alles
> eher durch das I/O zeitlich begrenzt wird.

Extrem schnell? Momentan liegt die schnellste CPU i7 SB bei  ~100 GFlops 
(alle Cores zusammen), eine HD 7970 bei 947 GFlops (double precision) 
und 3.78 TFlops (single precision).
"Performance Comparison of Single-Precision SPICE Model-Evaluation
on FPGA, GPU, Cell, and multi-core Processors"
http://authors.library.caltech.edu/18923/1/Kapre20...
(eine 9600 GT GPU war da Faktor 3 bis 131 schneller als ein Xeon 5160)

http://www.nvidia.com/object/cuda_app_tesla.html
listet ein paar SPICE/Simulationspakete

Die Frage ist nur ab welcher Modellgröße/komplexität sich das lohnt.

Autor: Soundman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitat aus dem Vergleich FPGA, GPU und CPU:

We are able to show that we can accelerate Single-Precision
SPICE Model-Evaluation by


1- 33 when using an IBM Cell
3-131 when using the NVIDIA 9600 GT GPU
3–182 when using a Xilinx Virtex5 FPGA

compared to 3 GHz Intel Xeon 5160.

Der Virtex 6 lief auf nur 200 MHz. Allerdings kostet der auch x-mal mehr 
und frisst das dreifache an Strom.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> We are able to show that we can accelerate Single-Precision SPICE 
Model-Evaluation by ...

Natürlich haben die ihre Benchmarks mit single precision laufen lassen, 
damit das auf einer GPU gut aussieht.
Gerade bei SPICE sollte man aber mit 64bit floating point rechnen. Das 
zieht die GPU-Performance um Faktor 5 herunter. Da bleibt dann gar nicht 
mehr so viel Geschwindigkeitsvorteil, dass sich das für die Masse der 
Anwendungen lohnen würde.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da muß ich Helmut leider recht geben. Ich muß bei vielen Sims die 
Precision auch hochstellen. Soll sagen, Single-Precision lohnt nicht 
wenn dafür extra Code erstellt werden müßte.

Ich denke, der ganze GPU-Kram ist für die breite Anwendung auch noch 
nicht genug gefestigt. Wer weiß, obs das in 10 Jahren noch gibt. Ich 
kann mich noch gut an die vielen CPU/DSP-Einsteckkarten für PCs 
erinnern. Da ist doch der Run schon vorbei und es blieben allenfalls 
wenige Speziallösungen übrig - da wo es sich finanziell wirklich lohnt. 
Früher lief Elektronik-Software auf sogenannten Workstations - die 
keiner zuhause hatte.

Autor: Oli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, von denen gibt es noch reichlich, aber die sitzen in der Niesche und 
man darf annehmen, dass sie ihre Produkte soweit optimiert haben, dass 
das Preis/Leistungsverhältnis stimmt.

Die Frage ist, wie man seine Rechenkapazität erweitert, wenn man mit dem 
Prozessor am Ende ist. Entweder man nutzt eine Dual CPU oder schleift 
einen weiteren Rechner ein. Im AV-Bereich wird einfach die SW nochmal 
installiert und ber Ethernet drangekoppelt.

..oder halt eine DSP-Karte.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oli schrieb:
> Na, von denen gibt es noch reichlich, aber die sitzen in der Niesche und
> man darf annehmen, dass sie ihre Produkte soweit optimiert haben, dass
> das Preis/Leistungsverhältnis stimmt.
>

Bis die betreffende Firma dann plötzlich verschwand ;-)


> Die Frage ist, wie man seine Rechenkapazität erweitert, wenn man mit dem
> Prozessor am Ende ist. Entweder man nutzt eine Dual CPU oder schleift
> einen weiteren Rechner ein. Im AV-Bereich wird einfach die SW nochmal
> installiert und ber Ethernet drangekoppelt.

Es scheitert an der Software Verfügbarkeit bzw. dem Willen der 
Programmierer/Geldgeber.
SETI@Home ginge auch für andere Anwendungen.

Speziell für den Bereich SPICE ist eine vernünftige Auslegung der 
Simulation zielführender. Wenn man natürlich meint, man könne den AVR 
gleich mit in SPICE simulieren, wird das sicherlich scheitern oder 
zumindest sehr schwierig werden. Also Probleme möglichst kleinmaschig 
aufspalten und einzeln simulieren. Die Ergebnisse dann per Brain 
zusammenführen.


>
> ..oder halt eine DSP-Karte.

Sehe ich keine Zukunft. Sowas wird vielleicht für CTs und ähnlich 
bildgebende Sachen verwendet. Man muß den ständig steigenden Kostendruck 
in Form des PC-Preisverfalles im Auge haben.

Autor: Oli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der PC wird immer billiger? Sehe ich eigentlich nicht. Die Chips werden 
wohl etwas besser, aber der PC als solcher nicht wirklich. Ausserdem 
würde die DSP Chips ja mit billiger werden.

Autor: Udo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der PC ist genau genommen auch noch ein unterschätztes Thema, denn 
schließlich ist er ein Grössen und ein Kostenfaktor. Man rechnet ja 
gerne vor, dass bei der Nutzung eines PC keine Kosten entstünden, weil 
der ja ohnehin vorhanden ist, aber wenn eine APP ihn belegt, ist er 
rechentechnisch weg.

Wenn man da nur mal an MATLAB und Konsorten denkt.

> ..oder halt eine DSP-Karte.
Ich kenne es nur von den Audio-DSP-Plattformen: Wenn man die einmal 
konfiguriert hat, also einen Synthesizer, ein Mischpult oder einen 
Klangprozessor eingebaut hat, laufen die autark ohne Rechnerbelastung, 
weil sie ihre IOs selber treiben.

Bei den Grafikkarten kommt man meines Wissens nur über den PC an die 
Aussenwelt heran, oder kennt jemand eine Applikation, wo eine einmal 
geladene Karte selber rechnet und auch IO-Kanäle besitzt?

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Udo schrieb:
> wo eine einmal
> geladene Karte selber rechnet und auch IO-Kanäle besitzt?

Das ist wohl was für die Zukunft. Für das Treiben von IOs müssten aber 
schon FPGAs her, die die Grafik-Chips passend ansteuern. Dazu müssten 
die Hersteller die Chips aber solo liefern und ich weiss nicht, ob da 
Interesse besteht.

Ich fände die Vorstellung aber reizvoll, weil man an einen FPGA 
sicherlich gleich mehrere Grafik-Chips samt RAMs dran bekommt und 
parallel laden und entladen kann.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.