holodepth

Three.js · Varlık · KTX2 · Transcoding

Transcoding süreci: KTX2'den GPU'ya yolculuk

KTX2 dosyasının içindeki veri (çoğu zaman Basis Universal yükü), doğrudan GPU tarafından okunacak biçimde durmaz; fakat bu paket, donanımın anladığı blok sıkıştırma biçimlerine (BC7, ASTC, ETC2 vb.) dönüştürülmek üzere tasarlanmış bir yoldur. Bu milisaniyelik «hedefe tercüme» adımına transcoding denir — aynı dosya, farklı cihazlarda farklı «yerel dile» çevrilir; siz yine de tek teslimat yoluyla kalırsınız.

Bu sayfa, indirmenin ardından olanları sıraya koyar: yükleyicinin yetenek sorgusu, CPU üzerindeki transcode, sıkıştırılmış bloğun VRAM'e yerleşmesi ve tarayıcıda bunun kullanıcıya yansıması (worker, ana iş parçacığı, bellek baskısı). Amaç, «neden bu kadar hızlı hissedilir / neden takılma riski düşer?» sorularına iskelet cevap vermektir; ölçüm tabloları ve sahne özelinde rakamlar yine sizin telemetrinize kalır.

Aşağıdaki bölümlerde önce dönüşümün kendisi, sonra WebGL çalışma zamanı davranışı, ardından GPU'nun neden ham piksel yerine blok veri istediği ve en sonda tek sayfalık özet akış yer alır. Bu sıra, okurken zihinde bir «zaman çizelgesi» tutmanızı kolaylaştırır.

Önce okumanız iyi gelir: KTX2 nedir? (konteyner ve maliyet zemini), Basis Universal (içerideki kodlama fikri ve ETC1S / UASTC ayrımı). İsterseniz pratik his için Basis lab ve bu sayfadaki pipeline lab figürüne göz atın; metin ise sürecin «hat krokisi» olarak kalır.

İnteraktif lab: JPG yolu · KTX2 yolu (öğretici)

Aşağıdaki sahnede aynı küp kalır; değişen şey «hangi pipeline rolünü oynadığımız»dır. JPG yolunda büyük RGBA tampon üretimi ve gecikme simülasyonu; KTX2 yolunda küçük blok temsil ve kısa transcode hissi verilir — rakamlar öğreticidir, üretim ölçümünüzle değiştirin.

Transcoding lab · DataTexture · Three.js r170 Yükleniyor…
Pipeline
Worker

Kapalıyken süre uzar; küp ölçeği ve FPS rozeti kısa «frame drop» (sim) oynatır — gerçek projede ölçün.

Pipeline süresi (sim)
—
VRAM / tampon (öğretici)
—
CPU yükü (sim)
—
İş parçacığı
—
GPU hedefi (WebGL)
—
FPS hissi (sim)
—

Sürükleyerek döndürün · modları karşılaştırın

Nasıl okunur: Önce KTX2 yolunu ve Worker açık halini izleyin; ardından JPG yoluna geçip süre, VRAM satırı ve FPS rozetini karşılaştırın. Küp aynıdır; doku tamamen tarayıcıda üretilir. Bu demo gerçek JPEG dosyası veya Basis WASM yüklemez — gecikmeler ve CPU yüzdesi öğretici simülasyondur. GPU hedefi satırı sıkıştırma uzantılarından okunur.

KTX2 → GPU biçimi dönüşümü

Dosya tarayıcıya ulaştığında KTX2 yükleyicisi (loader) devreye girer. Tipik akış şu sorulara yanıt üretir:

  1. Donanım analizi: Yazılım, WebGL / WebGPU ortamında hangi sıkıştırılmış doku uzantılarının güvenilir olduğunu tarar — yani «hangi GPU formatlarını destekliyorsun?» sorusunun pratik karşılığıdır.
  2. Hedefe tercüme: Basis temelli ara temsil, CPU üzerinde küçük ve hızlı bir transcoder ile hedef blok biçimine dönüştürülür; çıktı yine sıkıştırılmış dokudur.
  3. Platform örnekleri (yönlendirici, kesin sözleşme değil):
    • Masaüstü (NVIDIA / AMD): çoğu zaman BC7 veya DXT / S3TC ailesi.
    • Android: sık ETC2 / EAC.
    • iOS / modern mobil: çoğu zaman ASTC.
  4. VRAM'e yerleşim: Dönüştürülen veri artık örnekleme biriminin doğrudan okuyacağı compressed texture halindedir ve sürücü / API yoluyla grafik belleğine taşınır.

Üretimde hedef seçimi motor, sürücü ve içerik politikanızın bileşimidir; bu sayfa terimleri hizalamak içindir.

WebGL çalışma zamanı davranışı

Bir web sayfasında KTX2 kullanıldığında, tarayıcının runtime'ındaki yük davranışı klasik görsel çözme yolundan ayrışır. Üstteki pipeline lab ile Worker aç/kapa ve iki yol arasında gidip gelerek bu farkı hissedebilirsiniz.

İş parçacığı (Worker) kullanımı

Geleneksel JPEG çözme gibi işler ana iş parçacığında koşabilir ve kare süresine «tıkanma» olarak yansır. Birçok KTX2 yükleyicisi (örneğin Three.js KTX2Loader), transcoding'i sıklıkla Web Worker içinde yürütür; böylece ağır doku işi arka planda ilerlerken arayüz ve etkileşim daha akıcı kalır — yine de işin bittiğini varsaymayın: worker maliyeti ölçülmelidir.

Bellek yönetimi («sıfır şişme» fikri)

Klasik bir JPEG akışında dosya bellekte çözülerek genişleyebilir; örneğin 1 MB civarı bir JPEG, tampon olarak onlarca MB RGBA düşünebilir. KTX2 hattında ise hedef, veriyi tam boyutuna açmadan blok biçiminde GPU'ya iletmektir; böylece ana bellekte «şişme» riski azalır ve düşük RAM'li mobil profillerde stabilite artar. Somut rakamlar sahne ve çözünürlüğe bağlıdır; ölçüm şartsız iddia yerine tablo koyun.

GPU neden «ham» piksel istemez?

Transcoding sonunda GPU'ya giden verinin hâlâ sıkıştırılmış olmasının nedeni, donanımın doku erişim modelidir: ekran kartı, dokunun herhangi bir texel'ine rastgele erişim (random access) ile yaklaşmak ister.

  • JPG / PNG: Klasik çözülmüş akışta bir piksele güvenilir biçimde ulaşmak için geniş tamponlar ve farklı bellek düzeni gerekir; bu, GPU'nun doğrudan «dosyayı okuyayım» modeliyle örtüşmez.
  • Transcode edilmiş KTX2 yolu: Veri bloklar (ör. 4×4) üzerinden düşünülür; örnekleme birimi ihtiyaç duyduğu bloğu adresleyebilir. Bu, modern render performansının zeminidir.

Pratik not: blok boyutu biçime göre değişir; önemli olan «tam çözülmüş dev RGBA yüzeyi» yerine GPU'nun anladığı yol ile gitmektir.

Özet: adım adım akış

  1. Sunucu: .ktx2 paketi (içeride sıkıştırılmış temsil) gönderilir.
  2. Tarayıcı (Worker): Dosya iner; GPU yetenekleri ve politika kontrol edilir.
  3. Transcoder: Basis yükü, milisaniyeler düzeyinde hedef yerel biçime (ör. ASTC) tercüme edilir.
  4. GPU (VRAM): Sıkıştırılmış doku bağlanır; çizim hattı örneklemeye başlar.

HoloDepth notu

Ölçüm

Transcoding «bedava» değildir: worker süresi, ana iş parçacığında kalan işler ve VRAM baskısı aynı panoda toplanmalıdır. Basis lab figüründeki gibi cihaz hedefi satırını üretim loglarınızla eşleştirin.