SYCL und OpenCL für AMD GPU

Oct 03 2020

Ich habe eine AMD 5700XT-GPU und versuche, SYCL zu lernen, aber ich habe viele Zweifel am aktuellen Status der AMD-GPU-Treiberstapel. Nach dem, was ich gelesen habe, gibt es mehrere Treiberstapel für AMD gpus: mesa, amdgpu und amdgpu-pro. Wenn ich das richtig verstehe, hat mesa eine eigene opencl-Implementierung und es gibt eine andere Implementierung für die amdgpu-Treiber.

Außerdem hat amd ROCm, eine andere OpenCL-Implementierung, HIP, welche so etwas wie CUDA und einige Tools, oder?

Es gibt mindestens zwei Implementierungen, ComputeCpp und hipSYCL, die möglicherweise SYCL auf AMD gpus ausführen könnten. Sollte die Clang-Implementierung nicht auch auf AMD GPUS ausgeführt werden können, da sie laut Image mit OpenCL- und SPIR-V-Geräten ausgeführt wird?

Soweit ich weiß, gibt es auch oneAPI, eine Implementierung von SYCL (DPC ++) mit einigen Erweiterungen (SYCL 2020) und einigen Bibliotheken zusätzlich zu dieser SYCL-Implementierung (Art von cuBLAS oder cuSPARSE für CUDA). Sollte es möglich sein, oneAPI-Bibliotheken auf einer anderen SYCL-Implementierung auszuführen?

Wenn ich mesa für Grafiken verwende (OpenGL und Vulkan), ist es schließlich möglich, ROCm darüber hinaus auszuführen? Wie interagieren die Implementierung von ROCm und OpenCL Mesa mit Mesa-Grafiktreibern?

Wie Sie sehen können, habe ich eine große Verwirrung über das gesamte Ökosystem. Kann jemand etwas Licht ins Dunkel bringen?

Antworten

2 illuhad Oct 06 2020 at 00:40

Mein Verständnis ist, dass es einen einzigen Kerneltreiber gibt, amdgpu. Mesa lebt im Userland und ist eine OpenGL-Implementierung. amdgpu-pro bietet alternative Closed-Source-Userland-Bibliotheken (OpenGL, OpenCL usw.).

Clover ist eine OpenCL-Implementierung auf Mesa. Ich bin mir nicht sicher, in welchem ​​Zustand es sich befindet (ich habe den Eindruck, dass es einige Zeit nicht sehr gut gewartet wurde und die Entwicklung ins Stocken geraten ist), aber ich bezweifle, dass es SYCL-Programme ausführen kann.

ROCm ist mehr als eine OpenCL-Implementierung. Es ist AMDs GPGPU-Plattform, die eine KI-Plattform, beschleunigte Bibliotheken, Tools und Compiler bietet. Es enthält auch eine OpenCL-Implementierung. HIP ist keine OpenCL-Implementierung, sondern die Implementierung des CUDA-Programmiermodells durch AMD.

Meines Wissens kann leider keine aktuelle AMD OpenCL-Implementierung SYCL-Programme ausführen, da AMD weder SPIR noch SPIR-V unterstützt. AMD OpenCL hat SPIR-V noch nie unterstützt, daher funktioniert DPC ++ / clang nicht. ComputeCpp kann auch mit SPIR arbeiten, aber die Unterstützung dafür wurde bereits vor einiger Zeit aus der OpenCL-Implementierung von AMD entfernt.

In Bezug auf die SYCL-Unterstützung für AMD ist hipSYCL normalerweise der richtige Weg. Leider unterstützt AMD Ihre spezifische GPU auf ROCm (auf der hipSYCL aufbaut) nicht, da die ROCm-Unterstützung auf Chips konzentriert ist, die auch in Rechenzentrumskarten verwendet werden. Weitere Details finden Sie hier:https://github.com/RadeonOpenCompute/ROCm#supported-gpus

oneAPI ist Intels Überbegriff für die Computerplattform, die Bibliotheken, Tools und Compiler bereitstellt (ähnlich wie ROCm). DPC ++ / LLVM SYCL / Intel SYCL ist Teil von oneAPI. Alle diese Begriffe beziehen sich auf dasselbe, nämlich die Implementierung des Khronos SYCL 2020-Standards durch Intel. Nahezu alle Erweiterungen von Intel wurden in die SYCL 2020-Spezifikation integriert. Denken Sie also nicht an DPC ++ als separate Sprache.

Es ist möglich, OneAPI-Bibliotheken zusätzliche Backends hinzuzufügen, z. B. Codeplay für NVIDIA. Grundsätzlich ist es auch möglich, sie auf eine andere SYCL-Implementierung zu portieren. Wir arbeiten an einigen Grundlagen, um mit hipSYCL möglicherweise in diese Richtung zu gehen, indem wir die Kompatibilität zwischen hipSYCL und DPC ++ verbessern:https://www.urz.uni-heidelberg.de/en/2020-09-29-oneapi-coe-urz

Es ist nicht möglich, ROCm über Mesa auszuführen. Es ist ein völlig unabhängiger Stack für GPU-Berechnungen. Soweit ich weiß, gibt es keine Wechselwirkung zwischen ROCm und Mesa.