En bättre liknelse är då kanske att CUDA och HIP förhåller sig som svenska och norska, de är tillräckligt lika för att någon som är bra på ett av dem kan förstå det andra.
Huvudproblemet jag ser med HIP, efter att läst på lite mer för att försöka hitta AMDs vision, är detta
"Is HIP a drop-in replacement for CUDA?
No. HIP provides porting tools which do most of the work to convert CUDA code into portable C++ code that uses the HIP APIs. Most developers will port their code from CUDA to HIP and then maintain the HIP version. HIP code provides the same performance as native CUDA code, plus the benefits of running on AMD platforms."
Det markerade känns som ett rätt ordentligt hinder av primärt två huvudanledningar:
1. HIP är en delmängd av CUDA, varför skulle man vilja begränsa möjligheterna på Nvidias GPUer så länge de är dominanten?
2. Även om man går till HIP går man från att endast stödja Nvidia till att nu bara stödja Nvidia och AMD.
2. kan tyckas vara ett mindre problem, men grejen är att om målet är att nå en sådan bred publik som möjligt är det ju ännu bättre att gå till SyCL p.g.a detta
https://www.khronos.org/assets/uploads/blogs/2020-05-sycl-landing-page-02.jpg
https://www.khronos.org/assets/uploads/apis/2020-05-sycl-landing-page-02b_1.jpg
SyCL och HIP ger samma sak här, en kodbas kan stödja flera "backends". SyCLs stöd är väsentligt bredare, bl.a. finns det redan två sätt att stödja AMD GPUer (ingen har tyvärr officiellt stöd från AMD):
dels via hipCYCL (som numera heter Open CYCL). Men likt många andra helt 3:e-parts drivna projekt går detta relativt långsamt.
dels via OneAPI. Precis som i HIP finns det teknik i OneAPI för att, utöver att köra på Intel HW, även köra på Nvidia GPUer. Hade missat att man numera även har stöd för AMD GPUer (via HIP som "driver-lager").
Vidare finns det även "backends" för SyCL som använder sig av OpenCL (OpenCL 3.0 är en nedskalade variant jämfört med 2.x som i praktiken helt är tänkt som "driver-lager" för t.ex. SyCL) samt Vulkan compute.
Med SyCL når man därför inte bara AMD och Nvidia GPUer, man når allt från FPGA:er (t.ex. Xilinx produkter, teknik som AMD numera äger) till alla PC GPUer och även mobil GPUer (via endera OpenCL eller Vulkan).
Binäröversättning nämns i tråden: tekniskt sett borde det vara möjligt då AMD, Nvidia, Intel, Arm och Apple alla bygger sina GPU-kompilatorer på LLVM. Rosetta 2 (x86_64->ARM64 för MacOS) och Arm64EC (x86_64->ARM64 för Win11) använder just LLVM för att översätta x86_64 till LLVM IR (IR är en form av "virtuell" maskinkod), när man har LLVM IR är det möjligt att kompilera det till alla arkitekturer som LLVM har en backend för (vilket är "typ alla").
Vulkan shaders går i praktiken alltid via SPIR-V (som kan hanteras m.h.a. LLVM IR), så steget från LLVM IR till GPU-maskinkod finns i praktiken redan hos alla GPUer som har Vulkan stöd.
Huvudproblemet är nog att det kanske inte blir så effektiv. GPUer skiljer sig mer på HW-nivå jämfört med CPUer, givet att Rosetta 2 fixar 70-90 % effektivitet lär motsvarande för GPUer ser en lägre effektivitet. Fördelen är i.o.f.s att något stöd är bättre än inget stöd så länge som nettoeffekten är bättre prestanda än att köra utan GPU-acceleration.
