WebGPU je „svugdje”, ali WebGL još ne odlazi
Službena objava da je WebGPU sada podržan u svim glavnim preglednicima – Chromeu, Edgeu, Firefoxu i Safariju – sugerira da je vrijeme WebGL‑a pri kraju. Na papiru, WebGPU donosi moderniji grafički API, bliži Vulkanu, DirectX 12 i Metal API‑jima. U stvarnim projektima, međutim, slika je složenija.
Timovi koji rade s Three.js, Babylon.js, PlayCanvasom ili vlastitim engineima i dalje često otkrivaju da dobro optimiziran WebGL renderer daje stabilnije ili čak brže rezultate od ranih WebGPU implementacija u istim scenarijima. Razlog nije samo u razlici između dva API‑ja, nego u cijelom sloju iznad: bibliotekama, alatima, preglednicima i navikama timova.
Važno je razumjeti da je WebGL rezultat više od desetljeća iteracija, optimizacija i prilagodbi za desktop i mobilne GPU‑ove. WebGPU je, nasuprot tome, još uvijek u fazi uhodavanja. Driveri, preglednici i enginei tek uče kako najbolje iskoristiti novi pipeline.
Zašto WebGPU u praksi nije uvijek brži
U diskusijama u Three.js i Babylon.js zajednicama ponavlja se isti obrazac: WebGPU u realnim produkcijskim scenama često ne ostvaruje očekivani „besplatni“ skok performansi. U sintetičkim benchmarkovima i specifičnim compute primjerima WebGPU briljira, ali u tipičnim 3D web iskustvima – konfiguratorima, vizualizacijama, casual igrama – razlika je često mala ili negativna.
Batchiranje draw poziva i upravljanje bufferima
Jedan od ključnih razloga su razlike u strategijama batchiranja draw poziva i upravljanju bufferima. WebGL enginei imaju godinama usavršavane tehnike smanjenja broja draw callova: agresivno instancing, dinamično spajanje geometrije i pažljivo sortiranje objekata po materijalima i shaderima.
WebGPU daje veću kontrolu nad bufferima, layoutima i pipeline objektima, ali ta fleksibilnost dolazi uz cijenu. Loše dizajnirana strategija alokacije i ažuriranja buffer objekata može stvoriti više overheada nego u „starom“ WebGL modelu. U praksi se često događa da rani WebGPU renderer iz enginea napravi više malih buffer updateova i state promjena nego što je to činio WebGL renderer, što izravno udara na FPS i frame pacing.
Validacija stanja i stroža pravila
Drugi sloj problema je validacija. WebGPU ima stroža pravila oko atributa, layouta shadera, bind grupa i kompatibilnosti pipelinea. Preglednici u ranim fazama implementacije često provode opsežnu provjeru stanja na CPU‑u kako bi osigurali sigurnost i ispravnost.
Ta validacija je nužna, ali nije besplatna. U složenim scenama s više rendering passova, shadow mapa, post‑proces efekata i UI overlaya, dodatni troškovi validacije lako pojedu dio dobitka od efikasnijeg GPU pipelinea. Posebno je to vidljivo na slabijim CPU‑ima i mobilnim SoC‑ovima.
Mobilni uređaji: najosjetljiviji poligon
Mobilni uređaji dodatno naglašavaju razliku između teorije i prakse. Iako mnogi moderni telefoni deklarativno podržavaju WebGPU, realne performanse ovise o kombinaciji GPU arhitekture, drivera, verzije OS‑a i verzije preglednika.
U praksi, na istom uređaju često vidimo sljedeći obrazac:
- WebGL renderer drži stabilnih 30–60 FPS uz povremene spikeove.
- WebGPU renderer ima sličan prosječni FPS, ali češće pati od micro‑stuttera i nestabilnog frame pacinga.
- CPU opterećenje je niže na WebGPU u jednostavnim scenama, ali u kompleksnim scenama raste zbog validacije i dodatne logike u engineu.
Za korisnika je važniji doživljaj glatkoće nego prosječni FPS. Ako WebGPU donosi više micro‑zastajkivanja, WebGL će subjektivno djelovati „brže“, iako benchmarkovi kažu suprotno.
Kako enginei evoluiraju: primjer Babylon.js 8.0
Unatoč izazovima, WebGPU već sada gura cijeli ekosustav naprijed. Jedan od najboljih primjera je Babylon.js 8.0, koji uvodi fleksibilniji render pipeline kroz Node Render Graph i optimizirani rad sa shaderima.
Node Render Graph i strukturirani pipeline
Node Render Graph omogućuje definiciju rendering pipelinea kao grafa čvorova i veza. Svaki čvor predstavlja određeni rendering pass ili fazu obrade: geometriju, shadow mape, refleksije, post‑proces, UI sloj. Umjesto monolitnog koda, pipeline postaje eksplicitna struktura koju je lakše profilirati, optimizirati i mijenjati.
Iako je motivacija dijelom WebGPU – jer novi API traži jasnije definirane resurse i korake – korist imaju i čisto WebGL projekti. Bolje strukturirani pipeline znači:
- lakše isključivanje ili spajanje render passova ovisno o platformi,
- transparentniji profil performansi po čvoru,
- preciznije upravljanje memorijom i teksturama.
GLSL, WGSL i upravljanje shaderima
Babylon.js jezgra sada učinkovitije barata shaderima, balansirajući između GLSL‑a za WebGL i WGSL‑a za WebGPU. To uključuje:
- bolju podjelu zajedničke logike shadera,
- manje dupliciranog koda za različite backendove,
- optimiziran build proces i manje bundleove.
Za timove koji još ne planiraju aktivno koristiti WebGPU, ove promjene i dalje donose direktne benefite. Brže učitavanje, manji bundle, jasnije granice između materijala, efekata i pipeline koraka – sve to poboljšava i klasični WebGL projekt.
Praktične smjernice: kako danas donositi odluke
Za timove koji danas moraju odlučiti hoće li investirati u WebGPU, najrazumniji pristup je tretirati ga kao dodatni backend, a ne kao zamjenu preko noći. To znači postaviti WebGL kao stabilnu osnovu, a WebGPU kao opt‑in za korisnike i scenarije gdje se može izmjeriti stvarni dobitak.
Prvo iscijediti maksimum iz WebGL‑a
Prije prelaska na WebGPU, ima smisla provesti klasičnu WebGL optimizaciju. Ključni koraci uključuju:
- Instancing: koristiti instanced draw pozive za ponavljajuće objekte (drveće, zgrade, čestice) umjesto tisuća pojedinačnih draw callova.
- Upravljanje teksturama: konsolidirati teksture u atlase gdje je moguće, optimizirati rezolucije i formate (sRGB, komprimirani formati), paziti na mipmaping.
- Profiliranje draw poziva: mjeriti koliko draw callova je stvarno potrebno po frameu, identificirati materijale ili efekte koji generiraju eksploziju draw callova.
- Redukcija overdrawa: paziti na transparentne objekte, layering UI elemenata i efekte koji renderiraju više puta iste piksele.
U mnogim projektima se pokaže da je moguće dobiti 20–50% boljih performansi samo kroz discipliniran rad unutar WebGL‑a, bez ikakvog WebGPU koda.
Gdje WebGPU ima smisla već danas
WebGPU ima jasne prednosti u određenim klasama problema. Isplati ga se uključiti selektivno, u scenarijima kao što su:
- Kompleksni compute zadaci: fizika čestica, napredni simulacijski sustavi, prilagođeni post‑proces filteri koji koriste compute shadere.
- Masivne količine geometrije: CAD modeli, digitalni tvornice, vizualizacije gradova s desecima milijuna trokuta.
- Napredni PBR materijali: složeni BRDF modeli, više slojeva materijala, realistična raspršenja i volumetrija.
U takvim slučajevima, dodatni trud oko WebGPU pipelinea i WGSL‑a može donijeti mjerljive dobitke, osobito na desktop GPU‑ovima i novijim laptopima.
Sigurnost, stabilnost i brzina promjena
Još jedan faktor koji se ne smije zanemariti je sigurnost. Nedavne sigurnosne zakrpe za WebGPU u glavnim preglednicima pokazuju da je implementacija još uvijek u intenzivnom razvoju. API je standardiziran, ali detalji ponašanja, driver workaroundi i zaštitni mehanizmi se i dalje mijenjaju.
Za ozbiljne 3D web projekte to znači da je nužno:
- pratiti release noteove preglednika,
- redovito testirati ključne scene na više platformi,
- planirati fallback strategije kada WebGPU nije dostupan ili je nestabilan.
WebGL, iako stariji, u ovom je trenutku predvidljiviji. Većina kritičnih sigurnosnih i stabilnosnih problema je poznata i adresirana, a ponašanje je relativno konzistentno kroz različite platforme.
Hibridna budućnost: WebGL kao baseline, WebGPU kao opt‑in
U sljedećih godinu do dvije, najrealniji obrazac bit će hibridan. Ozbiljni 3D web projekti održavat će WebGL kao „baseline“ renderer za maksimalnu kompatibilnost i predvidljive performanse, dok će WebGPU služiti kao dodatni backend za korisnike na modernom hardveru i preglednicima.
Tipična arhitektura hibridnog enginea
U praksi, hibridni engine često izgleda ovako:
- Jedan zajednički sloj scene: objekti, materijali, svjetla, kamere, animacije.
- Dva render backenda: WebGL i WebGPU, s maksimalno zajedničkim dijelom logike.
- Detekcija podrške pri pokretanju: ako je WebGPU dostupan i označen kao stabilan, korisniku se nudi opcija ili se automatski odabere WebGPU; u suprotnom se koristi WebGL.
- Telemetrija i A/B testiranje: prikupljanje podataka o FPS‑u, frame pacingu i greškama za oba backenda kako bi se odluke temeljile na stvarnim metrikama.
Takav pristup omogućuje da se WebGPU uvodi postupno, bez prisiljavanja svih korisnika na novi pipeline koji još uvijek sazrijeva.
Tko će profitirati od ranog ulaganja u WebGPU
Timovi koji sada ulože vrijeme u razumijevanje gdje WebGL još uvijek briljira – i gdje WebGPU donosi stvarni pomak – imat će najstabilniju tranziciju kada WebGL napokon prestane biti zadani izbor. To uključuje:
- izgradnju internog znanja o WGSL‑u i WebGPU pipelineu,
- postavljanje alata za profiliranje i debugiranje na oba backenda,
- razvoj arhitekture koja minimizira dupliranje koda između WebGL i WebGPU renderera.
Za većinu produkcijskih timova, cilj nije „prebaciti sve na WebGPU što prije“, nego „planirano uvesti WebGPU tamo gdje ima smisla, bez žrtvovanja stabilnosti i pokrivenosti uređaja“.
Zaključak: performanse su i dalje neintuitivne
WebGPU je važan korak za web kao platformu za visoko zahtjevnu 3D grafiku i compute zadatke. No, unatoč tome što je sada podržan u svim glavnim preglednicima, stvarne performanse i dalje su neintuitivne. Rani WebGPU renderer u popularnom engineu često neće automatski nadmašiti zreli WebGL renderer koji je godinama optimiziran za iste scenarije.
Najzdraviji pristup danas je prihvatiti hibridni model: WebGL kao stabilan, provjeren „baseline“ i WebGPU kao dodatni, strateški korišten backend. Timovi koji pažljivo mjere, profiliraju i iteriraju na oba fronta bit će u najboljoj poziciji kada se ravnoteža konačno trajno pomakne u korist WebGPU‑a.
