W3C publiceert ontwerp voor WebGPU

Het World Wide Web Consortium heeft de eerste publieke working drafts voor WebGPU en de WebGPU Shading Language gepubliceerd. De publicatie is een nieuwe stap naar brede adoptie van de webstandaard voor acceleratie van grafische berekeningen.

Het W3C zet met de publicaties voor WebGPU en de Shading Language voor de technologie op een rij wat het tot nu toe heeft vastgelegd voor de komende webstandaard. De werkgroep voor WebGPU beschrijft onder andere zaken omtrent beveiliging, privacy, buffers en rendering.

WebGPU is een standaard voor de acceleratie van grafisch rekenwerk met gpu's voor webtoepassingen. De standaard wordt ontwikkeld door de GPU for the Web Community Group van de W3C, waarin ontwikkelaars van onder andere Apple, Mozilla, Microsoft en Google vertegenwoordigd zijn. De voorgestelde standaard heeft dan ook brede ondersteuning en de potentie om op veel platforms te werken.

De api moet WebGL vervangen en heeft zijn oorsprong in voorstellen voor WebGL Next-technologie van Google, Khronos en Mozilla, en WebMetal van Apple. De uiteindelijke WebGPU-api gebruikt technologie van Vulkan, Direct3D 12 en Metal, in tegenstelling tot WebGL, dat op OpenGL is gebaseerd. OpenGL is nooit het succes geworden waar de initiatiefnemers op hoopten, door onder andere gebrekkige ondersteuning, bugs en de voorkeur van ontwikkelaars voor Direct3D. Vulkan moest daar als Next Generation OpenGL Initiative verandering in brengen met onder andere betere prestaties.

Reacties (48)

[elmuerte]

OpenGL is nooit het succes geworden waar de initiatiefnemers op hoopten, door onder andere gebrekkige ondersteuning, bugs en de voorkeur van ontwikkelaars voor Direct3D.

Dat is nogal een statement.
Misschien is het voor Windows games niet het meest populair. Maar de wereld is groter dan Windows games.

[Cergorach]

OK... Welke (mainstream) consoles gebruiken het? Welke (mainstream) mobile devices gebruiken het? Welke Linux gamers spelen primair OpenGL games ipv. games via Wine of Proton?

Don't get me wrong, er zijn zeer goede games uitgegeven met OpenGL die niet eens zo oud zijn. Maar dat lijken primair crossplatform games te zijn van indie studio's (Bastion, Frozen Synapse, etc.). Ik heb altijd de indruk gehad dat dit een keuze is omdat men geen betere optie heeft, met wellicht zo nu en dan een idealistische keuze voor OpenGL.

https://www.pcgamingwiki.com/wiki/List_of_OpenGL_games

[sspiff]

Erm, tot een paar jaar terug was OpenGL de grafische API op iOS (voor Metal er was), en op Android is het nog steeds de meest gebruikte en ondersteunde API.

Bovendien draait de grafische interface van Android gewoon in OpenGL.

Dus op je vraag van "welke mainstream mobile devices gebruiken het", kunnen we alvast antwoorden: "bijna allemaal."

[JackBol]

In 2015 is Metal al geintroduceerd omdat OpenGL ruim te kort schoot voor de ambities van mobile gaming. Vrijwel alle iOS games draaien Metal.

[Reactie gewijzigd door JackBol op 29 juli 2024 08:08]

[Lord Anubis]

Ik vond de reden waardoor Apple het verving met Metal wel een goed plan. OpenGL uitfaseren lijkt me een logisch vervolg. Dus ja, waarom zouden anderen het ook niet doen. Al gebruikt/zit het in ieder systeem, de groei/ontwikkeling in OpenGL zat er niet meer in, leek me.

[Leejjon]

De OpenGL versie op iOS devices liep voordat Metal er was steeds een aantal versies achter tov Android. Waarschijnlijk deed Apple geen moeite om dit up to date te houden omdat ze toen al aan Metal werkte, maar het was niet alsof er geen ontwikkeling aan OpenGL gebeurde.

[elmuerte]

OpenGL wordt ook buiten games gebruikt. Veel 3D modelleringssoftware maakt gebruik van OpenGL (maar steeds meer Vulkan). Bijvoorbeeld Pixar's RenderMan gebruiken OpenGL voor een aantal zaken. Maar ook Blender maakt gebruik van OpenGL. Geen van beide tools doen iets met DirectX.
Verder is er maar 1 console tak die DirectX gebruikt, althans, een variant er van. PlayStation 3 ondersteunde wel OpenGL. Switch is gecertificeerd voor OpenGL 4.5/OpenGL ES/Vulkan.

[Wolfos]

OpenGL is vrijwel niet relevant meer voor games. De engines ondersteunen toch wel alle API's, dus kan je maar beter degene gebruiken die voor het platform word aangeraden. Dan word OpenGL eigenlijk alleen nog een fallback voor Android toestellen die geen Vulkan ondersteunen, voor de rest kan ik me echt niet bedenken waarom je nog OpenGL zou gebruiken.

3D software zou natuurlijk ook gewoon baat hebben bij een DX12/Vulkan/Metal renderer.

[Reactie gewijzigd door Wolfos op 29 juli 2024 08:08]

[johnbetonschaar]

OK... Welke (mainstream) consoles gebruiken het? Welke (mainstream) mobile devices gebruiken het? Welke Linux gamers spelen primair OpenGL games ipv. games via Wine of Proton?

- Zo ongeveer alle Android devices, en tot aan de introductie van Metal alle iOS devices (OpenGL ES)?
- Zo ongeveer all professionele 3D workstation applicaties die niet op Windows draaien
- Nintendo Switch support OpenGL (naast Vulkan)
- Elke game op een niet-Windows platform geschreven voordat er Vulkan of Metal was gebruikt OpenGL

Dat het 'nooit het success is geworden waar de iniatiefnemers op hoopten' is een bijzonder vreemde uitspraak van Tweakers en slaat de plank m.i. compleet mis. De eerste versie van OpenGL stamt uit 1992, de eerste versie van Vulkan uit 2015, en de eerste versie van Metal uit 2014. Dat betekent dat OpenGL bijna 25 jaar letterlijk de *enige* realistische optie voor 3D op *alle* niet-Windows platforms is geweest. Hoe je dat 'niet succesvol' kunt noemen is me een raadsel.

[Cergorach]

Men had natuurlijk gehoopt dat het mainstream was geweest op alle platforms, dus zo vreemd is die statement niet.

[Xthemes.us]

Tjah enkel een succes daar waar het de enige keus is - dat is inderdaad geen enorm succes. Het enige platform waar iets anders beschikbaar was werd massaal voor DirectX gekozen. Bij games is het m.u.v. Doom altijd de andere optie standaard*.
Bij emulators etc als er een optie is om DirectX te gebruiken gaat dit vrijwel altijd gepaard met een flinke prestatiewinst.

*En weinig games die überhaupt een optie hebben om OpenGL te gebruiken, bijna alleen blizzard titels die sowieso al een OpenGL versie voor MacOS moesten maken.

Zou leuk zijn geweest als het overal de standaard was. De prestaties hadden heel waarschijnlijk een stuk hoger gelegen als AMD en Nvidia dezelfde aandacht hadden gegeven aan opengl als aan DirectX. Maar goed het heeft zijn rol vervult, het is nu aan Vulkan om de fakkel over te nemen en die presteert gelijk aan of zelfs beter dan DirectX.

[jetspiking]

Welke Linux gamers spelen primair OpenGL games ipv. games via Wine of Proton?

Waarom zou je games die je Native kunt draaien via Wine of Proton spelen?

Don't get me wrong, er zijn zeer goede games uitgegeven met OpenGL die niet eens zo oud zijn. Maar dat lijken primair crossplatform games te zijn van indie studio's (Bastion, Frozen Synapse, etc.). Ik heb altijd de indruk gehad dat dit een keuze is omdat men geen betere optie heeft, met wellicht zo nu en dan een idealistische keuze voor OpenGL.

Inderdaad een hoop mooie games uitgebracht die OpenGL gebruiken, ook veel moderne games. De meest bekende is denk ik wel Minecraft (LWJGL).

Bovendien daarnaast mijn favoriete games (Kotor 1 en 2, naast Jedi Academy) .

OpenGL is nooit het succes geworden waar de initiatiefnemers op hoopten, door onder andere gebrekkige ondersteuning, bugs en de voorkeur van ontwikkelaars voor Direct3D.

Ik snap deze quote eigenlijk ook niet, waar is de bron hiervoor? Naar mijn weten doet OpenGL het heel goed.

[TheMak]

Een collega had een 3D visuele applicatie op een silicon graphics machine geprogrammeerd in opengl. Deze applicatie kon ik ook draaien op een systeem met een alpha processor (een andere unix machine). Daarvoor was opengl bedoeld. Handleiding uitgeprint met een matrix printer weet ik nog. Dus ik heb het over de jaren 90. Een niche markt. Ik betwijfel of Direct3D geschikt is voor toepassingen in linux/unix omgevingen, om het zacht uit te drukken. Genoeg mensen die het ook voor games wilden gebruiken. Maar ik weet vrij zeker dat de initiatiefnemers dat niet bedoeld hadden, maar ik heb ze niet gesproken.

[Gropah]

Die lijst is sowieso niet compleet en er staan genoeg AAA games op, maar die zijn vaak wat ouder, zoals CoD2 en 4, alle bioshocks, Civilization 3 tm 6, Doom 2016 of Borderlands 3. Dat ze wat ouder zijn heeft er mee te maken dat het tegenwoordig iets achterhaalt is en opgevolgd is door Vulkan.

In 2013 kwam AMD met Mantle, een nieuwe, directere manier om GPUs aan te kunnen sturen waardoor er meer uitgehaald kon worden (wat natuurlijk erg lekker werkte met hun nieuwste GPUs). Dit heeft veel verschuiving veroorzaakt. Hoewel Mantle zelf niet meer is, is het wel de blauwdruk voor DirectX12 en Vulkan. DX12 is de windows specifieke variant en Vulkan is de open variant, die door sommige ook wel als opvolger word gezien van OpenGL voor graphics in games.

Maar OpenGL gaat veel verder dan games. Het word ook regelmatig gebruikt voor visualisaties in de wetenschap. En als je mij 1 ding kunt vertellen, is dat dit soort technologie in de wetenschap oneindig lang gebruikt blijft worden.

[Cergorach]

En als je mij 1 ding kunt vertellen, is dat dit soort technologie in de wetenschap oneindig lang gebruikt blijft worden.

En in het bedrijfsleven! Cobol anyone? ;-)

[Schway]

Nou, de Windows games wereld is anders best groot.

[Settler11]

Inmiddels wel. En dat is in mijn optiek een goed iets. Microsoft is aardig goed op weg met de Game Pass maar er zijn nog zat zaken die voor verbetering vatbaar zijn.

[Reactie gewijzigd door Settler11 op 29 juli 2024 08:08]

[mOrPhie]

Waar doel je op? XBox is altijd DirectX geweest. Playstation verschillende implementaties (soms extensies op OpenGL ES, zoals PSGL, maar later volledig aparte API's als GNM). Nintendo de NVN api. De support voor OpenGL brokkelt al jaren af. In Windows-land is DirectX koning, maar daarbuiten is het zeker niet per se OpenGL. Het enige dat OpenGL echt voor heeft, is dat het een open standaard is en daardoor zoveel bindings kent. Daarom was het een "relatief" gemakkelijke keuze voor het web. Maar dat maakt het niet per se de beste keuze.

[maali]

ja, erg boud en onjuist. zo'n beetje ieder willekeurig apparaat met iets van een GPU erin maakt gebruik van opengl tenzij 't zelf een andere API heeft. Dat lijkt me best een succes te noemen.

[Joerdgs]

Kan wel met Jonathan Blow's tirade op Twitter meekomen dat we niet nog een shading language nodig hebben.

[Wolfos]

Hij heeft ooit een hele presentatie gehouden dat alle software z'n eigen besturingssysteem moet implementeren want bugs.

Deze taal compileert, net als alles tegenwoordig, van en naar Spir-V. Als je nog steeds zo eigenwijs bent dat je zelf een game engine moet ontwikkelen dan pak je gewoon een project van Github die alles converteert. Deze is door Khronos ontwikkelt: https://github.com/KhronosGroup/SPIRV-Cross

[Reactie gewijzigd door Wolfos op 29 juli 2024 08:08]

[Snoitkever]

" Als je nog steeds zo eigenwijs bent dat je zelf een game engine moet ontwikkelen"

"pak je gewoon"

Aldus Wolfos, bekend als ontwikkelaar van gerenommeerde games als.... eh... wat precies?

Sorry gozer, maar je kan zeggen wat je wilt van Jonathan Blow, hij weet waar hij over praat. Er zijn ontzettend goede redenen om een eigen engine te ontwikkelen. Talloze bedrijven doen dit nog steeds heel bewust. En een tool als SPIR-V is ideaal voor simpeler projecten, maar er bestaan geen silver bullets voor complexe problemen als de wirwar en complexiteit van 3D rendering technologie.

[Wolfos]

Ja want Braid en The Witness zijn zo super geavanceerd dat je dat echt niet in een bestaande engine kan doen
Dat EA met een team van honderden een eigen engine schrijft okee, maar om het voor een 2D platformer te doen is tijdverspilling en levert echt geen kwaliteitsverschil op.

[Reactie gewijzigd door Wolfos op 29 juli 2024 08:08]

[Snoitkever]

> Lekker op de man spelen.
Dat is toch precies wat jij met Blow doet? Zeggen dat zijn keuze om een eigen engine te schrijven "eigenwijs" is, en niet een weloverwogen keuze van een professional met 10-20 jaar ervaring in de industrie.

> Dat EA met een team van honderden een eigen engine schrijft okee, maar om het voor een 2D platformer te doen is tijdverspilling en levert echt niks op.
Toch is dat wat bijvoorbeeld het kleine Nederlandse Ronimo heeft gedaan en met (commercieel) succes. Zelf nog een jaartje gewerkt. Hele goeie redenen om hun eigen engine te schrijven en helemaal niet zo moeilijk om dat te onderhouden. Heeft daarnaast ook vele voordelen tov een standaard engine waar je te maken hebt met miljoenen regels code die je:
- Niet snapt
- Niet geschreven zijn voor jou use-case
- Niet of slecht gedocumenteerd zijn
- Geen invloed op kan uitoefenen
- Voor 90% niet nodig hebt

Mensen overschatten hoeveel werk het is om een "engine" te schrijven. Sterker nog, de meeste mensen weten niet eens wat een engine is, en het is ook eigenlijk een heel lastig te definieren iets. Daarnaast heb je het over games uit 2008 en 2016 (begonnen in 2005/2006 en in 2008/2009 ergens). Destijds bestonden er amper licenseerbare engines en als ze bestonden gold het bovenstaande nog eens driedubbel. De wereld van nu (Unity/Unreal) is totaal onvergelijkbaar met de wereld van toen.

[Reactie gewijzigd door Snoitkever op 29 juli 2024 08:08]

[Wolfos]

De wereld van nu (Unity/Unreal) is totaal onvergelijkbaar met de wereld van toen.

We hebben het toch ook over nu? WebGPU is een nieuwe standaard.
De tijd dat je voor een kleine game een eigen engine schrijft is voorbij. Als je zo eigenwijs bent dat je dat nog steeds wilt doen moet je niet gaan klagen dat het moeilijk is. De technologie gaat vooruit. Je kunt niet meer alles in je eentje doen en gelukkig hoeft dat ook niet.

Mensen overschatten hoeveel werk het is om een "engine" te schrijven.

Een moderne engine met physically based rendering, een level editor, physics, een animatiesysteem, en weet ik veel wat nog meer?
Ik kan Unity downloaden, dat kost me 0 tijd, of ik kan het zelf gaan doen en ben dan 3 maanden bezig die ik ook aan de game had kunnen spenderen.

[Reactie gewijzigd door Wolfos op 29 juli 2024 08:08]

[armageddon_2k1]

Aldus de man die zelf een hele taal en compiler ontwikkelt omdat ie zich niet kan vinden in alle andere drieduizend talen en denkt dat ie een uniek probleem heeft wat een eigen taal benodigd. En vervolgens is de output gewoon weer een game. Niet eens een spectaculaire game, maar gewoon....een game.

Jonathan Blow is een slimme gozer, maar niemand forceert hem dit te gebruiken, dus snap z'n tirade niet zo.

[johnbetonschaar]

Ben het helemaal met je eens over Jonathan Blow en zijn eeuwige gerant op letterlijk alle moderne technologie. Hij heeft meestal wel een punt, maar vergroot dat vervolgens zo enorm uit, gooit 1001 andere dingen op 1 hoop en negeert alle pluspunten die de dingen waar hij op afgeeft heeft, en zaagt eindeloos door over hetzelfde. Best vermoeiend.

Dat gezegd hebbende is de hoofd reden dat hij zijn eigen taal gericht op game programming maakt volgens mij vooral omdat hij een hekel heeft aan C++ omdat het veel te complex is geworden, de compiler veel te traag, en er veel te veel cruft in de standaard zit die niet relevant (en vaak zelfs niet wenselijk) is voor game programming. Daar heeft hij wel een punt, hoewel je ook zou kunnen zeggen 'dan gebruik je die delen van C++ toch niet'. Maar het feit dat zijn eigen compiler letterlijk tientallen malen betere compile times haalt dan C++ compilers en daarbij allerhande interessante programmeerbare compile-time feedback and diagnostics features heeft geeft wel aan dat hij zeker niet volkomen ongelijk heeft...

[RangedNeedles]

Zonder dat ik uberhaupt ervaring heb met C++, ligt de traagheid van het compileren van C++-code niet bij de compiler dan? Als je je project compileert met, ik zeg maar wat, gcc, en het is traag, misschien dat Clang dan een oplossing biedt?

*edit*
Cool, bedankt voor de verheldering, @Snoitkever en @johnbetonschaar! Weer wat bijgeleerd

[Reactie gewijzigd door RangedNeedles op 29 juli 2024 08:08]

[Snoitkever]

Onder andere, maar C++ heeft fundamentele problemen die in het ontwerp van de taal zelf zitten. Deze maken het onmogelijk om snel te compileren. Als het beter en sneller kon bij C++ dan was het al lang uitgevonden

[johnbetonschaar]

Zoals @Snoitkever is dit voor C++ helaas geen oplosbaar probleem...

Het model van C++ is dat elke source file die je compileert als onafhankelijke 'translation unit' wordt behandeld, en daarbij al zijn afhankelijkheden mee trekt, dus alle header files die (recursief) #geinclude worden, etc. Al die code wordt voor elke translation unit opnieuw gecompileerd. Gooi je ook nog templates in de mix, dan genereert de compiler code voor elke template instantiate die je gebruikt, en ook dat moet allemaal weer gecompileerd worden. Schrijf je modern C++ en maak je gebruik van technieken als CRTP voor compile-time polymorphisme, dan is al snel bijna alles wat je schrijft automatisch een template. En dan zijn er nog trucs als SFINAE waarbij je template 'fouten' gebruikt om compile-time functies te restricten op eigenschappen van bijvoorbeeld de types die je in gooit. Wat de compiler doet als je zo'n functie aanroept is de template voor *alle* mogelijke versies van je functie om 'uit te proberen' welke er 'past'. Libraries als Boost gebruiken dit soort template metaprogramming soms met tientallen of honderden mogelijke overloads. Oh en aan het eind van de rit moet alles ook nog gelinked worden, wat ook absurd lang kan duren.

Anyway, om een lang verhaal kort te maken, zo lang je dat allemaal niet gebruikt dan valt het redelijk mee, maar het probleem is dat veel van deze features super handig zijn en allerhande voordelen hebben (compile time tijd inleveren voor minder run-time overhead, compactere code die makkelijker te onderhouden is, etc). En sinds C++11 en leunt ook de standard template library steeds meer op dit soort technieken.

Dat is waarom game programmers een hekel hebben aan 'modern C++' en liever 'orthodox C++' (ook wel 'C with classes') schrijven (geen enkel gebruik maken van alle moderne features), en vaak 'unity builds' gebruiken (in plaats van verschillende source files 1-voor-1 compileren, de code van je hele programma in 1 file #includen zodat je hem als 1 translation unit kan compileren). Dat kan allemaal maar dan mis je een hoop voordelen van de taal, en je introduceert weer allerhande andere problemen kwa maintenance en deployment.

Edit:
Er wordt overigens wel gewerkt aan 'workarounds' om dit soort problemen iets te beperken, bijvoorbeeld support voor 'modules' in C++20. Dan is het idee dat je code kunt schrijven die niet zijn afhankelijkheden niet door middel van #includes vastlegt, maar in termen van de interfaces van modules die de code wil aanroepen. De compiler hoeft dan alleen maar te controleren dat er ergens in de build een module is die voldoet, en hoeft dan niet alle headers van die module te gaan inladen en compileren. Dit lijkt veel meer op hoe talen als Java etc. werken. Maar heel veel dingen die je via templates kunt doen kun je niet in module interfaces gebruiken als ik het goed begrijp (heb er nog nooit serieus naar gekeken omdat er tot op de dag van vandaag nog maar beperkte support is voor C++20 en de voorstellen voor modules volgens mij pas een paar maanden geleden definitief geaccepteerd zijn).

[Reactie gewijzigd door johnbetonschaar op 29 juli 2024 08:08]

[EraYaN]

Alsof C++ compile time het probleem is bij C++...

[Snoitkever]

Eh.... ja? Onder andere? Als fulltime C++ dev zou ik heel veel over hebben als een project van enkele honderduizenden regels code in een aantal seconden zou compileren. Kortere feedback cycles zijn fantastisch.

[EraYaN]

Ik mag toch hopen dat jij je 100k regels code niet iedere keer opnieuw compileert? Dat moet je toch echt gaan verspreiden over meerdere compile units. (En niet te veel header-only libraries I guess)

[Snoitkever]

Als het in enkele seconden zou kunnen? Tuurlijk wel. Nu? Tuurlijk niet. Bazel, niet teveel header-only libraries, al dat soort dingen. Maar dat dat nodig is is juist mijn punt.

[EraYaN]

Al die andere snellere compilers doen het gewoon onder de motorkap alsnog, bij C++ is het proces nou gewoon eenmaal wat meer handmatig. Compiler software is niet perse magie, en zolang je niet echt modules kent in je taal en echte incrementele compiles kan doen is het het beste wat je er van kan maken. Maar mijn punt was meer dat er wel meer mis is met C++ wat ik dan denk een veel grotere impact heeft op de geproduceerde kwaliteit.

[johnbetonschaar]

Alsof C++ compile time het probleem is bij C++...

C++ is een van de traagste programmeer talen die er is om te compileren. Niet als je eenvoudige goed gemodulariseerde projectjes compileert zonder al te veel template metaprogramming en dergelijke, maar zo gauw je richting een klein beetje complexere en grotere code base gaat en 'modern C++' stijl code schrijft die vol zit met STL en boost code, dan wordt het al snel een enorm groot nadeel. Dan kan je wel zeggen dat je je source files anders moet indelen maar dat argument gaat dus niet op als je veel gebruik maakt van templates in header files die door veel verschillende modules gebruikt worden. Om maar een voorbeeld te geven: als ik maar een regel commentaar toevoeg aan de verkeerde header file in onze codebase op werk dan triggert dat een recompile op van een stuk of 100 files die allemaal bergen Boost header files binnen trekken, en dan zit je gewoon zomaar 2 minuten te wachten op een snel systeem.

Als je serieus stelt dat compile times geen probleem zijn bij C++ dan heb je of nog nooit met grotere codebases gewerkt die vol met (afhankelijkheden op) template code zitten, of je hebt nog nooit met talen gewerkt die ultrasnel compilen, live code compile/deploy mogelijk maken etc. Om een voorbeeld te noemen: ik ben alles behalve fan van de programmeertaal Java, maar compilatie is bij Java gewoon veel, veel sneller.

De compiler van Jonathan Blow zijn programmeertaal kan zichzelf compileren in een seconde of 5 geloof ik. Als ik g++ compileer op een retesnelle workstation dan zit ik denk ik een minuut of 30 te wachten.

[Joerdgs]

Oh je hebt helemaal gelijk, de ironie dat die z'n eigen programmeertaal aan het ontwikkelen is ontgaat me niet. Maar vind dat die nog steeds een punt heeft dat nog een shading language niet echt veel toevoegd aan het al overgroeide systeem van shading languages waar programmeurs mee verwacht worden te werken. Op hoeveel verschillende manieren kan je een GPU aansturen, echt?

[sympa]

Je kan beter vragen: op hoeveel manieren kan je data modelleren (driehoeken, voxels, exacte geometrie...), vermenigvuldigd met het aantal manieren om een beeld te vormen van die data (raytracing, texture mapping, schaduwberekening, reflection mapping) en vermenigvuldigd met de implementaties daarvoor.
Ik kan me voorstellen dat de shading-interface (en dus taal) hier af en toe een update nodig heeft, ja.

[mOrPhie]

Jaja, die man die z'n eigen programmeertaal maakt, omdat al het andere niet voor hem werkt? Ik mag de man graag en heb echt bewondering voor hoe hij sommige dingen aanpakt. Maar zijn tirades beginnen wel een beetje oud te worden. Hij moet echt oppassen dat mensen het niet zat worden en afhaken. Ik zit daar al tegenaan.

[SPee]

Ik heb hem even opgezocht, want ik kende de naam niet.
Ik heb blijkbaar wel een paar vlogs van hem bekeken, maar toen was ik het al zat.
Negatief zijn en klagen wanneer je iets uitlegt, dat was mij te deprimerend.

[Kun]

Zou dit misbruikt kunnen worden door websites om op de achtergrond cryptocurrencies te minen mbv de GPU?

[timwelter99]

Kan sowieso al met WebAssembly

[sspiff]

Maar niet op de schaal dat een GPU dat kan.

[timwelter99]

Zeker waar, maar XMR mining is nog steeds mogelijk via CPU. Lijkt mij dat een website met veel verkeer hier best wat mee kan verdienen.

[Wolfos]

Aangezien er gebruik gemaakt kan worden van compute shaders denk ik dat wel ja.

[The Zep Man]

Mits het zoiets wordt als OpenGL/WebGL, Vulkan, Direct3D, ... Onwaarschijnlijk. De API is daarvoor te beperkt en afgesloten. Het gaat dan echt exclusief om vooraf gedefinieerde grafische berekeningen.

Als het wel kan, dan zie ik de volgende permissie pop-up alwaar verschijnen.

[Reactie gewijzigd door The Zep Man op 29 juli 2024 08:08]

[mOrPhie]

Met double precision in pixel shaders kan dit in theorie nu al. Punt is volgens mij dat dergelijke botnets (zo noem ik ze maar even) juist onopvallend willen opereren en daarom vooral mikken op horizontaal schalen.

[Mitsuko]

Vulkan, Direct3D 12 en Metal zijn allemaal APIs die wat dichter bij de hardware zitten dan bijvoorbeeld Direct3D 11 en OpenGL, dus lijkt me dat je het verschil tussen WebGPU en WebGL vooral daarin moet zoeken.

Of zie ik dat verkeerd en is het meer zo dat OpenGL een aantal specifieke eigenaardigheden heeft in tegenstelling tot de gemeenschappelijke kwaliteiten van Vulkan, Direct3D 12 en Metal?