AMD maakt raytracinglibrary's voor HIP-programmeertaal opensource

AMD heeft enkele raytracinglibrary's voor zijn HIP-programmeertaal opensource gemaakt. Hierdoor zouden ontwikkelaars die raytracingfunctionaliteit willen toevoegen aan hun HIP-applicaties, dat op een eenvoudigere wijze kunnen doen.

AMD heeft het nieuws bekendgemaakt op GPUOpen. Het bedrijf heeft de raytracinglibrary's en alle extra documentatie beschikbaar gemaakt op GitHub. AMD vertelt niet waarom het de library's opensource heeft gemaakt. De redactie van Wccftech vermoedt dat dit heeft te maken met start-up Tiny Corp. Tiny Corp is een computerbedrijf dat momenteel AI-hardware aan het ontwikkelen is. Het maakt daarbij gebruik van AMD Radeon RX 7900 XT-videokaarten en zou tijdens de ontwikkeling van zijn AI-systemen problemen met de firmware van deze videokaarten hebben ondervonden.

HIP staat voor Heterogeneous-Compute Interface for Portability. Het is een C++-runtime-api en kernel language waarmee ontwikkelaars programma’s kunnen schrijven voor hardware van zowel AMD als Nvidia. Ontwikkelaars kunnen HIP ook gebruiken om software die voor Nvidia-gpu’s is geschreven, te converteren naar een codebase die op AMD-gpu’s kan draaien.

AMD HIP Ray Tracing

Reacties (32)

[JBVisual]

Ik denk dat dit soort beslissingen zeer goed kunnen uitpakken, sterker nog… ik denk dat als AMD nog meer opensource maakt ze hun positie aardig kunnen veranderen.

Waarom zelf alleen een duur betaald team drivers laten schrijven als je tienduizenden vrijwilligers mee kan laten doen.

Je software en drivers worden er beter van, je producten gaan hiermee beter functioneren. Meer mensen kopen je producten hierdoor wat weer extra R&D budget beschikbaar maakt.
Uiteraard is dit wel een langetermijnvisie, maar dit soort beslissingen zullen er juist voor zorgen dat ik juist voor een AMD product zou kiezen.
(Helpend in keuze is niet per definitie àlles bepalend uiteraard. Zou vind ik de ik “Framework” laptops wel leuk, maar niet passend bij wat ik in een laptop zoek)

[Wolfos]

Wat vooral goed uitpakt is het feit dat AMD zich keihard aan het verbeteren is op het gebied van compute. De Nvidia dominantie op dat gebied bestaat vooral omdat AMD daar jarenlang te weinig in investeerde.

Ze zijn nog niet echt competitief maar sinds de 7000 serie begint het wel ergens op te lijken. Als ze over een paar generaties echt competitief zijn word het natuurlijk interessant, en is zo'n open alternatief voor CUDA een goed lokkertje.

[goarilla]

en is zo'n open alternatief voor CUDA een goed lokkertje.

Lokkertje het is mijn insziens toch de main reason voor de enterprise om bij Nvidia te blijven. Dat en hun cluster tools en integratie (nvidia-smi, openpbs/slurm, ...).

[johnny2000]

Hoe nobel het ook is (#team red hier) het laat natuurlijk mooi zien dat concurrentie goed is. Intel en Amd kunnen niet anders. En ook ik denk dat Nvidia straks weer mee gaat doen.

Voor mij heeft Nvidia al heel lang afgedaan, en support Amd hardware. Wellicht iets minder, maar hun open karakter houd ik van. En de frustraties van kernel modules moeten compileren .... Niet meer!

[Sp3ci3s8472]

AMD is op dit moment in gesprek met een aantal ontwikkelaars om hun firmware van gpus gedeeltelijk opensource te maken. ROCM is namelijk nog niet fantastisch en de compiler heeft fouten die door het opensource maken kunnen worden opgelost.

Ben heel benieuwd wat hier uit gaat komen. Ook al zouden ze maar een gedeelte opensource maken zou dat mooi zijn.
Twitter posts (en video) heb ik gelinked in het CJ AMD gpu topic:
https://gathering.tweaker...message/78454446#78454446

[fevenhuis]

Ik denk dat AMD op de grafische afdeling net zoveel verkeerd doet als het Nvidia achterna loopt.

RTX bestaat alweer een hele tijd en een complete programmeertaal voor grafische doeleinden zonder voorbeelden van wat er mee mogelijk is?

Nee, ze hebben nog een hoop te leren daar.

[Sp3ci3s8472]

Er staan op de gpuopen website genoeg voorbeelden. Het is voornamelijk bedoellt voor renderers bijv. Blender.

Wat bedoel je precies met RTX bestaat al een tijd? Mooi dat dat stukje merknaam/trademark al een tijdje bestaat maar wat heeft dat hier verder mee te maken.

Als je bedoelt dat RT al een tijd bestaat, dat klopt en Nvidia had niet eens de eerste ingame variant; dat was Intel in het tijdperk van Quake Wars.
https://www.youtube.com/watch?v=mtHDSG2wNho

Laat niet weg dat AMD vaak achter de feiten aan loopt.
Aan de andere kant kun je het punt maken dat RT pas nu een beetje bruikbaar wordt in spellen.

Edit: tikfouten, want mobiel..

[Reactie gewijzigd door Sp3ci3s8472 op 23 juli 2024 16:03]

[fevenhuis]

Ik bedoel natuurlijk dat code voorbeelden niet zo goed verkopen als grafische voorbeelden wat mogelijk is met de code.

Nvidia begrijp dat gedeelte van de marketing dus een stuk beter.

[Sp3ci3s8472]

Dat klopt zeker, AMD marketing laat een boel steken vallen op dat punt.

Ik denk wel dat het punt van GPUOpen, met wellicht minder fraaie voorbeelden als Nvidia niet bedoelt is voor de standaard gamers maar eerder voor ontwikkelaars en nog specifieker game engine developers of mensen die aan renderers werken; ik vind het juist fijner als er een paar goede voorbeelden zijn met code om iets werkend te krijgen.

Laat niet weg dat een pagina met wat voorbeelden die er super mooi uitzien voor de bühne ook erg belangrijk is. Nvidia levert altijd interessante demo's, zoals die path traced knikkerbaan.

[THETCR]

@JayStout HIP is geen programmeertaal maar een C++ API.

[.oisyn]

Het is weldegelijk een eigen taal, het is namelijk niet strict C++. Het heeft extra keywords en niet de volledige set van C++ wordt ondersteund.

[THETCR]

Dat noemen we een subset. En maakt het niet een eigen taal.

The phrase 'Kernel Language' refers also to a small, fixed subset of a language for which everything else is SyntacticSugar.

[.oisyn]

Het is geen subset als het nieuwe elementen toevoegt

C++/CLI noemen "we" dus ook gewoon een eigen taal.

API is helemaal een misnomer omdat je er wel een aparte compiler voor nodig hebt.

[Reactie gewijzigd door .oisyn op 23 juli 2024 16:03]

[THETCR]

Volgens mij bedoel je het andersom.

Het is geen subset als niet alle elementen in de parent te vinden zijn.

[Reactie gewijzigd door THETCR op 23 juli 2024 16:03]

[.oisyn]

Dat is een superset.

{a, b, c} is een subset van {a, b, c, d, e}. Het probleem is dat HIP strict gezien allebei niet is. Het ondersteunt niet álle C++ features (wat het een subset zou maken), maar het voegt ook eigen taalconstructies toe. Als C++ {a, b, c, d, e} is, dan is HIP {a, b, c, f}. Dus zowel geen subset als geen superset.

[THETCR]

Klaarblijkelijk is het alleen om de primitives goed om te zetten.

De compiler is een wrapper om Clang heen en gebruikt vervolgens LLVM of NVidia hun compiler om het goed te compilen.
Maar alles wordt nog steeds geschreven in C++.
Alle extra keywords zijn sugar syntax.

[.oisyn]

Alle extra keywords zijn sugar syntax.

Álle keywords en constructs in talen zijn natuurlijk syntactic sugar.

Het belangrijkste punt hier is, voor een purist is dit geen stricte C++ is. Het is een extensie van de taal, en daarmee kun je het zien als een eigen taal, met een eigen compiler front-end.

Je distinctie tussen "programming language" en "kernel language" ondersteun ik niet. Natuurlijk is het een programmeertaal. Ze noemen het een kernel language omdat je er compute kernels mee kunt bouwen.

[THETCR]

Ze maken zelf echter niet de claim een aparte programmeertaal te zijn. Maar eerder een zogenaamd "dialect".

[jerisson]

Maar alles wordt nog steeds geschreven in C++.
Alle extra keywords zijn sugar syntax.

Volgens die redenering is C++ geen op zichzelf staande programmeertaal, maar slechts C met extra keywords die sugar syntax zijn.

[THETCR]

Nee, want voor C++ heb je toch een aparte compiler nodig?

[jerisson]

Voor HIP en gelijkaardige systemen ook. Voor CUDA heb je bijvoorbeeld nvcc nodig om je C(++)-achtige code te compilen.

Bij OpenCL compilede je (althans vroeger) de kernel code at-runtime mbhv een compiler die in de OpenCL library zat. Hetzelfde voor shaders bij OpenGL bijvoorbeeld. Deze compiler zorgde dat C/C++-achtige code omget werd naar code geschikt voor de specifieke GPU.

Bij CUDA gaat nvcc de code analyzeren en opsplitsen in code bestemd voor de cpu en code voor de gpu (device code). Het cpu gedeelte wordt aan een traditionele compiler meegegeven (nvcc gebruikt onder linux bijvoorbeeld by default gcc), maar de device code built nvcc zelf omdat gcc niet weet wat ermee aan te vangen.

Bij HIP wordt nvcc of HIP-Clang aangeroepen door hipcc. Hipcc heeft zowat dezelfde functie als nvcc, maar moet ook met 3rd party vendors rekening houden (NVidia). HIP-Clang is een compiler gebaseerd op Clang, maar dus met aanpassingen voor HIP-C++.

Al die systemen hierboven hebben een eigen variant van C of C++ om GPU-code te schrijven. Voor 95% zijn ze hetzelfde, maar 5% zorgt ervoor dat het dialecten zijn en dus niet compatibel met de standaard-taal. Voor mij, en ik gok de meeste programmeurs, is dat voldoende om te spreken van een andere programmeertaal: simpelweg om verwarring of conflicten te voorkomen.

[THETCR]

Ja, dus het is alleen een subset wanneer alles ervan in de "set" te vinden is. En een super set wanneer het alles van de "set" heeft en er extra dingen aan toevoegt.

Het gaat hier dus om een kwestie van terminologie. Kernel language vs Programming language.

[Reactie gewijzigd door THETCR op 23 juli 2024 16:03]

[TheVivaldi]

Het Frans voegt ook nieuwe elementen toe ten opzichte van het Latijn waarop het gebaseerd is en niet alle elementen/woorden van het Latijn vind je terug in het Frans, maar niemand zal zeggen dat het Frans geen taal is.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 16:03]

[THETCR]

Maar gelukkig is dat niet een correcte vergelijking in dit geval.

[jerisson]

Van de HIP documentatie:

HIP is a C++ runtime API and kernel language that allows developers to create portable applications for AMD and NVIDIA GPUs from single source code.

Een kernel language is een programmeertaal. Met andere woorden: HIP is beide.

[Mars Warrior]

Beetje verwarrend lijkt het wel ja. Maar in je link staat toch echt "taal", al zal het enkel een uitbreiding op C++ zijn...

New projects can be developed directly in the portable HIP C++ language and can run on either NVIDIA or AMD platforms

[THETCR]

Omdat C++ zelf de language is.

Ter verduidelijking er zit een verschil tussen een "Kernel Language" en een "Programming Language".

Volgens het artikel is het een Programming Language, maar dat is het niet.

[Reactie gewijzigd door THETCR op 23 juli 2024 16:03]

[jerisson]

Fout. Daarmee bedoelen ze dat de C kernel APIs HIP headers begrijpen.

Hierbij krijg ik de indruk dat je denkt dat ze het over de kernel van het OS hebben (bvb Linux kernel), terwijl het over compute kernels gaat.

Hoe je überhaupt bij het idee komt dat het beide kan zijn en de terminologie "kernel language" een programmeertaal impliceert is noemenswaardig.

Ik zie niet in hoe kan je kan denken dat dit niet is: een kernel language is nu eenmaal een programmeertaal om compute kernels voor computing devices (hier GPU, maar ook bvb CPU en FPGA - zie OpenCL) te schrijven/programmeren.

Net zoals shader languages (HLSL, GLSL, ...) programmeertalen zijn om shaders te schrijven/programmeren.

Kernel language impliceert programmeertaal, maar programmeertaal impliceert niet kernel language.

Daarnaast gaat het over de HIP C++ Language (zoals ze het zelf noemen in de link waarnaar je verwijst): een variant op de standaard C++ Language. Bepaalde features van standaard C++ zijn niet geschikt voor compute kernels, onder andere omwille van de verschillende memory layouts en architectuur van de accelerator hardware t.o.v. een CPU. De multi-threading synchronisatietechnieken van standaard C++ zijn bijvoorbeeld niet geschikt voor HIP: daar heb je andere technieken voor nodig die wel in HIP C++ zitten. Verder heeft HIP C++ ook andere keywords om de scope van functies (~kernels) en locaties van geheugen en uit te voeren code aan te duiden.

De syntax is grotendeels C++, maar HIP C++ is een dialect van gewone C++, waardoor het niet volledig compatible is.

[THETCR]

Precies dat laatste stuk. Het is een "dialect", niet een volledig eigen taal.
Daar zit het belangrijke verschil in de definitie.

Het is de wrapper om de Clang compiler -> LLVM / NVidia compiler die de daadwerkelijke vertaalslag maakt toch?

[Metal spoon]

Lijkt mij een goede ontwikkeling.
Nu ongeveer 1 jaar overgestapt naar een AMD GPU (kwam van Nvidia), met name vanwege de betere linux support voor dingen als wayland en algemene QoL.
Maar ik overwoog destijds nog sterk om een nvidia te nemen voor CUDA omdat ik nog wel eens loop te hobbyen met blender.

Voor HiP was er voor AMD GPU's openCL en dat was nogal vervelend om goed werkend te krijgen met blender op linux omdat je proprietary en opensource (mesa) userspace drivers door elkaar moest draaien.
Zeker vervelend als je ook af en toe wilt gamen, want de proprietary drivers die je nodig had voor openCL hadden verminderde gaming performance t.o.v. mesa.
Hoe dan ook, HiP kwam rond die tijd ook in de picture dus uiteindelijk toch een AMD gekocht.
HiP is echt super makkelijk te installeren en je hoeft niet meer verschillende driver stacks door elkaar te draaien.
Een nvidia kaart uit hetzelfde klassement (ik heb een 7900xt, dus grofweg een 4080/4070ti i guess) is nog steeds sneller met CUDA, maar AMD met HiP komt echt redelijk in de buurt, zeker t.o.v. openCL vroeger.
Voor enterprise usecases zal nvidia nog wel even koning blijven, maar voor mijn hobbywerk is HiP meer dan zat.

[Bux666]

WTF heeft raytracing met AI te maken?