Discussion:
Parallelisierung via GPGPU
(zu alt für eine Antwort)
mutluit
2020-03-03 12:59:53 UTC
Permalink
Kennt sich hier jemand mit GPGPU (General Purpose GPU-Programming) aus
und könnte mir Tips für den Einstieg geben?

Es geht darum, eine mathematische Aufgabe, die normal viel Zeit benötigt,
zu parallelisieren indem man man die Aufgabe auf mehrere CPU-Threads verteilt.
Jetzt bin ich auf die Idee gekommen, dass man das noch weiter parallelisieren
kann, sprich mehr Threads einsetzen könnte indem man auch die GPU heranzieht.

Leider habe ich noch Null Erfahrung mit GPU-Programmierung. Daher die Frage
in die Runde: was ist die wichtigste Kennzahl bzw. Eigenschaft bei GPUs für
diese Art von Tasks. Als Beispiel hier die Ausgabe des clinfo-Programs.
Es geht hierbei also nicht um Grafik-Programmierung, sondern um allgemeine
Integer-Berechnungen.

In wieviel zusätzliche Teile (Threads) könnte ich die Aufgabe noch unterteilen
mit dieser iGPU unten? Ist es die Angabe "Max compute units: 4" ?
(ich dachte GPUs haben viel mehr Parallel-Einheiten, so in die Tausende
gehend, hätte ich erwartet):


#######################

Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 2.0 AMD-APP (1912.5)
Platform Name: AMD Accelerated Parallel Processing
Platform Vendor: Advanced Micro Devices, Inc.
Platform Extensions: cl_khr_icd cl_amd_event_callback
cl_amd_offline_devices


Platform Name: AMD Accelerated Parallel Processing
Number of devices: 1
Device Type: CL_DEVICE_TYPE_CPU
Vendor ID: 1002h
Board name:
Max compute units: 4
Max work items dimensions: 3
Max work items[0]: 1024
Max work items[1]: 1024
Max work items[2]: 1024
Max work group size: 1024
Preferred vector width char: 16
Preferred vector width short: 8
Preferred vector width int: 4
Preferred vector width long: 2
Preferred vector width float: 8
Preferred vector width double: 4
Native vector width char: 16
Native vector width short: 8
Native vector width int: 4
Native vector width long: 2
Native vector width float: 8
Native vector width double: 4
Max clock frequency: 1845Mhz
Address bits: 64
Max memory allocation: 2147483648
Image support: Yes
Max number of images read arguments: 128
Max number of images write arguments: 64
Max image 2D width: 8192
Max image 2D height: 8192
Max image 3D width: 2048
Max image 3D height: 2048
Max image 3D depth: 2048
Max samplers within kernel: 16
Max size of kernel argument: 4096
Alignment (bits) of base address: 1024
Minimum alignment (bytes) for any datatype: 128
Single precision floating point capability
Denorms: Yes
Quiet NaNs: Yes
Round to nearest even: Yes
Round to zero: Yes
Round to +ve and infinity: Yes
IEEE754-2008 fused multiply-add: Yes
Cache type: Read/Write
Cache line size: 64
Cache size: 16384
Global memory size: 7468056576
Constant buffer size: 65536
Max number of constant args: 8
Local memory type: Global
Local memory size: 32768
Max pipe arguments: 16
Max pipe active reservations: 16
Max pipe packet size: 2147483648
Max global variable size: 1879048192
Max global variable preferred total size: 1879048192
Max read/write image args: 64
Max on device events: 0
Queue on device max size: 0
Max on device queues: 0
Queue on device preferred size: 0
SVM capabilities:
Coarse grain buffer: No
Fine grain buffer: No
Fine grain system: No
Atomics: No
Preferred platform atomic alignment: 0
Preferred global atomic alignment: 0
Preferred local atomic alignment: 0
Kernel Preferred work group size multiple: 1
Error correction support: 0
Unified memory for Host and Device: 1
Profiling timer resolution: 1
Device endianess: Little
Available: Yes
Compiler available: Yes
Execution capabilities:
Execute OpenCL kernels: Yes
Execute native function: Yes
Queue on Host properties:
Out-of-Order: No
Profiling : Yes
Queue on Device properties:
Out-of-Order: No
Profiling : No
Platform ID: 0x7f96f8adda18
Name: AMD A10-5750M APU with Radeon(tm) HD Graphics
Vendor: AuthenticAMD
Device OpenCL C version: OpenCL C 1.2
Driver version: 1912.5 (sse2,avx,fma4)
Profile: FULL_PROFILE
Version: OpenCL 1.2 AMD-APP (1912.5)
Extensions: cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics
cl_khr_int64_extended_atomics cl_khr_3d_image_writes
cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission
cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops
cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_khr_gl_event


#######################
S.a.
https://en.wikipedia.org/wiki/General-purpose_computing_on_graphics_processing_units
https://wiki.archlinux.org/index.php/GPGPU
Christian Gollwitzer
2020-03-04 08:05:49 UTC
Permalink
Post by mutluit
Kennt sich hier jemand mit GPGPU (General Purpose GPU-Programming) aus
und könnte mir Tips für den Einstieg geben?
Es geht darum, eine mathematische Aufgabe, die normal viel Zeit benötigt,
zu parallelisieren indem man man die Aufgabe auf mehrere CPU-Threads verteilt.
Jetzt bin ich auf die Idee gekommen, dass man das noch weiter
parallelisieren
kann, sprich mehr Threads einsetzen könnte indem man auch die GPU heranzieht.
Leider habe ich noch Null Erfahrung mit GPU-Programmierung.
Klingt gut. Klappt nur, wenn sich Deine Aufgabe perfekt parallelisieren
lässt, d.h. vor allem wenig lokaler Speicher ist notwendig. Je nach
Aufgabe wird die meiste Zeit auch dazu verwendet, auf den Speicher zu
warten. Bei verteilten Zugriffen sind hierbei CPUs schneller(!) bedingt
durch die Caches, bei "streaming" Zugriffen, also wenn man einen großen
Block Daten durchgeht, sind GPUs schneller, weil das GPU-RAM schneller
ist (bis 1TB/s Durchsatz)
Post by mutluit
Daher die Frage
in die Runde: was ist die wichtigste Kennzahl bzw. Eigenschaft bei GPUs für
diese Art von Tasks. Als Beispiel hier die Ausgabe des clinfo-Programs.
Es geht hierbei also nicht um Grafik-Programmierung, sondern um
allgemeine Integer-Berechnungen.
Kann man so nicht beantworten. Dazu muss man wissen, wie das Programm
auf Daten zugreift.
Post by mutluit
In wieviel zusätzliche Teile (Threads) könnte ich die Aufgabe noch
4" ?
Vergiss iGPU, das bringt nur selten was. AUßerdem liest Du den Output
Post by mutluit
  Device Type:                     CL_DEVICE_TYPE_CPU
siehst Du, dass es sich um die CPU handelt, für die der Treiber den
Output liefert. GPUs spricht man mit CL_DEVICE_TYPE_GPU an.

Ich nehme an, dass Du noch nicht den richtigen Treiber installiert hast.
Da müsste ein zweiter solcher Block für die GPU kommen, davon sehe ich
aber nix.

Zurück zur Frage, Du kannst auf einer GPU viele Tausend Threads starten,
das stimmt aber nicht mit der Anzahl Compute Units überein, weil die
nämlich auch viele arithmetische Einheiten haben können. Im Endeffekt
hilft nur ausprobieren. Bei sehr kurzen Kernels lohnt es sich, im Kernel
eine for-Schleife zu machen. Zuallererst würde ich aber versuchen, pro
Rechnung genau 1 Thread zu starten.

Christian
mutluit
2020-03-04 09:11:04 UTC
Permalink
Post by mutluit
Kennt sich hier jemand mit GPGPU (General Purpose GPU-Programming) aus
und könnte mir Tips für den Einstieg geben?
Es geht darum, eine mathematische Aufgabe, die normal viel Zeit benötigt,
zu parallelisieren indem man man die Aufgabe auf mehrere CPU-Threads verteilt.
Jetzt bin ich auf die Idee gekommen, dass man das noch weiter parallelisieren
kann, sprich mehr Threads einsetzen könnte indem man auch die GPU heranzieht.
Leider habe ich noch Null Erfahrung mit GPU-Programmierung.
Klingt gut. Klappt nur, wenn sich Deine Aufgabe perfekt parallelisieren lässt,
d.h. vor allem wenig lokaler Speicher ist notwendig. Je nach Aufgabe wird die
meiste Zeit auch dazu verwendet, auf den Speicher zu warten. Bei verteilten
Zugriffen sind hierbei CPUs schneller(!) bedingt durch die Caches, bei
"streaming" Zugriffen, also wenn man einen großen Block Daten durchgeht, sind
GPUs schneller, weil das GPU-RAM schneller ist (bis 1TB/s Durchsatz)
Post by mutluit
Daher die Frage
in die Runde: was ist die wichtigste Kennzahl bzw. Eigenschaft bei GPUs für
diese Art von Tasks. Als Beispiel hier die Ausgabe des clinfo-Programs.
Es geht hierbei also nicht um Grafik-Programmierung, sondern um allgemeine
Integer-Berechnungen.
Kann man so nicht beantworten. Dazu muss man wissen, wie das Programm auf
Daten zugreift.
Daten sind fast keine da. Es soll nur in einer for-loop eine Division
mit Rest durchführen und auf Rest == 0 testen, also eine mod-Berechnung.
Alternativ eine Multiplikation und testen auf einen übergebenen Wert.
Wäre das keine gute Aufgabe zur Berechnung auf der GPU?
Post by mutluit
In wieviel zusätzliche Teile (Threads) könnte ich die Aufgabe noch
unterteilen mit dieser iGPU unten? Ist es die Angabe "Max compute units: 4" ?
Ich wollte so auf dem Laptop mit iGPU (AMD APU) erstmal Erfahrung sammeln
und wenn es tatsächlich was bringt, erst dann wollte ich eine Investition
in eine dedizierte GPU für PC machen.
Post by mutluit
Device Type: CL_DEVICE_TYPE_CPU
siehst Du, dass es sich um die CPU handelt, für die der Treiber den Output
liefert. GPUs spricht man mit CL_DEVICE_TYPE_GPU an.
Ach, stimmt, habe ich tatsächlich übersehen.
Ich nehme an, dass Du noch nicht den richtigen Treiber installiert hast. Da
müsste ein zweiter solcher Block für die GPU kommen, davon sehe ich aber nix.
Ja, verstehe ich leider auch nicht, hätte da sein müssen.
Kann man irgendwo nachschauen, ob diese iGPU von OpenCL überhaupt unterstützt
wird?

Auf diesem System (Debian Linux 8) sind folgende opencl-Sachen installiert:
$ dpkg -l | grep -i opencl
ii amd-clinfo 1:15.9-4~deb8u2
amd64 AMD OpenCL info utility
ii amd-libopencl1:amd64 1:15.12-2~bpo8+4
amd64 AMD OpenCL ICD Loader library
ii amd-opencl-dev:amd64 1:15.12-2~bpo8+4
amd64 AMD OpenCL development files
ii amd-opencl-icd:amd64 1:15.12-2~bpo8+4
amd64 non-free AMD OpenCL ICD Loaders
ii opencl-headers 2.0~svn31815-2~bpo8+1
all OpenCL (Open Computing Language) header files
Zurück zur Frage, Du kannst auf einer GPU viele Tausend Threads starten, das
stimmt aber nicht mit der Anzahl Compute Units überein, weil die nämlich auch
viele arithmetische Einheiten haben können. Im Endeffekt hilft nur
ausprobieren. Bei sehr kurzen Kernels lohnt es sich, im Kernel eine
for-Schleife zu machen. Zuallererst würde ich aber versuchen, pro Rechnung
genau 1 Thread zu starten.
Wenn CL_DEVICE_TYPE_GPU geht, werde ich das natürlich testen. Aber noch klappt
es nicht.
Ich konnte jetzt folgendes Beispiel 1:1 unter Linux kompilieren:
https://github.com/arkanis/minimal-opencl-on-windows
jedoch hat es die iGPU nicht erkannt. Im Code kommt CL_DEVICE_TYPE_GPU vor.
Wenn ich das auf CL_DEVICE_TYPE_ALL abändere, dann klappt es
(gibt "hello world" aus), aber so wie es aussieht, lässt es den Code
bestimmt von der CPU ausführen, nicht von der iGPU.

Ich muss sagen dieser Bereich (GPGPU) ist echt verwirrend: laut meiner
kurzen Recherche gibt es u.a. mind. folgende Systeme: OpenCL, CUDA, SYCL, ROCm.
CUDA kommt bei mir nicht in Frage, weil das ja für NVidea-Karten ist
(hab nur AMD Radeon), und von den restlichen muss ich einen nehmen,
wo als Compiler gcc/g++ benutzt werden kann.
Sieht noch nach viel Arbeit aus, aber könnte sich am Ende lohnen.

Danke für deine Hilfe. Falls du noch mehr Tips hast, nur her damit :-)
mutluit
2020-03-04 16:00:29 UTC
Permalink
Bin jetzt nach Installation eines alternativen OpenCL-Treibers (oder API oder
Loader, oder was es auch ist :-)
etwas weitergekommen: die GPU wird jetzt korrekt erkannt.
Demnach hat das Laptop sogar eine 2. GPU (die 2., externe, hatte ich
nie gebraucht; im BIOS war es die ganze Zeit disabled):


$ lspci
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Richland [Radeon HD 8650G]
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun PRO
[Radeon HD 8570A/8570M]


Das sind die jetzt installierten Pakete:

$ dpkg -l | grep -i opencl
ii clinfo 0.0.20130513-2
amd64 Query OpenCL system information
ii libclc-amdgcn 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - amdgcn support
ii libclc-dev 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - development files
ii libclc-ptx 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - ptx support
ii libclc-r600 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - r600 support
ii mesa-opencl-icd:amd64 13.0.6-1~bpo8+1
amd64 free implementation of the OpenCL API -- ICD runtime
ii ocl-icd-libopencl1:amd64 2.2.3-1+deb8u1
amd64 Generic OpenCL ICD Loader
ii ocl-icd-opencl-dev:amd64 2.2.3-1+deb8u1
amd64 OpenCL development files
ii opencl-headers 2.0~svn31815-2~bpo8+1
all OpenCL (Open Computing Language) header files

$ dpkg -l | grep -i gpu
ii libdrm-amdgpu1:amd64 2.4.74-1~bpo8+1
amd64 Userspace interface to amdgpu-specific kernel DRM
services -- runtime
ii radeontop 0.8-1
amd64 Utility to show Radeon GPU utilization

$ dpkg -l | grep -i radeon
ii libdrm-radeon1:amd64 2.4.74-1~bpo8+1
amd64 Userspace interface to radeon-specific kernel DRM
services -- runtime
ii radeontool 1.6.3-1
amd64 utility to control ATI Radeon backlight functions on
laptops
ii radeontop 0.8-1
amd64 Utility to show Radeon GPU utilization
ii xserver-xorg-video-radeon 1:7.8.0-1~bpo8+1
amd64 X.Org X server -- AMD/ATI Radeon display driver



Eines der GPUs hat 6 Compute Units und der andere 5.
Beim ersten zeigt die Ausgabe aber merkwürdigerweise "Max clock frequency 0MHz":

$ clinfo
Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 1.1 Mesa 13.0.6
Platform Name: Clover
Platform Vendor: Mesa
Platform Extensions: cl_khr_icd


Platform Name: Clover
Number of devices: 2
Device Type: CL_DEVICE_TYPE_GPU
Device ID: 4098
Max compute units: 6
Max work items dimensions: 3
Max work items[0]: 256
Max work items[1]: 256
Max work items[2]: 256
Max work group size: 256
Preferred vector width char: 16
Preferred vector width short: 8
Preferred vector width int: 4
Preferred vector width long: 2
Preferred vector width float: 4
Preferred vector width double: 2
Native vector width char: 16
Native vector width short: 8
Native vector width int: 4
Native vector width long: 2
Native vector width float: 4
Native vector width double: 2
Max clock frequency: 0Mhz
Address bits: 32
Max memory allocation: 750002176
Image support: No
Max number of images read arguments: 32
Max number of images write arguments: 32
Max image 2D width: 5
Max image 2D height: 0
Max image 3D width: 27609160
Max image 3D height: 139941985082872
Max image 3D depth: 140727982084224
Max samplers within kernel: 16
Max size of kernel argument: 1024
Alignment (bits) of base address: 1024
Minimum alignment (bytes) for any datatype: 128
Single precision floating point capability
Denorms: No
Quiet NaNs: Yes
Round to nearest even: Yes
Round to zero: No
Round to +ve and infinity: No
IEEE754-2008 fused multiply-add: No
Cache type: None
Cache line size: 0
Cache size: 0
Global memory size: 1071431680
Constant buffer size: 750002176
Max number of constant args: 13
Local memory type: Local
Local memory size: 32768
Error correction support: 0
Unified memory for Host and Device: 1
Profiling timer resolution: 0
Device endianness: Little
Available: Yes
Compiler available: Yes
Execution capabilities:
Execute OpenCL kernels: Yes
Execute native function: No
Queue properties:
Out-of-Order: No
Profiling : Yes
Platform ID: 0x7f46c7a09c20
Name: AMD ARUBA (DRM 2.50.0 / 4.19.0-rc7-my1a+, LLVM 3.8.1)
Vendor: AMD
Device OpenCL C version: OpenCL C 1.1
Driver version: 13.0.6
Profile: FULL_PROFILE
Version: OpenCL 1.1 Mesa 13.0.6
Extensions: cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_fp64


Device Type: CL_DEVICE_TYPE_GPU
Device ID: 4098
Max compute units: 5
Max work items dimensions: 3
Max work items[0]: 256
Max work items[1]: 256
Max work items[2]: 256
Max work group size: 256
Preferred vector width char: 16
Preferred vector width short: 8
Preferred vector width int: 4
Preferred vector width long: 2
Preferred vector width float: 4
Preferred vector width double: 2
Native vector width char: 16
Native vector width short: 8
Native vector width int: 4
Native vector width long: 2
Native vector width float: 4
Native vector width double: 2
Max clock frequency: 825Mhz
Address bits: 64
Max memory allocation: 1503238553
Image support: No
Max number of images read arguments: 32
Max number of images write arguments: 32
Max image 2D width: 5
Max image 2D height: 0
Max image 3D width: 27609160
Max image 3D height: 139941985082872
Max image 3D depth: 140727982084224
Max samplers within kernel: 32
Max size of kernel argument: 1024
Alignment (bits) of base address: 1024
Minimum alignment (bytes) for any datatype: 128
Single precision floating point capability
Denorms: No
Quiet NaNs: Yes
Round to nearest even: Yes
Round to zero: No
Round to +ve and infinity: No
IEEE754-2008 fused multiply-add: No
Cache type: None
Cache line size: 0
Cache size: 0
Global memory size: 2147483648
Constant buffer size: 1503238553
Max number of constant args: 16
Local memory type: Local
Local memory size: 32768
Error correction support: 0
Unified memory for Host and Device: 1
Profiling timer resolution: 0
Device endianness: Little
Available: Yes
Compiler available: Yes
Execution capabilities:
Execute OpenCL kernels: Yes
Execute native function: No
Queue properties:
Out-of-Order: No
Profiling : Yes
Platform ID: 0x7f46c7a09c20
Name: AMD HAINAN (DRM 2.50.0 / 4.19.0-rc7-my1a+, LLVM 3.8.1)
Vendor: AMD
Device OpenCL C version: OpenCL C 1.1
Driver version: 13.0.6
Profile: FULL_PROFILE
Version: OpenCL 1.1 Mesa 13.0.6
Extensions: cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_fp64
Christian Gollwitzer
2020-03-05 08:30:13 UTC
Permalink
Post by mutluit
Bin jetzt nach Installation eines alternativen OpenCL-Treibers (oder API
oder Loader, oder was es auch ist :-)
Das ist etwas komplifiziert. Es gibt einen Treiber, der im Prinzip nur
die eigentlichen Treiber verwaltet. Dem gibt man eine .icd-Datei unter
/etc/ zum registrieren, so dass ein gegen OpenCL gelinktes Programm mit
jeder anderen GPU läuft. Unter Windows funktioniert das recht gut, da
hab ich das Binary gegen NVidia kompiliert und dann auf AMD auf einem
anderen Rechner laufen lassen, und der OpenCL-Compiler war immer schon
mit dem Grafiktreiber installiert. Unter Linux ging es nicht ohne
Gefrickel.
Post by mutluit
etwas weitergekommen: die GPU wird jetzt korrekt erkannt.
Demnach hat das Laptop sogar eine 2. GPU (die 2., externe, hatte ich
Das klingt doch schon mal gut.
Post by mutluit
$ clinfo
Number of platforms:                 1
  Platform Profile:                 FULL_PROFILE
  Platform Version:                 OpenCL 1.1 Mesa 13.0.6
Bin mir nicht ganz sicher, aber das riecht schon wieder so nach
OpenSource-Treiber. Ich habe erfolgreich OpenCL auf einer Radeon RTX480
mit guter Performance unter Linux benutzt, das hat aber nur so richtig
mit dem Closed-Source OpenCL von AMD funktioniert. Immerhin arbeitet das
seit einiger Zeit problemlos mit dem Kernel-Modul, was im Kernel mit
dabei ist. D.h. Du müsstest einen möglichst aktuellen Kernel
installieren und dann bei der Installation des AMD-Treibers kann man das
Kernel-Modul abschalten und nur den OpenCL-Teil installieren, guck mal da:

https://linuxconfig.org/install-opencl-for-the-amdgpu-open-source-drivers-on-debian-and-ubuntu

Die Version des AMDGPU-Pro muss grob zu der Kernel-Version passen, da
gab es verschiedene API-Änderungen.

Dann hast Du auch OpenCL 2.0 Unterstützung, nicht bloß 1.1. Das ganze
OpenSource-Geraffel hat außer Hängern bei mir nicht viel Output
produziert. Und meine Berechnungen waren auch eher einfach, allerdings
speicherintensiv.

Christian
Christian Gollwitzer
2020-03-05 08:34:38 UTC
Permalink
Post by Christian Gollwitzer
Bin mir nicht ganz sicher, aber das riecht schon wieder so nach
OpenSource-Treiber. Ich habe erfolgreich OpenCL auf einer Radeon RTX480
Hier steht noch eine ganz aktuelle Info vom 18.2.2020 dazu:

https://math.dartmouth.edu/~sarunas/amdgpu.html


Christian
mutluit
2020-03-05 14:01:42 UTC
Permalink
Post by Christian Gollwitzer
Post by Christian Gollwitzer
Bin mir nicht ganz sicher, aber das riecht schon wieder so nach
OpenSource-Treiber. Ich habe erfolgreich OpenCL auf einer Radeon RTX480
https://math.dartmouth.edu/~sarunas/amdgpu.html
Danke für diesen wichtigen Hinweis; das würde bei mir OpenCL 2.0 Unterstützung
ermöglichen, statt jetzt der sehr alten OpenCL 1.1 aus dem Jahre 2011.

Ich bin kein Freund von Closed-Source. Ich hatte abgewogen ob ich mir
den Closed-Source von AMDGPU-PRO antun sollte, hatte mich aber nach
reiflicher Überlegung dagegen entschieden, weil ich mein System nicht
zerschiessen wollte, da es ja tief ins System eingreift (benötigt kernel-
sourcen bzw. -headers, dkms etc.), einschliesslich des Eingriffs ins
Desktop-Systems (Xorg).

Aber mit diesen neuen Infos (und den Infos von Christian), werde ich
es mir mit AMDGPU-PRO nochmal überlegen und es wahrscheinlich doch
noch ausprobieren, da es so ja nur eine Untermenge des gesamten Pakets
zu installieren scheint, eben die Teile nur für OpenCL (nehme ich mal an :-).

Das Problem bei mir ist: Kernel ist nicht der Jüngste (4.19 vs. 5.5.7),
und OS-Version ist ebenso alt (oldstable; d.h. Debian 8), zudem noch
Debian (nicht Ubuntu); ich kann diese OS-Version leider nicht
aufgeben, wg. anderer (Wartungs-)Projekte etc.

Wie gesagt, ich werde es mal vorsichtig ausprobieren, ob ich AMDGPU-PRO
draufbekomme, wenn nicht dann auch ok; denn mit der jetzigen Lösung
mit OpenCL 1.1 müsste ich mein Problem auch testen können. Erst danach
wollte ich abwägen ob ich dieses Projekt dann auf einen dedizierten PC
auslagere, mit richtiger, starker GPU als Compute-Accelerator für die
Lösung des besagten mathematischen Problems aus dem Cryptoforschungsbereich.

Thx All!
Christian Gollwitzer
2020-03-05 15:30:48 UTC
Permalink
Post by mutluit
Post by Christian Gollwitzer
Post by Christian Gollwitzer
Bin mir nicht ganz sicher, aber das riecht schon wieder so nach
OpenSource-Treiber. Ich habe erfolgreich OpenCL auf einer Radeon RTX480
https://math.dartmouth.edu/~sarunas/amdgpu.html
Danke für diesen wichtigen Hinweis; das würde bei mir OpenCL 2.0 Unterstützung
ermöglichen, statt jetzt der sehr alten OpenCL 1.1 aus dem Jahre 2011.
Ich bin kein Freund von Closed-Source. Ich hatte abgewogen ob ich mir
den Closed-Source von AMDGPU-PRO antun sollte, hatte mich aber nach
reiflicher Überlegung dagegen entschieden
sowas hatte ich schon befürchtet, die Benutzung von dpkg deutet darauf
hin ;)
Post by mutluit
Das Problem bei mir ist: Kernel ist nicht der Jüngste (4.19 vs. 5.5.7),
könnte im Prinzip funktionieren. Bei Kernel 4.18 wurde der AMD-Treiber
in die Kernelquellen aufgenommen, 4.19 habe ich glaube ich schon mit dem
AMDGPUPRO benutzt. Du musst halt evtl. eine ältere Version installieren,
die gibts aber noch.
Post by mutluit
Wie gesagt, ich werde es mal vorsichtig ausprobieren, ob ich AMDGPU-PRO
draufbekomme, wenn nicht dann auch ok; denn mit der jetzigen Lösung
mit OpenCL 1.1 müsste ich mein Problem auch testen können.
Vielleicht. Wie gesagt, meine Erfahrungen waren da eher so "das
Mesa-Zeuch ist unbenutzbar", also nciht einfach nur ein alter Standard,
sondern es hat schlicht Müll und Abstürze produziert. Möglicherweise ist
das aber inzwischen auch besser geworden. Wenigstens da solltest Du das
aktuelle einsetzen. Es gibt auch noch "pocl", eine OpenSource
Implementation von OpenCL. Funktioniert prinzipiell, da ist die
Performance aber auch unter aller Kanone.

Christian
mutluit
2020-03-05 19:56:31 UTC
Permalink
Also, ich hab's probiert: amdgpu-pro archiv entpackt und
das Verzeichnis in apt eingetragen als lokale repository,
dann "apt update" und "apt install ..."
Die aktuellste Version (19.30, für Ubuntu) meckert wg. DRM (2.5 vorhanden, >=
3 benötigt)

Dann habe ich die ältere Version 17.40 nach dem selben Schema versucht:
damit gibt es das DRM-Problem nicht, aber es funktioniert einfach nicht :-(

Hab dann alles von AMDGPU und AMDGPU-PRO rausgeschmissen.
Jetzt habe ich wieder den alten funktionierenden Stand:
pocl bietet OpenCL 1.2 für die CPU, erkennt aber die GPUs nicht
mesa bietet OpenCL 1.1 für die GPUs, erkennt aber nicht die CPU
Aber: beides zusammen gleichzeitig funktioniert gut, und deckt somit alle
devices ab.

Das sind die finalen Pakete:

# dpkg -l | grep -i "opencl\|amdgpu\|icd"
ii clinfo 0.0.20130513-2
amd64 Query OpenCL system information
ii libclc-amdgcn 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - amdgcn support
ii libclc-dev 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - development files
ii libclc-ptx 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - ptx support
ii libclc-r600 0.2.0+git20150813-3~bpo8+1
all OpenCL C language implementation - r600 support
ii libdrm-amdgpu1:amd64 2.4.74-1~bpo8+1
amd64 Userspace interface to amdgpu-specific kernel DRM
services -- runtime
ii mesa-opencl-icd:amd64 13.0.6-1~bpo8+1
amd64 free implementation of the OpenCL API -- ICD runtime
ii ocl-icd-libopencl1:amd64 2.2.3-1+deb8u1
amd64 Generic OpenCL ICD Loader
ii opencl-headers 2.0~svn31815-2~bpo8+1
all OpenCL (Open Computing Language) header files
ii pocl-opencl-icd 0.10-10
amd64 pocl ICD


Ich belasse es jetzt mal dabei.

Also, eigentlich bin ich ein AMD-Fan, aber was AMD hier mit den Grafik-Treibern
bzw. mit OpenCL auf Linux gemacht hat, insb. wg. dem &%&$ DRM-Mist,
ist nicht zu akzeptieren. Den ganzen Closed-Source-Mist AMDGPU-PRO
sollte AMD lieber in die Tonne schmeissen. Meine Meinung.

Ok, ich mach mal jetzt an meinem eigentlichen Problem weiter... :-)
--
So long and thanks for all the fish, and for my wasted time, dear AMD :-)
Loading...