AMD:s utvecklarverktyg översätter CUDA för Radeon-grafikkort

Det som skulle bli intressant, var om Radeon kom ikapp i produktivitetsprogram, t.ex. Adobe Premiere. I så fall skulle jag inte ha något skäl att föredra Geforce.

Till för de som utvecklar/förvaltar CUDA-applikationer som jag förstår det, inte en kund som fått en binär och hejdå.

Väldigt kul att läsa, hoppas verkligen Imperiet får ett par sprickor.

Om det finns produkter från amd som har bra prestanda jämfört med nvidias motsvarigheter till bättre pris skapas ju ett behov. Nvidia har ju monopol på cuda-hårdvara så då sätter de ju priser därefter.

Det måste väl vara mer på medellång sikt de hoppas att det ska spela roll, att på detta vis göra det lättare att komma igång med att bredda vilken hårdvara som stöds genom HIP om man har byggt en CUDA-applikation redan.

Om de kan locka strategiskt viktiga mjukvaror att stöda även AMD-prylar så kan det ju få stor effekt lite senare.

Hade varit intressant om Sweclockers kunde inkludera t.ex. Blender rendering på GPU, Blender Cycles (classroom) då Blender har stöd för HIP (haft det ett tag nu, tror sen 3.1).
Den har idag dessutom blivit snabbare jämfört med Phoronix 3.2 test där RX 6800 presterade runt 44 sekunder medans min 6800 på Blender 3.6 och 4.0 alpha på 34 sekunder.

Snabbtester Blender cycles, classroom med HIP:
3.1 - 51s
3.2 (phoronix) - 44s
3.4 - 39s
3.6.1 [HIP RT] - 33s
4.0 Alpha (230728) [HIP RT] - 33s
4.0 Alpha (230730) + ROCm 5.5 [HIP RT] - 33s edit2

4.0 Alpha delar idag en del kod med 3.6.1 så vi får se hur 4.0 release blir, har för mig att de var i slutet av Augusti som den blir "finalized".

Tror man behöver idag kompilera Blender själv för att få med ROCm 5.5 version av HIP och HIP RT, har tyvärr inte tid att undersöka samt göra det själv men det finns instruktioner på github av saadrahim för den som känner sig manad

PyTorch håller på med ROCm 5.5 idag (nightly build) men stödet för Windows finns ej än, få se om det kommer eller om det blir ROCm 5.6 istället för windows stödet.

EDIT:
Dokumentationen för ROCm finns även på github (istället för artikelns länk), där finns även installationshänvisning under "windows Quick Start"
https://rocm.docs.amd.com/en/latest/release/windows_support.h...

EDIT2:
Gjorde en build på 4.0 Alpha med manuellt tillagd ROCm 5.5. Prestandan är oförändrat sen 3.6.1.
Vi får se hur blender och HIP (med HIP RT) presterar med ROCm 5.6 istället.

Du kan ju inte ändra i mjukvaran själv med detta verktyg utan detta är för utvecklarna av mjukvaror som Adobe Premiere och Fusion 360 så de lättare kan bygga in stöd för AMD-kort också utan att bygga om alla funktioner som använder CUDA idag. Det blir som ett abstraktionslager som jag misstänker använder en del OpenCL där det går.

Edit: @HappyPie rättade mig där. Det kan gå att lägga till stöd själv där mjukvaran är open source förstås.

Trevligt att de tillslut lagt till stöd för konsument-GPUer till HIP (5000, 6000 och 7000 serien). Länge var HIP/ROCm Linux-only samt fungerande bara på "Radeon Pro" serien.

Som redan påpekats är inte detta något som gör att man automagiskt kan köra CUDA-bibliotek/program på Radeon GPUer.

HIP är i grunden ett API, ett API som är väldigt snarlikt CUDA när det kommer till funktioners signatur och funktion, dock med att annat prefix (hipXxx() i stället för cuXxx()). Finns ett verktyg som automatiserar denna översättning som kallas HIPIFY.

Som med all ingenjörskonst får man fundera vilka för- och nackdelar en lösning har.

Den uppenbara fördelen med HIP är just att dess likhet med CUDA gör det relativt enkelt att ta ett CUDA-program och konvertera detta till HIP (det är fortfarande en delvis manuell process).

Den uppenbara nackdelen är att CUDA är helt designat för att passa Nvidias GPUer + då CUDA är ett propretärt API kommer HIP alltid lagga en eller ett par versioner då det är först när en ny version av CUDA blir tillgänglig som AMD kan börja lägga in motsvarande stöd i HIP.

Intels OneAPI är precis som CUDA/HIP både ett programspråk, CUDA är en variant av C++ ("nästan" fullt C++11 stöd), HIP är en variant av C++ (mer stöd för C++14/17 jämfört med CUDA) medan SyCL använder ISO C++17 + ett bibliotek (SyCL är en standard definierad av Khronos och är det OneAPI använder) och ett gäng bibliotek/byggblock. Likt HIP finns även för OneAPI ett verktyg som delvis översätter CUDA till SyCL, men här krävs mer jobb då SyCL och CUDA skiljer sig betydligt mer än HIP och CUDA:

Kan verka vara en fördel för HIP att det är mer lika, men AMD själva pekar specifikt på detta som något man inte får automatiskt

Things the HIP SDK doesn’t do

• Optimize the performance of your software

• Provide support for developing machine learning or AI applications

En av "killer features" i SyCL över både CUDA och framförallt över OpenCL (som var rätt mycket en katastrof ställt mot CUDA) är att man identifierade just hur känslig just optimering är m.a.p. HW-utformningen, SyCLs runtime har väldigt bra möjligheter att göra optimering även vid runtime (CUDA/HIP/OpenCL gör nästan alla optimeringar up-front).

Jag tror dock att AMD grovt överskattar hur många som gladeligen kavlar upp ärmarna för att göra detta jobb. Vad jag hoppas AMD haft som prio#1 är hur enkelt det är för dem att få till HIP-stöd till relevant programvara. För tittar man runt ser man att, bortsett från vissa CUDA-fall (detta enbart då de länge var det enda realistiska valet + ingen annan har lika mycket bibliotek/byggblock för att komma igång som Nvidia), så är det i praktiken upp till HW-tillverkaren att fixa stöd om det ska bli något.

Om man tar några exempel.

Blender: Nvidia jobbar med CUDA/OptiX-stödet, AMD jobbar med HIP-stödet, Intel jobbar med OneAPI-stödet, Apple jobbar med Metal-stödet
PyTorch: Nvidia jobbar med CUDA-stödet, AMD jobbar med HIP-stödet, Intel jobbar med OneAPI-stödet, Apple jobbar med Metal-stödet
Tensorflow: Nvidia jobbar med CUDA-stödet, här finns ett par 3:e part som jobbar med HIP-stödet (eller verkar mer vara "jobbade", ingen verkar kommit speciellt långt), Intel jobbar med OneAPI-stödet, Apple jobbar med Metal-stödet

Det räcker inte med att "källkoden är öppen". Om de "andra" HW-tillverkarna säkerställer stöd för "sin" HW på viktiga projekt är det helt orealistiskt att tro att 3:e-part ska få till något på egen hand bara för att det råkar finnas en SDK. Att Jensen varit ute och jabbat mot OneAPI tror jag mycket beror på att han inser att Intel är beredd att stoppa in mycket resurser för att få in OneAPI på alla möjliga ställen (de har även fått in det i Matlab, NumPy och en gäng HPC-program).

Visa innehåll

HIP-RT fungerar inte i Secret Deer, slutsatsen från TechGauge var

"Considering the fact that Blender gained RT acceleration for NVIDIA four years ago, it is really great to finally see the feature added for other vendors in Blender 3.6. We believe Intel’s take to be stable enough for real use, but for AMD, it might be best to wait for Blender 4.0 (due November)."

Angående Blender, har gjorts lite tester på v3.6 när AMD, Nvidia och Intel alla nu har acceleration via 'RT-kärnor'

Vore kul att se lite HIP-tester på APUer. Även om de inte är lika starka som dGPUer har AMD, Intels och framförallt Apples (då de är klart snabbast i nuläget sett till topp-modellen) iGPUer unika fördel över dGPU:
de har dels tillgång till mer RAM (så borde inte finnas något fall där GPGPU faller på RAM-mängd)
då de delar RAM med CPU är det långt mer effektivt för GPU och CPU att samtidigt jobba på ett problem (Metal stödjer det i Blender i form av samtidig CPU+GPU render, sedan finns det fall CPU är bättre på samt det omvända -> kombinera styrkorna).

Är lite undrande över beskrivningen i artikeln, "Detta är den röda tråden genom den öppna plattformen ROCM, men istället för AI- och datacenterfokus siktar HIP på enskilda användare och desktop."
HIP har använts mest i datacenter än så länge och finns med i dokumentationen för de flesta nyare superdatorer med AMD hårdvara.
Det som är nytt är stöd för konsument GPU:er.

Stämmer det verkligen att AMD ligger 1 generation efter i prestanda?

För mig som inte egentligen förstår mer än det @Yoshman skriver så känns det spontant som att man dubbat ett språk till ett annat, men tveksam röstskådis på rumänska.

Stämmer nog ganska väl Nvidia RTX 4090 är nedskärd variant av Nvidia bästa chipp AD102-300-A1 ifall Nvidia skulle vilja så kan de släppa ett RTX 4090 Ti med hela kärnan aktiverad.

RTX 4090 presterar ca 20% bättre än RX 7900XTX och en 4090Ti? skulle förmodligen presterar ca 30% bättre än ett RX 7900XTX.

Så 20-30% bättre prestanda är ungefär en generation

Så är det, lägger man in prestanda/krona så väl RX 6950 XT rätt så svårslagen i dagsläget?

Att de inte gör något kort som motsvarar 4090 betyder inte att de är en generation efter. Sen använder du spelprestanda här - compute ser helt annorlunda ut.

Haha. Många här med examen i ”Sweclockers prestandaindex”

https://youtu.be/IhlL1_z8mCE

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

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.