Bir Headless Chromium GPU Düzeltmesi Bir AI Avatar Yayını Nasıl 4fps'ten 58fps'e Çıkardı

Sürekli açık bir AI avatar yayın servisi geliştiren bir geliştirici, dev.to'da headless Chromium'un GPU'yu sessizce yok sayarak bir 3D avatarı yaklaşık 4fps ile render ettiğini — ve üç parçalı bir yapılandırma düzeltmesinin aynı sahneyi 57–58fps'e çıkardığını belgeledi. Orijinali forge.workstyle.tech'te Japonca olarak yayımlanan yazıda, headless Chromium içinde bir VRM 3D modelinin render edilip videosunun yakalandığı ve RTMP üzerinden yayınlandığı, avatarın insan müdahalesi olmadan konuştuğu ve yorumlara tepki verdiği bir pipeline anlatılıyor.

Yalnızca CPU'ya dayalı tasarım gerçek iş yükünde çöktü

Orijinal tasarım, maliyet ve ölçeklenebilirlik nedenleriyle GPU'ları tamamen dışlıyordu. Chromium, CPU tabanlı bir WebGL uygulaması olan SwiftShader ile geliyor ve basit bir üçgen testi tam 60fps'de çalışıyordu — yazar bunu yanıltıcı bir güven duygusu olarak tanımlıyor. Gerçek VRM avatar sahnesi aynı tarayıcı, CPU ve çözünürlükte yaklaşık 4fps'e düştü; oyuncak kıyaslamanın yaklaşık 15 katı yavaş.

Beş dakikalık bir çözünürlük taraması darboğazı buldu

Yavaşlamayla karşılaşan yazar, çıktı çözünürlüğünü tarayıp kare hızlarını ölçtü: 720p, 540p ve 360p'nin hepsi yaklaşık 4fps verdi. Piksel sayısını düşürmek fark yaratmadığından darboğaz parça (fragment) işleme değil, geometri ve CPU işiydi — her karede CPU'da çalışan kemik başına skinning dönüşümleri, saç ve kıyafet için yay-kemiği (spring-bone) fizik simülasyonu ve draw call sayısını artıran MToon toon gölgelendirmesinin ekstra outline geçişleri. Bunların hiçbiri çıktı çözünürlüğüyle ölçeklenmiyor.

Bu bulgu, tasarım belgesindeki 24fps'te 540p'ye düşme yedek planını geçersiz kıldı. Yazarın ifade ettiği ders: bir yedek plan her zaman neyin azaltıldığını ve bu azaltmanın neyle orantılı olduğunu belirtmeli, aksi halde plan değil dilek olur. Daha düşük kare hızı ya da basitleştirilmiş model seçenekleriyle karşı karşıya kalan yazar, RTX sınıfı GPU bulut instance'ları kiralamayı tercih etti.

Chromium'un GPU'da render etmesi için üç koşul

Container'a bir GPU atanmış, nvidia-smi çalışıyor ve bir WebGL context oluşturulmuş olsa bile Chromium hâlâ herhangi bir hata veya uyarı vermeden SwiftShader'a geri düşüyordu. Yazıya göre GPU render'ı yalnızca aşağıdakilerin üçü de yerinde olduğunda gerçekleşiyor:

• Hafif headless shell değil, Chromium'un tam derlemesi; programatik başlatıcılar çoğu zaman varsayılan olarak shell'i açar. Shell, CI DOM testlerine uygundur ama GPU render yolundan yoksundur.
• EGL ICD kaydı — /usr/share/glvnd/egl_vendor.d/ altındaki 10_nvidia. gibi JSON dosyaları ve /usr/share/vulkan/icd.d/ altındaki Vulkan ICD dosyaları — artı libglvnd. Container'larda NVIDIA_DRIVER_CAPABILITIES all olarak ayarlanmalı, çünkü varsayılan olan compute,utility grafik kütüphanelerini mount etmemeye bırakıyor.
• Başlatma flag'leri: --use-gl=angle, --use-angle=vulkan (veya gl-egl), --ignore-gpu-blocklist ve --no-sandbox. Blocklist flag'i önemli, çünkü aksi halde Chromium, sorunlu olarak bildiği sürücü kurulumlarını diskalifiye ediyor; yazar bu durumun container ortamlarında neredeyse her zaman geçerli olduğunu söylüyor.

Temiz bir başlatmaya güvenmek yerine render cihazını doğrulayın

Yazı, bu yığının gerçekte başarısız olduğunda bile başarı bildirdiğini vurguluyor: sayfalar yükleniyor, context'ler oluşturuluyor ama her şey CPU'da çalışıyor. Güvenilir kontrol, sayfanın içinden WEBGL_debug_renderer_info uzantısıyla GL_RENDERER değerini okumaktır — SwiftShader dizgisi geri düşüş demektir, NVIDIA adaptör adı ise GPU render'ını doğrular. Yazar bu günlüklemeyi başlatmaya bağladı ki pipeline kendini otomatik olarak doğrulayasın.

ANGLE backend'leri ve kare yakalama sorunları

İki ANGLE backend'i eşdeğer değildi. Hem gl-egl hem vulkan aynı 57–58fps'i üretti, ancak ikisi arasındaki görüntü kalitesi farklıydı ve yazar vulkan'da karar kıldı. Kare yakalama kendi şekilde bozuldu: CPU render altında çalışan canvas.captureStream(), render GPU'ya taşındığında bozuk ya da siyah çıktı üretti. Önerilen替代 yerine geçiş, Chrome DevTools Protocol'den Page.startScreencast.

Neden önemli

Container'lardaki headless tarayıcılar artık test, scraping, render ve otomasyon için standart altyapı ve bu yazı, GPU hızlandırmanın bu ortamda nasıl sessizce başarısız olduğunun kompakt bir kataloğu — hatalar yok, metrikler normal görünüyor ve context'ler yanlış cihazda başarıyor. Performans bahisleri marjinal değil: 4fps ile 58fps arasındaki fark, gerçek zamanlı 3D için kullanılamaz ile sevk edilebilir arasındaki fark. Hata ayıklama yöntemleri canlı yayınla sınırlı değil. Darboğazın piksel doldurma mı yoksa geometri ve CPU işi mi olduğunu belirlemek için çözünürlüğe karşı kare hızını ölçün, kareyi gerçekte hangi donanımın çizdiğini doğrulamak için GL_RENDERER'ı okuyun ve renderer dizgisi aksini söyleyene kadar container GPU erişimini kanıtlanmamış sayın.