DirectX 12-apparaten krijgen in de toekomst ondersteuning voor OpenCL en OpenGL

Windows krijgt in de toekomst ondersteuning voor OpenCL 1.2 en OpenGL 3.3. Dat meldt softwarebedrijf Collabora, dat samenwerkt met Microsoft om de api's naar apparaten met DirectX 12-ondersteuning te brengen. Het is nog onduidelijk wanneer dit gebeurt.

Collabora meldt dat het bedrijf hiervoor gebruikmaakt van de Mesa 3D Graphics Library. Dat is een opensource-implementatie van verschillende grafische technieken, waaronder OpenCL en OpenGL. Collabora gebruikt de Gallium-interface als basis voor de OpenGL-laag. Voor de OpenCL-compiler wordt NIR gebruikt. In de praktijk moet dit project ertoe leiden dat alle apparaten die DirectX 12-ondersteunen, op termijn ook met OpenCL en OpenGL overweg kunnen.

Om OpenCL compatibel te maken met DirectX, gebruiken de ontwikkelaars LLVM en de SPIR-V-LLVM-translator van Khronos om 'SPIR-V-representaties' van de OpenCL-kernel te maken. Deze kernel wordt vervolgens vertaald naar NIR, waar enkele optimalisaties worden doorgevoerd. Uiteindelijk wordt de NIR-kernel vertaald naar DXIL, een programmeertaal voor DirectX. Hiermee kan het worden uitgevoerd op DirectX 12-gpu's.

De vertaalslag van OpenCL naar DirectX is meervoudig. Afbeelding via Collabora

Voor OpenGL gebruiken Microsoft en Collabora de Gallium-driver voor D3D12. Deze driver neemt OpenGL-commando's en vertaalt ze naar DXIL, waarna ze via de driver worden uitgevoerd op een DirectX12-gpu. Volgens Collabora komen hier enkele 'interessante details' bij kijken waardoor dit lastig kan worden, maar het bedrijf zegt deze details later te delen.

Collabora meldt wel dat er nog een hoop werk te doen is voordat gebruikers ondersteuning voor OpenCL en OpenGL in hun DirectX12-apparaten kunnen verwachten. Zo moet het bedrijf nog het gewenste feature-level bereiken. Collabora wil de conformiteitstests voor OpenCL 1.2 en OpenGL 3.3 halen. Ook moet nog gewerkt worden aan compatibiliteit met applicaties, waarbij vooralsnog vooral op productiviteitsprogramma's wordt gefocust. Het bedrijf geeft dan ook geen releaseperiode aan. Wel deelt Collabora de broncode van het project. Op termijn moet de broncode te vinden zijn in de Mesa-repository.

Reacties (18)

[henk717]

Ik neem aan dat dit voor de driverloze opstelling is? Ik kan mij namelijk geen GPU driver bedenken die niet OpenGL 4.6 levert.

Edit: Lijkt er op dat het om een compatibility layer gaat zodat je als app developer een beperktere maar universelere OpenGL kunt gebruiken. Wel vraag ik mij nog steeds af hoe dit in de praktijk werkt gezien er al OpenGL drivers aanwezig zijn van de GPU leverancier. Kan de applicatie kiezen en welke wordt standaard gebruikt? Want je wil tenslotte niet dat een moderne OpenGL game ineens via OpenGL 3.3 gaat draaien.

Ik gok dat dit niet officieel in Windows komt maar gebundeld wordt met de applicaties als Mesa voor Windows. Of als los geinstalleerde driver als je het system wide nodig hebt.

[Reactie gewijzigd door henk717 op 22 juli 2024 18:47]

[CoreIT]

Het lijkt me ook wel handig voor applicaties die WebGL 2.0 willen ondersteunen.

[Wolfos]

Nu nog wel, maar het is de vraag hoe lang een oude API die toch al nooit echt werd aangeraden op Windows nog ondersteund word. Hiermee zijn die (vaak slecht werkende) drivers dus niet meer nodig. Ook zal het ongetwijfeld wat prestatievoordelen opleveren.

[Reactie gewijzigd door Wolfos op 22 juli 2024 18:47]

[Darkstriker]

Waar de F heb jij het over? OpenGL presteert prima op Windows en zo'n compatibility layer zal dat alleen langzamer maken.

[CH4OS]

Ik ben benieuwd hoe dit gaat presteren als het er eenmaal is, want zoals ik de tekst nu interpreteer, zitten er twee lagen tussen die eea omzetten zodat input van X naar Y gaat, van Y naar Z en van Z uiteindelijk de DX12 API in...

[SuperDre]

Juist dat is ook mijn gedachte, dit zal toch een behoorlijke performance impact hebben tegenover 'native' werken..

[wpoely86]

Nee, dat hoeft absoluut niet. Dit is de standaard manier waarop Mesa werkt. De 'high level' input (OpenGL in dit geval) wordt omgezet naar NIR en de eigenlijk gpu driver zet NIR om iets dat het kan verwerken (DX12 in dit geval). Dat verschilt niet wezenlijk met het geval waar je rechtstreeks naar een GPU driver output (bv radeonsi).

Ik ken de interne keuken van DX niet maar ik vermoed dat je daar ook meerdere lagen hebt.

[gast128]

Ik heb wel eens met OpenCL en AMP gespeeld maar meestal is dat een buffer reserveren en een kernel definiëren en dat naar de GPU opsturen waar het echte parallelle rekenwerk gebeurt. Elke vertaallaag heeft overhead maar wellicht in deze weinig omdat het hele idee is dat de GPU het zware werk doet. Dat gezegd hebbende schijnt CUDA sneller te zijn dan OpenCL en dat is in tegenspraak met wat ik net opschreef.

[johnbetonschaar]

Best apart dat ze ook OpenCL op deze manier op DX12 devices willen aanbieden, ik had zelf het idee dat OpenCL voor GPU compute nooit echt is doorgebroken en inmiddels eigenlijk min of meer overbodig is. Het overgrote deel aan compute werk op GPU's is volgens mij CUDA voor NVidia en voor nieuwe GPU compute projecten die andere vendors moeten onderstuenen is er Vulkan Compute voor Windows/Linux en Metal voor macOS? Welke use case vult een OpenCL => DX12 laag in?

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 18:47]

[Belgar]

Vulkan compute is een subset van OpenCL. In de DX12 context heb je, denk ik, grotendeels gelijk dat je vulkan compute zou kunnen gebruiken.

Indirect gebeurt dat ook,omdat er gebruikt wordt van SPIR-V(ulkan), de intermediate die beide gebruiken. Ik neem aan dat het voornamelijk voor backwards compatibility is en geen toekomstige implementaties.

[IndoBoy]

Als ik mij goed herinner voor de Voodoo kaarten in het verleden gebruikt.

[johnbetonschaar]

Ik kan me vergissen maar volgens mij is dit niet correct en staat OpenCL op NVidia volkomen los van CUDA, het is ook een heel ander model van programmeren. CUDA code voeg je samen met je C/C++ compiler en dat haal je dan door Nvidia tooling om een binary te bouwen, terwijl OpenCL code run-time wordt gecompileerd in de driver. De feature set van OpenCL is ook breder en ondersteunt ook CPU's en FPGA's, wat eigenlijk alleen maar een nadeel is in plaats van een voordeel als je alleen maar in GPU compute taken geïnteresseerd bent.

[CH4OS]

Punt is dat OpenCL wel gebruikt wordt, niet veel, maar het gebeurd wel. Vooral in CAD applicaties komt het voor zover ik begreep veel voor, maar ook programma's als Photoshop gebruiken het veel. Folding@Home werkt voor de videokaarten die zij ondersteunen ook gewoon op basis van OpenCL en daarvan kunnen zowel AMD kaarten als nVidia kaarten gebruik maken. Vandaar dat ik ervan uitging dat OpenCL simpelweg een API is, dat vervolgens afhankelijk van de GPU dus zaken of naar CUDA vertaald, of het AMD alternatief daarvan, anders heeft het aanbieden van een API als OpenCL geen zin.

Naar mijn weten is er geen apart component voor OpenCL op de GPU's en worden de hardwarematige berekeningen inderdaad op basis van CUDA gedaan voor nVidia. Ook dit artikel geeft aan dat OpenCL een alternatief is op CUDA, dus het zou mij niet verbazen als het, voor nVidia kaarten, het 'gewoon' een vertaalslag doet van OpenCL naar CUDA of CUDNN.

[geoffrey.vl]

CUDA en OpenCL zijn beiden API's voor GPGPU zaken. CUDA is echter een proprietary stack van NVIDIA en werkt enkel op NVIDIA hardware. OpenCL is als open standaard een tegenhanger van CUDA die wel werkt op verschillende hardware. Je kan OpenCl op je NVIDIA/AMD/Intel videokaart aanspreken, of bv de GPU in je embedded systeem, of zelfs je CPU kan gebruikt worden in OpenCL. Hiervoor moet er echter wel een driver beschikbaar zijn die OpenCL voorziet voor jouw hardware.

OpenCL lijkt inderdaad stukken minder populair, maar dat lijkt altijd wel zo geweest te zijn. NVIDIA was er heel snel bij en heeft altijd goeie marketing hierover gedaan. Performance wise zit CUDA meestal ook iets beter. Vandaag de dag zie je doorgaans veel gebruik van CUDA in de embedded wereld, o.a. voor objectherkenning e.d.

[CrazyJoe]

Ook vanuit een programmeurs oogpunt is CUDA prettiger om mee te werken dan OpenCL. Veel zaken die in CUDA voor je opgezet worden moet je in OpenCL zelf handmatig opzetten, wat het gebruik van OpenCL natuurlijk een stuk onaangenamer maakt.

Ook worden in CUDA (omdat het nu eenmaal alleen voor NVIDIA kaarten geschikt is) een aantal zaken efficienter geimplementeerd dan in OpenCL, wat compatible moet zijn met een grote diversiteit aan hardware (GPU's zowel als CPU's).

[fastbikkel]

Ik heb hier weinig verstand van, maar vind openGL gewoon altijd wel cool om te volgen.
Blijft toch datgene waarmee ik mn Diamond viper 330 gebruikte in Quake toendertijd.
Een voodoo kaart vond ik te duur en openGL bood een heel net alternatief dat eigenlijk alleen maar beter werd.

[ari3]

Dit lijkt mij de verkeerde aanpak. Ik zou eerder OpenGL/CL de defacto standaard maken voor Windows en een DX-vertaler maken naar OpenGL/CL voor legacy applicaties. Dit heeft als voordeel dat applicaties veel meer portable worden. Maarja, Microsoft zou zijn DX vendor lock-in wel graag willen behouden...

Wat mij nog steeds verbaasd aan DX is dat je heel vaak applicatie-specifieke patches uitgebracht ziet worden op de DX-driver van de grafische kaart. Dat duidt mijn inziens op een ontwerpfout.

Sowieso mag er wel eens vaart gemaakt worden met een generieke driver voor grafische kaarten. Voor USB, Firewire en SATA zijn we immers ook naar een generieke hardware interface gegaan met bijbehorende generieke kernel drivers. Mij lijkt dat er ook een gestandaardiseerde hardware interface kan komen voor het aansturen van grafische chipsets. Feitelijk zou je het OpenGL profiel gewoon in het BIOS kunnen coderen en via de SM-bus uitvraagbaar maken ofzo. Het is gewoon een verspilling van resources om voor iedere grafische kaart of chipset weer nieuwe drivers te gaan ontwikkelen.