WebGPU kao nova zajednička baza za 3D web
Dolazak WebGPU‑a u sve glavne preglednike – Chrome, Edge, Firefox i Safari – označava prvu fazu stvarno univerzalne GPU apstrakcije na webu. WebGPU donosi moderan, eksplicitniji pristup GPU‑u, bliži Vulkanu, D3D12 i Metal API‑jima nego klasičnom OpenGL‑u. Time se web po prvi put ozbiljno približava nativnim engineima po mogućnostima i kontroli nad hardverom.
Ipak, to ne znači da WebGL nestaje. U produkcijskim projektima WebGL ostaje zreli, stabilni sloj kompatibilnosti. Godine iskustva, brojni workaroundi za drivere i široka baza uređaja čine WebGL 2 i dalje najnižom zajedničkom razinom na koju se timovi mogu osloniti kada ciljaju masovno tržište. WebGPU zasad otvara vrata prvenstveno novim generacijama alata, specijaliziranim vizualizacijama i use‑caseovima visokih performansi.
Stanje u engineima: WebGL kao baza, WebGPU kao paralelni back‑end
Three.js: evolucija, ne revolucija
Three.js ostaje de facto standard za 3D grafiku u pregledniku. Njegov WebGL renderer je stabilan, dobro dokumentiran i podržan na velikom broju uređaja – od starijih laptopa do mobilnih preglednika. U novijim izdanjima tim uvodi i eksperimentalni WebGPU renderer.
U praksi to znači da je isti scene graph moguće renderirati kroz dvije različite putanje: klasični WebGL renderer i novi WebGPU renderer. Za jednostavnije vizualizacije, dashboarde i lagane interaktivne scene, WebGL ostaje preporučeni default. Za zahtjevnije efekte – napredne PBR materijale, volumetriju, kompleksne post‑proces lance ili veći broj instanci – WebGPU renderer se koristi kao opt‑in za podržane konfiguracije.
Babylon.js: dvostruki shadere i fleksibilan pipeline
Babylon.js je otišao korak dalje. S novijim verzijama jezgreni shadere prelaze na dvostruki režim: GLSL za WebGL 2 i WGSL za WebGPU. Time ista scena, s istim materijalima i istom poslovnom logikom, može ciljati dva različita grafička back‑enda bez dupliciranja scene ili game logike.
Tipičan tijek rada u Babylon.js‑u danas izgleda ovako: aplikacija pri startu detektira dostupnost WebGPU‑a, pokuša inicijalizirati WebGPU engine, a u slučaju neuspjeha ili nepodržane konfiguracije elegantno pada natrag na WebGL 2. Za korisnika je iskustvo transparentno; za tim to znači jedan kodni bazen s dva render back‑enda.
Ovaj pristup usvajaju i drugi enginei i biblioteke. Fokus je na apstrakciji render sloja, gdje se scene i resursi definiraju neovisno o tome hoće li se na kraju koristiti WebGL ili WebGPU pipeline.
Performanse: kako univerzalni WebGPU mijenja planiranje optimizacije
Od smanjivanja draw callova do eksplicitnog GPU rada
U WebGL svijetu optimizacija se tradicionalno svodi na agresivno smanjivanje draw callova, batchiranje geometrije, instancing i ručno upravljanje bufferima. Sve to ostaje relevantno, ali WebGPU otvara nove mogućnosti. Uz značajke poput render bundleova, efikasnijeg upravljanja memorijom i eksplicitnog definiranja render passova, veći dio workload‑a može se strukturirano prebaciti na GPU bez nepotrebnog CPU overheada.
Primjer iz prakse: kompleksna arhitektonska vizualizacija s tisućama objekata. U WebGL‑u se tim često odlučuje na bakeanje svjetla, spajanje statičnih meshova i smanjenje rezolucije tekstura kako bi zadržao prihvatljiv FPS na slabijim uređajima. Uz WebGPU back‑end moguće je zadržati sličnu razinu detalja, ali koristiti efikasnije upravljanje uniform bufferima, bolji frame pacing i naprednije tehnike cullinga, uz manji CPU bottleneck.
Fragmentirana dostupnost i praktična donja granica
Čak i uz službenu podršku u svim glavnim preglednicima, dostupnost WebGPU‑a i dalje je fragmentirana. Na nekim mobilnim platformama WebGPU je još uvijek iza flagova, na starijim GPU‑ima oslanja se na slojeve kompatibilnosti, a korporativna okruženja često kasne s nadogradnjom preglednika.
Posljedica je jasna: WebGL 2 ostaje praktični minimum za masovno dostupne 3D aplikacije. Dizajn scena, rezolucija tekstura, složenost shader pipelinea i ciljani FPS i dalje se moraju planirati tako da aplikacija bude upotrebljiva i na WebGL‑u. WebGPU se u tom scenariju koristi kao dodatni turbo sloj, a ne kao jedini stup aplikacije.
Strategije migracije za postojeće WebGL projekte
1. Jasna separacija render sloja
Prvi korak u tranziciji prema WebGPU‑u je čista separacija render sloja od ostatka aplikacije. Poslovna logika, stanje igre ili simulacije, senzori, mrežna komunikacija i scene trebaju biti definirani neovisno o konkretnoj grafičkoj implementaciji.
U praksi to znači uvođenje apstraktnog sučelja za renderer: metode za učitavanje geometrije, kreiranje materijala, upravljanje teksturama, definiranje render passova i post‑proces lanca. Iza tog sučelja mogu postojati dvije implementacije – WebGL renderer i WebGPU renderer – koje dijele isti scene graph i resurse.
2. Hibridni pristup: WebGL za prikaz, WebGPU za skupe zadatke
Drugi korak je hibridni pristup. Umjesto da se cijela aplikacija preko noći prebaci na WebGPU, timovi mogu WebGPU iskoristiti za specifične, skupe zadatke, dok osnovni prikaz i dalje ide kroz WebGL.
Tipični primjeri:
- post‑proces efekti visoke rezolucije (bloom, depth of field, temporalni anti‑aliasing) koji se izvršavaju kao compute zadaci u WebGPU‑u, dok WebGL renderira glavni pass;
- fizičke simulacije čestica, tkanine ili fluida koje se računaju na GPU‑u putem WebGPU compute pipelinea, a rezultati se zatim vizualiziraju u WebGL‑u;
- AI inference na rubu (edge uređaji) – npr. prepoznavanje gesta ili objekata u realnom vremenu – gdje WebGPU preuzima ulogu akceleratora, a WebGL služi za prikaz rezultata na dashboardu ili u AR sceni.
Ovakav pristup omogućuje da se WebGPU uvodi postupno, ciljano i mjerljivo, bez rizika za korisnike na starijim konfiguracijama.
3. Ciljano testiranje po preglednicima i platformama
Treći korak je sustavno testiranje. Činjenica da je WebGPU „podržan” u određenom pregledniku ne znači da je uvijek dostupan i uključen po defaultu na svim kombinacijama OS‑a, GPU‑a i sigurnosnih politika.
Preporučeni workflow uključuje:
- detekciju WebGPU podrške pri inicijalizaciji (feature detection, ne user‑agent heuristike);
- telemetriju o stvarnim korisničkim konfiguracijama (koji GPU, koji driver, koji preglednik);
- A/B testiranje WebGL‑only i hibridnih WebGL + WebGPU putanja za usporedbu FPS‑a, frame pacinga i stabilnosti;
- fallback mehanizme koji na razini gatewaya ili edge uređaja mogu prisilno isključiti WebGPU za problematične kombinacije hardvera.
Što WebGPU znači za WebGL developere
Znanje WebGL‑a ostaje temeljno
Za developere koji već rade s WebGL‑om, poruka je dvostruka. S jedne strane, postojeće znanje i dalje je vrlo vrijedno. Koncepti poput vertex i fragment shader pipelinea, PBR modela osvjetljenja, normal mapa, HDR ton‑mappinga i optimizacijskih obrazaca (instancing, frustum culling, LOD) gotovo se izravno prenose u WebGPU svijet.
Veliki enginei će još godinama nuditi WebGL kao prvi stupac podrške, upravo zato što ogromna baza uređaja i dalje ne može isporučiti dosljedan WebGPU doživljaj. Projekti u obrazovanju, industriji, medicinskoj vizualizaciji ili IoT dashboardima često imaju stroge zahtjeve za kompatibilnošću, gdje je WebGL siguran izbor.
Vrijeme je za učenje WebGPU idiomâ
S druge strane, sada je pravi trenutak početi usvajati WebGPU idiome. Važno je razumjeti razlike u prostoru koordinata (npr. dubinski raspon i NDC konvencije), eksplicitno upravljanje resursima (bind grupe, bufferi, teksture) i konfiguraciju pipelinea (render passovi, compute passovi, layouti).
Praktični koraci za WebGL developera:
- prepisati jednostavan WebGL demo u WebGPU (rotirajući cube, PBR kugla) kako bi se upoznale razlike u API‑ju;
- istražiti kako Three.js i Babylon.js strukturiraju svoje WebGPU back‑endove te kako rješavaju dvostruke shadere (GLSL + WGSL);
- učiti uz konkretne use‑caseove: npr. maleni compute shader za simulaciju čestica ili jednostavan deferred rendering pass;
- razumjeti kako se WebGPU uklapa u širi pipeline – od učitavanja podataka s gatewaya i edge uređaja, preko pripreme bufferâ, do konačnog framea u pregledniku.
Oni koji već danas restrukturiraju svoje WebGL projekte u smjeru apstraktnog render sloja imat će znatno lakši prijelaz na hibridne ili potpuno WebGPU‑temeljene 3D web aplikacije u sljedećih nekoliko godina.
Praktična budućnost: koegzistencija, ne zamjena
U bliskoj budućnosti realan scenarij je koegzistencija WebGL‑a i WebGPU‑a. WebGL ostaje univerzalni, stabilni cilj za široku publiku. WebGPU postaje izbor za projekte koji trebaju vrhunske performanse, napredne efekte, kompleksne simulacije ili GPU‑akcelerirane AI zadatke, ali mogu prihvatiti nešto uži skup podržanih uređaja.
Za timove koji planiraju nove projekte, ključ je u dizajnu arhitekture: od prvog dana razdvojiti scene, logiku i render sloj, predvidjeti hibridne pipelineove i u plan optimizacije ugraditi i WebGL i WebGPU. Time se rizik smanjuje, a mogućnosti rasta – kada WebGPU sazrije na svim platformama – ostaju otvorene.
Univerzalni WebGPU ne znači kraj WebGL‑a, nego početak nove faze u kojoj web grafika konačno dobiva puni pristup modernom GPU‑u, dok WebGL nastavlja služiti kao robusni most prema najširem mogućem spektru uređaja.
