WebGPU je stigao, ali WebGL još ne silazi s trona
Krajem 2025. WebGPU je napokon dostupan u svim glavnim preglednicima. Edge, Chrome, Firefox i Safari nude stabilnu podršku, a WebGPU se u dokumentaciji i prezentacijama sve češće ističe kao novi standard za 3D grafiku i računalno intenzivne zadatke u pregledniku.
Međutim, rasprave u Three.js zajednici, GitHub issueima i na forumima pokazuju drukčiju sliku kada se pogleda stvarna produkcija. U mnogim konkretnim scenarijima, pogotovo u kompleksnim Three.js aplikacijama, stari WebGLRenderer i dalje ostvaruje stabilniji i predvidljiviji FPS od novog WebGPURenderera.
To nije samo konzervativnost developera. Benchmark scene s tisućama i desecima tisuća mesh objekata, složenim materijalima i velikim brojem draw callova otkrivaju slučajeve u kojima WebGLRenderer postiže višestruko veći FPS na istom hardveru i u istom pregledniku.
Benchmarkovi: kada WebGLRenderer još uvijek pobjeđuje
Tipičan test koji se danas dijeli u Three.js zajednici izgleda ovako: scena s 10 000 do 50 000 mesh objekata, bez instanciranja, s nekoliko različitih materijala i jednostavnim shaderima. U pozadini radi animacija kamere ili lagani pomak objekata kako bi GPU i CPU ostali aktivni.
U takvim scenarijima, brojke su iznenađujuće za one koji očekuju da će WebGPU automatski nadmašiti WebGL. Na istom računalu, WebGLRenderer često drži, primjerice, 60 FPS, dok WebGPURenderer padne na 15–20 FPS. U nekim prijavljenim slučajevima razlika je i do četiri puta u korist WebGL-a.
Ključni uzorak je uvijek sličan:
- velik broj ne-instanciranih mesh objekata
- mnogo render-itema u internom render pipelineu
- više materijala i shader varijanti
- česti state changeovi i draw callovi
U teoriji, WebGPU bi trebao bolje podnijeti ovakve slučajeve zahvaljujući modernijem dizajnu API-ja i nižem CPU overheadu. U praksi, trenutna implementacija WebGPURenderera u Three.js-u još nije dovoljno optimizirana za ove ekstremne scenarije. Rezultat je veći CPU overhead po render-itemu nego u WebGLRendereru, što direktno ruši FPS.
UBO sustav i CPU overhead: gdje WebGPU danas gubi
Jedan od konkretnih tehničkih problema koji se često spominje je implementacija uniform buffer objekata (UBO) u WebGPURendereru. U WebGPU svijetu uobičajeno je grupirati podatke o materijalima, transformacijama i svjetlima u uniform buffere i bind grupe. To bi, u idealnom slučaju, trebalo smanjiti broj pojedinačnih poziva prema GPU-u.
U trenutnoj Three.js implementaciji, međutim, za scene s velikim brojem render-itema dolazi do neočekivano visokog CPU overheada:
- svaki render-item generira vlastite upise u UBO ili bind grupe
- učestalo se ažuriraju bufferi i strukture podataka
- javlja se dodatna logika za sinkronizaciju stanja između CPU-a i GPU-a
To znači da prednost WebGPU API-ja ostaje „zaključana” iza neoptimalnog koda u višem sloju. API je moćniji, ali način na koji ga Three.js trenutno koristi troši previše CPU vremena po draw callu. U usporedbi s time, WebGLRenderer ima godinama polirane code pathove, specijalne optimizacije za tipične Three.js uzorke scena i predvidljiviji raspored rada unutar jednog rendering passa.
Praktična posljedica za developere je jasna: nije dovoljno samo prebaciti isti Three.js projekt s WebGLRenderer na WebGPURenderer i očekivati automatski dobitak. U mnogim slučajevima rezultat je suprotan, barem dok se ne prilagodi struktura scene, način grupiranja objekata i strategija ažuriranja uniform podataka.
Profiliranje performansi: od stats-gl do GPU timestamp queryja
Promjena renderera donosi i promjenu alata. WebGL ekosustav je godinama živio sa stats.js i kasnije stats-gl panelom, koji u gornjem kutu prikazuju FPS, broj draw callova i osnovne metrike. Za brzu procjenu performansi to je često bilo dovoljno.
S WebGPU-om situacija se mijenja. Novi Three.js primjeri koji koriste WebGPURenderer uglavnom više nisu kompatibilni sa stats-gl. Umjesto toga, autori preporučuju korištenje ugrađenog Inspectora koji koristi GPU timestamp queryje. Taj pristup omogućuje detaljniji uvid u to koliko vremena GPU stvarno provodi u pojedinom rendering passu, koliko traje određeni pipeline state i gdje nastaju uska grla.
Međutim, u WebGL2 kontekstu taj sustav još uvijek ima ograničenja. Ne rade svi GPU timestamp queryji jednako pouzdano na svim platformama, a stariji projekti i dalje se uvelike oslanjaju na:
- klasične FPS overlaye (stats.js, stats-gl)
- ručno mjerenje performansi kroz Performance API
- profilere u devtoolsima preglednika
Za timove koji održavaju dugačak niz WebGL projekata, prelazak na novi alatni lanac znači dodatno vrijeme za učenje i prilagodbu. To je još jedan razlog zašto mnogi produkcijski timovi kratkoročno ostaju na WebGLRendereru, čak i kada eksperimentiraju s WebGPU-om u odvojenim granama repozitorija.
Gdje WebGPU već danas pobjeđuje
Unatoč navedenim problemima, WebGPU već sada donosi jasne prednosti u određenim tipovima zadataka. Najčešće spominjani primjeri su:
- compute shaderi za fiziku i simulacije
- obrada velikih setova podataka na GPU-u
- napredni post-processing s više rendering passova
- kompleksne PBR pipeline konfiguracije s puno tekstura i buffer objekata
U takvim slučajevima, arhitektura WebGPU-a omogućuje niži CPU overhead po operaciji, bolje upravljanje memorijom i finiju kontrolu nad pipelineom. Primjerice, simulacije čestica s milijunima particla, koje u WebGL-u zahtijevaju niz trikova sa shaderima i teksturama, u WebGPU-u se mogu implementirati izravno kroz compute pipeline.
Za Three.js developere to znači da WebGPURenderer ima smisla u projektima gdje je fokus na:
- naprednim efektima (fluidne simulacije, volumetrija, složeni post-processing)
- GPU-ubrzanoj analitici i vizualizaciji podataka
- eksperimentalnim grafičkim tehnikama koje teško stanu u WebGL ograničenja
Ali i u tim slučajevima, većina timova još uvijek zadržava WebGLRenderer kao fallback za uređaje i preglednike s ograničenim ili problematičnim WebGPU implementacijama.
Zašto je WebGLRenderer i dalje „radni konj” 3D weba
Razlog zbog kojeg WebGL krajem 2025. i dalje pobjeđuje u mnogim stvarnim Three.js projektima nije samo navika. Radi se o kombinaciji faktora:
- zrelost koda – WebGLRenderer je godinama optimiziran, s brojnim specijalnim slučajevima i cache mehanizmima
- stabilan FPS – za tipične scene s puno draw callova i standardnim materijalima, frame pacing je predvidljiv
- široka kompatibilnost – od starijih laptopa do integriranih GPU-ova, WebGL je provjeren
- poznati alati – profiliranje, debug i monitoring su dobro uhodani
Za produkcijske timove, ključni cilj nije nužno maksimalni teoretski throughput, već stabilan FPS na što većem broju uređaja. Kada dashboardi, konfiguratori proizvoda, 3D preglednici ili edukativne aplikacije moraju raditi jednako dobro u korporativnim okruženjima, školama i na kućnim računalima, konzervativni odabir WebGLRenderera još uvijek ima snažnu poslovnu logiku.
Preporučena strategija: hibridni pristup i paralelno testiranje
U praksi se sve više timova odlučuje za hibridnu strategiju. Novi projekti se od početka dizajniraju s WebGPU-om na umu, ali se WebGLRenderer zadržava kao stabilni baseline.
Tipičan pristup izgleda ovako:
- u glavnoj produkcijskoj grani projekta koristi se WebGLRenderer
- u zasebnoj grani ili feature flagu eksperimentira se s WebGPURendererom
- provode se usporedna mjerenja FPS-a, CPU i GPU vremena, broja draw callova
- analiziraju se konkretne scene gdje WebGPU donosi dobitak i gdje gubi
Na temelju tih podataka, timovi odlučuju hoće li:
- zadržati WebGL kao primarni renderer i WebGPU kao opcijski „high-end” mod
- postupno prebacivati dijelove aplikacije na WebGPU (npr. samo određene simulacije)
- čekati daljnje optimizacije WebGPURenderera prije potpunog prelaska
Ovakav pristup smanjuje rizik, a istovremeno omogućuje da se tim pripremi za budućnost u kojoj će WebGPU vjerojatno postati dominantan.
Što očekivati u idućim godinama
Razvoj WebGPURenderera u Three.js-u je intenzivan. Očekuje se da će se u narednim verzijama:
- optimizirati UBO sustav i smanjiti CPU overhead po render-itemu
- uvesti agresivnije batching i instancing strategije u WebGPU backend
- proširiti i stabilizirati alati za profiliranje i debug, uključujući GPU timestamp queryje
- riješiti specifični bugovi vezani uz pojedine GPU drivere i preglednike
Kako se ti problemi budu rješavali, omjer će se postupno okretati u korist WebGPU-a, posebno u projektima koji ciljaju na moderniji hardver i zahtjevnije grafičke efekte.
Ipak, stanje krajem 2025. ostaje jasno: u realnim, komercijalnim 3D web aplikacijama, WebGLRenderer još uvijek vrlo konkretno demonstrira zašto ostaje ključni radni konj 3D weba. WebGPU je budućnost, ali WebGL je i dalje sadašnjost.
