Što je WebGPU compatibility mode u Chromeu?
Chromeov WebGPU tim radi na novom sloju kompatibilnosti koji cilja uređaje bez podrške za moderne niskorazinske API‑je poput Direct3D 12 ili Vulkan 1.1. Taj sloj nazivaju WebGPU compatibility mode.
Ideja je jednostavna: omogućiti da WebGPU aplikacije rade i na starijem ili slabijem hardveru, ali bez da preglednik odustane od postojećih grafičkih drivera. Umjesto D3D12 ili Vulkan backenda, WebGPU se u tom modu mapira na D3D11 ili OpenGL ES. U praksi, to znači da se postojeći WebGL ekosustav i dalje koristi kao temeljni transportni sloj za starije GPU‑ove.
Za krajnjeg korisnika to izgleda kao „radi ili ne radi”. No za developere i engine autore, compatibility mode mijenja način na koji razmišljaju o podršci za stariji hardver, verzije API‑ja i fragmentaciju drivera.
Kako WebGPU koristi postojeće WebGL drivere
WebGL je godinama bio primarni 3D API na webu. Ispod haube, preglednici su WebGL pozive prevodili na D3D11, OpenGL ili OpenGL ES. Taj sloj je stabilan, battle‑tested i dobro profiliran na širokom spektru GPU‑ova i operacijskih sustava.
WebGPU compatibility mode ne pokušava taj sloj zamijeniti preko noći. Umjesto toga, koristi ga kao najniži zajednički nazivnik. WebGPU API na vrhu, WebGL‑kompatibilni driveri na dnu.
Tipičan put podataka izgleda ovako:
- Aplikacija koristi WebGPU API (bufferi, render passovi, compute passovi, pipeline objekti).
- Chromeov WebGPU sloj odlučuje može li koristiti „pravi” backend (D3D12/Vulkan/Metal).
- Ako ne može, aktivira se compatibility mode koji prevodi WebGPU operacije u skup operacija koje postojeći D3D11 ili OpenGL ES driver razumije.
Time WebGL više nije direktno izložen aplikacijskom kodu, ali ostaje ključan kao infrastrukturni sloj za stariji hardver. Preglednik preuzima odgovornost za prijevod između modernog modela resursa i pipelinea te starijih API paradigmi.
Što to znači za WebGL developere
Za WebGL developere najveći problem posljednjih godina nije bio sam API, nego fragmentacija. Potreba za održavanjem paralelnih kodnih baza:
- WebGL 1 renderer za starije uređaje i preglednike.
- WebGL 2 renderer za modernije GPU‑ove.
- Početni WebGPU renderer za nove projekte i eksperimentalne značajke.
Svaka od tih grana ima vlastiti shader kod, vlastite optimizacije i vlastite bugove vezane uz drivere. Testiranje i profiliranje se množi s brojem renderera.
S WebGPU compatibility modeom, cilj je prebaciti taj teret s aplikacijskog koda na preglednik. Developeri mogu:
- primarno ciljati WebGPU API kao jedinstvenu ulaznu točku,
- dozvoliti pregledniku da odluči koristi li nativni WebGPU backend ili compatibility backend,
- smanjiti broj paralelnih codepathova i specifičnih WebGL detekcija na strani aplikacije.
WebGL tako evoluira iz „ciljne platforme” u ulogu infrastrukturnog sloja. I dalje je ključan za starije uređaje, ali ga developeri sve manje moraju direktno dodirivati u novim projektima.
Primjeri: Three.js, Babylon.js, PlayCanvas
Najveći 3D web enginei već su krenuli prema WebGPU‑u, ali s oprezom. Njihova baza korisnika i dalje uključuje škole, poslovne korisnike, starija računala i embedded uređaje gdje je WebGL jedini realan izbor.
Three.js
Three.js već ima eksperimentalni WebGPURenderer, dok je WebGLRenderer i dalje default. Za sada developeri često rade ovakve strategije:
- pokušaj inicijalizirati WebGPU renderer,
- ako padne, vrati se na WebGL 2,
- ako ni to ne uspije, tek tada pokušaj WebGL 1.
S WebGPU compatibility modeom, scenarij se može pojednostaviti. Three.js u budućnosti može:
- inicijalizirati isključivo WebGPU renderer,
- prepustiti Chromeu da odluči koristi li nativni ili compatibility backend,
- zadržati WebGLRenderer samo kao krajnji fallback za vrlo stare preglednike ili specifične platforme.
To smanjuje potrebu za održavanjem više renderera i različitih materijalnih sustava.
Babylon.js
Babylon.js je agresivno usmjeren na performanse i PBR vizualnu kvalitetu. Već sada nudi WebGPU engine paralelno s WebGL engineom. U kompleksnim scenama s puno post‑process efekata, broj render passova i bandwidth prema GPU‑u postaje kritičan.
Uz compatibility mode, Babylon.js može tretirati WebGPU kao primarni API i optimizirati svoj pipeline oko njega: bind groupovi, layouti, compute shaderi za culling i post‑processing. Ako korisnikov GPU ne podržava moderne API‑je, WebGPU sloj će pokušati preslikati taj pipeline na D3D11/OpenGL ES što je bolje moguće.
Razlika u FPS‑u i dalje će postojati, ali developeri više ne moraju ručno pisati zasebne shader varijante za WebGL i WebGPU. Jedan set shader koda, jedan alatni lanac, različiti backendovi.
PlayCanvas
PlayCanvas kao SaaS platforma za 3D web sadržaj posebno je osjetljiva na širinu podržanih uređaja. Svaki dodatni renderer znači više kompleksnosti za korisnike, ali i za tim koji održava engine.
WebGPU compatibility mode otvara mogućnost da PlayCanvas u budućnosti nudi „WebGPU‑prvi” editor i runtime, a da se fallback na stariji GPU stack događa automatski u pregledniku. To je bitno i za poslovne korisnike koji ne kontroliraju hardver svojih krajnjih korisnika, ali žele stabilan prikaz i prihvatljiv frame pacing na starijim strojevima.
Performanse, shaderi i ograničenja compatibility moda
Compatibility mode nije čarobni štapić. On donosi i prednosti i ograničenja.
Prednosti
- Jedinstveni API sloj: Developeri pišu shader kod i pipeline konfiguracije za WebGPU, bez paralelnih GLSL i WGSL kodnih baza.
- Jednostavnije profiliranje: Alati i workflowi za profiliranje mogu se fokusirati na WebGPU callove, dok se razlike u backendu rješavaju na razini preglednika.
- Moderni dizajn pipelinea: Lakše je dizajnirati PBR, deferred ili tiled/clustered forward pipeline kada se cilja WebGPU model resursa i render passova.
Ograničenja
- Nedostupne napredne značajke: Compute‑heavy workflowi, napredne storage teksture ili specifične sinkronizacijske primitivne možda neće biti podržane u compatibility modu ili će biti emulirane uz veći trošak.
- Overhead prevođenja: Svaki dodatni sloj prevođenja između WebGPU i D3D11/OpenGL ES uvodi overhead. Na slabijem hardveru to može značiti niži FPS ili lošiji frame pacing.
- Neravnomjerna kvaliteta drivera: I dalje ovisimo o kvaliteti starih drivera. Ako je D3D11 ili OpenGL ES driver loše optimiziran, WebGPU compatibility mode ne može u potpunosti sakriti te probleme.
U praksi, developeri će morati definirati jasne performance targete. Primjerice, 60 FPS na modernom GPU‑u s nativnim WebGPU backendom i 30 FPS na starijem GPU‑u u compatibility modu. Bitno je da iskustvo ostane stabilno, bez trzaja i naglih padova frame ratea.
Kako planirati migraciju: WebGL danas, WebGPU sutra
Za već postojeće WebGL projekte, pitanje je kada i kako krenuti prema WebGPU‑u, a ne hoće li to biti potrebno. Chromeov compatibility mode mijenja dinamiku tog planiranja.
Kratkoročno (1–2 godine)
- WebGL 2 ostaje ključan. I dalje treba optimizirati draw callove, veličine tekstura, broj render passova i shader kompleksnost.
- Poželjno je početi uvoditi WGSL i WebGPU konceptualni model u alatne lance, barem eksperimentalno.
- Za nove značajke može se razmotriti dualni pristup: WebGL 2 kao baza, WebGPU kao opt‑in za noviji hardver.
Srednjoročno (3–5 godina)
- WebGPU postaje primarni cilj za nove engine module i alate.
- Compatibility mode preuzima većinu posla oko podrške za stariji hardver.
- WebGL renderer se svodi na „legacy” opciju, održava se samo za specifične slučajeve (vrlo stari OS‑ovi, specijalizirani embedded sustavi, kiosk rješenja).
Ključno je da se kompleksnost rada s naslijeđenim GPU API‑jima pomiče iz aplikacijskog koda u preglednik. WebGL ne nestaje, ali njegova se uloga mijenja: od glavnog cilja prema stabilnom sloju kompatibilnosti.
Šira slika: WebGL kao temelj, WebGPU kao budućnost
Chromeov WebGPU compatibility mode šalje jasnu poruku WebGL zajednici. WebGL je i dalje važan, ali njegova najveća vrijednost u idućem desetljeću bit će stabilnost i raširenost, a ne inovacija.
WebGPU preuzima ulogu primarnog API‑ja za nove 3D web projekte. Donosi modernu arhitekturu resursa, bolju kontrolu nad pipelineom i mogućnost iskorištavanja novih GPU značajki čim stignu na desktop i mobilne platforme.
Istovremeno, upravo zahvaljujući compatibility modu, ta budućnost ne isključuje stariji hardver. Umjesto „WebGPU ili ništa”, dobivamo kontinuirani spektar: od nativnog WebGPU backenda na najnovijim GPU‑ovima do WebGL‑baziranog compatibility sloja na starijim strojevima.
Za developere to znači manje fragmentacije, čišći kod i jasniju strategiju migracije. Za korisnike to znači da će i starija računala još neko vrijeme moći pratiti evoluciju 3D weba, makar uz nešto skromnije postavke i niži FPS.
