WebGPU: tarayıcı için yeni nesil grafik ve hesaplama yolu

WebGL, uzun yıllar boyunca web 3D’sinin omurgası oldu; fakat durum makinesi ve sürüm parçalanması, büyük motorların omuzunda ağır hissedilir. WebGPU ise «tek seferde küçük bir ayar, sonra çiz» ritmini önceden derlenmiş nesneler ve açık komut tamponları ile değiştirmeye çalışır. Aşağıdaki üç alt başlık, aynı donanımı düşünürken zihinsel modelin nasıl kaydığını özetler — ayrıntılı API rehberi değil, okuma yönü verir.

Donanım rolü: «yalnızca çiz»ten «çiz + paralel iş»e

WebGL çoğu zaman GPU’yu zihinde çizim motoru olarak konumlandırır; hesaplama fikri varsa bile çoğu zaman grafik hattının etrafında dolanır. WebGPU ise aynı çip üzerinde grafik + compute yolunu birinci sınıf vatandaş yapar — yani kare bütçesinde «önce bu ızgarayı işle, sonra sahneyi çiz» gibi aynı bellek ailesi içinde düşünebileceğiniz işler için resmi bir kapı açılır. Bu, yalnızca kare hızı değil; veri hazırlama ve simülasyonların nerede koşacağı sorusunu da kaydırır: bazı adımlar CPU’da kalmak zorunda olsa bile, artık «neden GPU’da denemiyorum?» sorusu daha meşru hale gelir.

Pratik uyarı: GPU’da koşmak, otomatik olarak «daha doğru» veya «her zaman daha ucuz» demek değildir; okuma–yazma senkronu, bellek bariyerleri ve hata ayıklama maliyeti yeni bir öğrenme eğrisi getirir. Aşağıdaki Compute shader başlığında bu yolun Holodepth’te nasıl derinleşeceğine değineceğiz — burada yalnızca rol çerçevesi netleşsin.

CPU maliyeti: ön ödeme ve daha düz kare içi yürüyüş

WebGL dünyasında sık state değişimi, küçük ayarların peş peşe gönderilmesi ve sürücüye bırakılan ince taneli kararlar, JavaScript tarafında ölçülmesi zor bir gizli ek yük yaratabilir. WebGPU’nun tasarım hedeflerinden biri, bu tür maliyetin bir kısmını çizim öncesine taşımak — pipeline ve bağ nesnelerini hazırlarken ödemek, kare içinde ise daha öngörülebilir bir komut akışı bırakmaktır.

«Her zaman daha hızlıdır» demek doğru olmaz: sahne hafifse fark hissedilmeyebilir; ağır sahnede ise kazanç, batching ve veri düzeninizle birlikte gelir. Üçgen başına maliyet hâlâ vardır; değişen şey, kimin ne zaman neyi bildiği ve sürücüyle konuşma biçimidir. Shader mantığı · veri paketi metnindeki «çağrı anı» düşüncesi burada da geçerlidir — yalnızca paketin paketlenme biçimi farklılaşır.

Shader sözleşmesi: GLSL → WGSL

WebGL ekosisteminde GLSL ağırlıktadır; giriş ve depolama nitelikleri için GLSL sayfası yeterli bir üst köprüdür. WebGPU tarafında ise WGSL (WebGPU Shading Language) öne çıkar: benzer matematiksel çekirdek (skaler, vektör, matris) paylaşılsa da bellek görünürlüğü, kaynakların bağlanma biçimi ve derleyicinin doğrulama tonu farklıdır. «Aynı noktayı boyuyorum» hissi devam eder; fakat kaynak kodu dosyanızın üstünde yazdığınız sözleşme başka bir dilde imzalanır.

Bu Holodepth sayfasında WGSL öğretilmeyecek; amaç, projeye girdiğinizde «GLSL bilgim var, o yüzden WGSL kolaydır» varsayımını kırmaktır — çoğu zaman taşıma işi ve yeni hata sınıfları bekler. İlerideki içeriklerde seçilen bir örnek üzerinden sözdizimi açılacaktır.

Aşağıdaki başlıklar, WebGPU’yu «WebGL Plus» gibi okumayı engelleyen yapı taşlarıdır. Her biri, Holodepth’in ileride açacağı ayrıntı sayfalarına zemin hazırlar.

Compute shader · ekran dışı paralel iş

Görüntü üretiminden bağımsız, ızgara tabanlı paralel çekirdek işleri WebGPU ile tarayıcıda daha doğal hale gelir: parçacık adımları, alan örneklemesi, bazı yapay zeka yardımcıları veya geometri ön işleme gibi işler CPU’yu boğmadan düşünülebilir. Bu, Holodepth örnekleminde anlatılan türden sahneler için olanak demektir; tek başına «otomatik olarak kolay» anlamına gelmez — bellek bant genişliği, senkronizasyon ve doğrulama yine sizin tasarımınızdadır.

Pipeline nesneleri · önceden mühürlenmiş ayar

Birçok karışım, derinlik karşılaştırması ve hedef biçimi gibi kararlar önceden paketlenmiş bir render pipeline ile sabitlenir; kare içinde «her satırda rastgele durum çevirmek» yerine, geçerli pipeline’ı seçip çizersiniz. Bu, kavramsal pipeline metnindeki aşamaları motor içi nesneleştirme pratiğine yaklaştırır — fakat aynı metinde anlatılan tampon politikaları veya post-processing zinciri ayrıntısı burada tekrar edilmez.

Bind group / kaynak bağlama · daha düzenli kitaplık

Dokular, tamponlar ve örnekleme ayarları gruplar halinde bağlanır; böylece karmaşık materyal düzenleri daha okunur ve taşınabilir olur. Bu, Shader mantığındaki veri paketi düşüncesini değiştirir: aynı «kim, neyi okuyor?» sorusu devrededir; fakat cevabın dilbilgisi WebGL’deki klasik uniform tek çizgisi kadar düz olmayabilir.

Holodepth, önce okunabilir kavram zincirini kurmayı hedefler; WebGPU ise bu zincirin performans ve ifade gücü uçlarında yeni kapılar açar. Aşağıdaki üç alt başlık vaat değil, içerik planlama gerekçesi olarak okunmalıdır:

Pil ve termal: CPU nefesi, GPU faturası

Daha az «boğucu» CPU yönetimi ve daha düz komut akışı, doğru kurguda mobil cihazlarda uyanık süre maliyetini düşürebilir; bu da pil ve termal hissiyatına yansıyabilir. Fakat aynı cihazda GPU üzerinde koşan ağır bir compute geçişi, kötü seçilmiş iş boyutu veya gereksiz senkron ile aynı ısı bütçesini tüketir — yani «WebGPU açtım, cihaz serinledi» otomatiği yoktur. Holodepth metinlerinde bu başlık, «önce ölç, sonra kutuya koy» disiplinini hatırlatır; enerji mühendisliği dersi vermez.

Yoğun geometri: örnekleme ve bellek duvarı

Örnekleme (instancing) ve daha açık kaynak yönetimi, aynı geometriyi çok kez çizmek zorunda kalmadan büyük öbekleri taşınabilir kılmaya yardım edebilir. Bunun teorik zemini Holodepth’te geometri tarafında anlatılır; örneğin Instancing konusu ile bağ kurabilirsiniz — burada yalnızca WebGPU’nun bu tür düzenleri daha düzenli taşımayı hedeflediği vurgulanır.

Gerçek dünyada ise bellek ve bant genişliği hâlâ duvardır: daha çok örnek, daha çok köşe verisi ve doku trafiği demektir. Düşük seviyeli kontrol, sınırı aşmayı kolaylaştırmaz; yalnızca sınırı nerede göreceğinizi daha erken görmenizi sağlar.

Görüntü sonrası ve kalite: seçici deneyler

Bazı denoising ve ışın tabanlı yaklaşımlar, WebGPU + compute ile tarayıcıda deneysel veya seçici senaryolarda görünür hale gelmiştir; «film kalitesi her cihazda hazır» beklentisi ise yanıltıcıdır. Üretimde her zaman ölçüm, cihaz listesi ve WebGL’e dönüş planı gerekir.

Çok geçişli görüntü sonrası düşüncesi — tamponlar arasında taşınan pass zinciri — Holodepth’te Render Pipeline · Post-processing bölümünde anlatılır; burada tekrarlanmaz. WebGPU’nun getirdiği şey, bu zincirde hesaplama yoğunluğu için daha geniş bir oda; oda dolunca yine aynı tampon maliyetleriyle yüzleşirsiniz.

Three.js ekosisteminde WebGPURenderer yolu, aynı sahne fikrini farklı bir sürücü yoluna taşır; fakat tarayıcı desteği, sürüm farkları ve eklenti kısıtları nedeniyle tek yol stratejisi risklidir. Holodepth yaklaşımı: WebGPU varsa onu hedefleyen, yoksa WebGLRenderer ile devam eden feature detection ve açık kullanıcı geri bildirimi. Üretimde ayrıca Can I use · WebGPU tablosunu düzenli kontrol etmek, «yerelde çalıştı» yanılgısını erken kırar.