GPU vs CPU: 3D Sahne ve WebGL’de İş Bölümü

Odak: Bir kareyi ( frame ) üretirken kritik soru “kim daha hızlı?” değil; hangi iş yükü hangi tarafta doğal sorusudur. CPU karar verir, GPU tekrarı yürütür.

Bir Kare (Frame) Gerçekten Ne İş Yaptırır?

Bir 3D sahneyi render etmek, her karede ekrandaki piksellerin rengini ve görünürlüğünü yeniden üretmek demektir.

Hedef 60 FPS olduğunda, kullanıcıya hissettirmek istediğin şey yalnızca "akıcı animasyon" değil; aynı zamanda her kare için ayrılan

zaman penceresinin içinde bitmesi gereken iş yığınıdır.

Bu yüzden soru "hangi işlemci daha hızlı?" değil, "hangi iş yükü hangi tarafta doğasına uyuyor?" sorusuna döner: tek bir karar zinciri mi, yoksa aynı işlemin binlerce kopyası mı baskın?

Mimari felsefe bu noktada sadeleşir: CPU, dünyanın kurallarını ve sahne durumunu yöneten tekil karar merkezi iken; GPU, aynı anda çok sayıda benzer işi yürüten yığınsal iş gücü olarak konumlanır.

Kısa bir sezgi: CPU tarafında sıklıkla düşük gecikme ve dallanmalı akış önemlidir; GPU tarafında ise iş hacmi ve aynı programın devasa veri üzerinde tekrarlanması öne çıkar.

İkisini aynı ölçütlerle yargılamak, tasarımı baştan kaydırır.

Kare Bütçesi: Önce Ritim, Sonra Süs

Bir kareyi düşünürken zihninde iki katman aç: update aşamasında sahne durumu ( fizik , girdi , ağ, oyun mantığı ) ve draw aşamasında bu durumun ekrana yansıması.

İlk katman çoğunlukla CPU’nun "sırayla ve kontrollü" dünyasıdır; ikinci katman ise GPU’nun "aynı anda ve tekrarlı" dünyasıdır.

Web tarafında bu ayrım, tarayıcının ana iş parçacığında çalışan JavaScript ile grafik API’sinin ( WebGL / WebGPU ) oluşturduğu komut + veri sınırında belirginleşir: tarafını seçmezsen, ya mantığı GPU’ya taşıyamazsın ya da piksel işini CPU’da kalabalıklaştırırsın.

İçerik Odağı: Bu sayfa bir "donanım katalogu" değildir; amaç, update ile draw aşamalarını zihninde ayırırken CPU ve GPU rollerini tahmin edilebilir kılmaktır.

Burada kazanılacak beceri, model numaralarını ezberlemek değil; performans sorunu çıktığında "önce köprü mü, önce shader mı, yoksa önce gereksiz CPU işi mi?" diye doğru sırayla sorabilmektir.

Pratik sezgi: Bir kareyi "tek bir hikâye" gibi oku: giriş → durum güncelleme → GPU’ya giden komutlar → ekran.

Bu hikâyede gereksiz bir cümle tüm bölümün ritmini bozar.

Sonraki alt başlıklarda önce iki işlemcinin güçlü yanlarını ayıracağız; sonra duvar boyama metaforuyla seri ve paralel farkını pekiştireceğiz.

Alt başlık: CPU’nun gücü dallanmalı mantık ve kontrol hattıdır. Web’de bu çoğu zaman main thread üstündeki JavaScript ritmidir.

Az Çekirdek, Geniş Yetki Alanı

CPU, karmaşık mantık yürütme, işletim sistemi etkileşimi ve sıralı ( sequential ) iş yükleri için tasarlanmıştır.

Az sayıda ama güçlü çekirdek; dallanmalı kod yollarında, sık erişilen verinin önbelleğe yakın tutulabildiği senaryolarda ve tek bir iş akışını sonuna kadar taşımakta üstündür.

Aynı anda bir event loop akışını sürdürmek, ağ veya depolama gibi I/O bekleme süreçlerini yönetmek ve bellek tahsis stratejilerini denetlemek gibi görevler CPU’nun "genel amaçlı" doğasına yakındır.

Modern CPU’lar içeride spekülatif yürütme ve komut yeniden sıralaması gibi mekanizmalarla "tek bir sıra" hissini korurken bazı işleri hızlandırır; fakat programlama modeli olarak düşündüğünde yine de karar ve kontrol hattının merkezinde durursun.

Tarayıcıda CPU = Ana İş Parçacığı Baskısı

Web geliştiricide CPU çoğu zaman JavaScript’in koştuğu ana hat ile özdeşleşir: requestAnimationFrame ile planlanan bir karede, hem mantık hem veri hazırlığı hem de ( yanlışsa ) ağır senkron işler aynı pencerede yarışır.

Bu yüzden CPU tarafındaki optimizasyon, yalnızca "daha iyi algoritma" değil; aynı zamanda ne zaman iş yapılmayacağı disiplinidir: uzun görevler ( long task ) kareyi ısırdığında, GPU boş kalsa bile kullanıcı akıcılığı çöker.

Güçlü yanı: Seri işler, if / else dallanmaları, derin karar ağaçları ve oyun/uygulama state makineleri.

Bu güç, "kuralları değiştir" ihtiyacında parlar: çarpışma seçimi, animasyon geçişleri, yapay zeka kararları, kullanıcı girdisinden sahneye giden niyet; hepsi CPU’nun rahat ettiği türden işlerdir.

3D’deki görevi: İş mantığını yürütmek, nesnelerin ne zaman güncelleneceğine karar vermek ve GPU’ya ne çizileceğini anlatan komut + tampon setini hazırlamaktır.

Pratikte bu, "draw call listesini kim kuruyor?" sorusunun cevabıdır: CPU, bağlama durumunu ve veri referanslarını düzenler; GPU ise bu listenin arkasında devasa tekrarı yürütür.

İçerik Odağı: CPU’yu verimli kullanmak, 3D’de "daha çok hesap" değil "daha az gereksiz koşul" demektir: her dal, her ekstra döngü, ana hatta ödediğin faizdir.

Bu yüzden iyi bir CPU disiplini; sahneyi sürekli yeniden kurmak yerine, değişenleri seçip GPU’ya küçük farklar iletmeyi öğrenmektir.

Derinlik: CPU performansı çoğu zaman ham frekansla değil, veri yerelliği ve dallanma maliyetiyle belirlenir: önbellek dostu düzen, öngörülebilir bellek erişimi ve sade kontrol akışı, 3D uygulamada bile ana hattı rahatlatır.

Pratik sezgi: CPU’yu yöneten filozof gibi düşün: konuşur, karar verir, emir yazar; ama duvarı piksel piksel boyamaz. Boyama işini ordulara ( GPU ) devredip, kendini "emir netliği" ile sınırladığında kare bütçesi nefes alır.

Aksi halde, çekirdekler ne kadar hızlı olsa da her pikselin ayrıntılı rengini tek tek JS döngüsünde hesaplamaya kalktığında kare bütçesi hızla tükenir.

Alt başlık: GPU’nun gücü, aynı programı çok büyük veri üzerinde eş zamanlı çalıştırmaktır. Bu yüzden amaç “GPU’ya daha çok iş atmak” değil; anlamlı ve tutarlı iş vermektir.

Çok Çekirdek, Tek Tip Emir

GPU, basit ama devasa miktardaki veriyi aynı anda işlemek için tasarlanmıştır: binlerce küçük yürütme birimi, aynı programın farklı veri parçalarına uygulanmasını ( SIMT düşüncesi ) mümkün kılar.

Özetle: aynı talimat, farklı köşelerde aynı anda yürür.

Bir draw call çoğu zaman tek bir "emir" gibi görünür; fakat arkada köşeler için vertex aşaması, üçgenlerin ekrana düşmesi ve her piksel için fragment aşaması gibi grafik hattı adımları tetiklenir.

Bu adımların her birinde tekrar eden matematik, GPU’nun doğal zeminidir.

Bu tekrar, CPU’nun sıralı dünyasında "lüks", GPU’nun dünyasında ise temel iş modelidir; yani sorun genelde "GPU yavaş" değil,

"GPU’ya ne kadar anlamlı iş verildiği"dir.

Dalgalanma (Divergence): Aynı Ordunun Farklı Emir Alması

Paralellik bedava değildir: aynı warp / iş grubundaki iş parçacıkları çoğu zaman aynı shader yolunu paylaşır.

Bir dal ( if ) bazı piksellerde farklı sonuca gidiyorsa, donanım verimliliği düşer; bu da GPU’yu "sonsuz paralel" sanmanın tehlikesidir.

Bu yüzden GPU optimizasyonu bazen daha az dallanma ve daha öngörülebilir bellek erişimi demektir; tıpkı CPU’da olduğu gibi, sadece ölçek ve maliyet modeli farklıdır.

Güçlü Tarafı: Muazzam paralellik; matris ve vektör işlemleri; doku örnekleme ve piksel bazlı hesap.

Özellikle dönüşümler ( MVP gibi ), ışık vektörleri ve dokudan okuma ( sample ) gibi işler, GPU’da "tek satır kod, milyonlarca veri noktası" olarak ölçeklenir.

3D İçerisinde ki Görevi: Işık modeli örneği, doku adresleme, derinlik testi ve nihai piksel rengine kadar olan "yoğun tekrar" yükünü taşımaktır.

Bunun pratik karşılığı: ekran çözünürlüğü arttıkça fragment maliyeti büyür; sahne geometrisi büyüdükçe vertex tarafı şişer; ikisi de aynı kare bütçesinden pay alır.

İçerik Odağı: GPU’yu verimli kullanmak, çoğu zaman "daha sık çiz" değil

"aynı görüntüyü daha az taşıma ve daha az gereksiz state değişimiyle çiz" demektir: gereksiz draw call ve gereksiz büyük dokular, köprüyü de GPU’yu da aynı anda yorar.

Derinlik: GPU’da sınır çoğu zaman saf "aritmetik" değil, bellek bant genişliği ve önbellek davranışıdır: büyük dokular, rastgele okuma ve düşük yerellik, ALU’dan önce tıkanıklık üretir.

Pratik sezgi: GPU’yu disiplinli ordular gibi düşün: tek tip talimatla hareket ederler; ama talimat sürekli dallanıyorsa veya her piksel farklı bellek yoluna kaçıyorsa, "düzen" bozulur ve kare süresi fırlar.

Bu nedenle GPU’yu "daha hızlı CPU" sanmak yanıltıcıdır; doğru soru: iş yüküm paralel mi, yoksa sıralı karar ağırlıklı mı? — ve paralel tarafta bile dallanma + bellek disiplinini unutmamak gerekir.

Alt başlık: “Seri vs. paralel” farkı, update (plan/karar) ile draw (uygulama) temposunun ayrılmasıdır. Metaforla düşün: usta planlar, robotlar boyar.

Metafor: Duvarı Kim, Nasıl Boyar?

Düşün ki bir duvarı boyaman gerekir.

CPU Yaklaşımı: Tek usta, hangi köşeden başlayacağına karar verir, fırçayı seçer ve uçtan uca hızlı ama sırayla ilerler.

Güçlü yanı, "ne yapılacağını" sürekli revize edebilmesidir.

GPU Yaklaşımı: Binlerce küçük robot; her biri duvarın küçük bir dikdörtgeninden sorumludur ve hepsi aynı anda çalışır; duvar fiziksel olarak

"aynı anda" biter.

Güçlü yanı, "aynı işi çok kez" aynı disiplinle tekrarlamaktır.

Gerçek 3D uygulamalarında ikisi de vardır: usta ( CPU ) planı değiştirir, robotlar yeni planı aynı anda uygular; sorun, planın her karede gereksiz yere değişmesi veya robotlara çelişkili talimat gitmesidir.

Aynı Karede İki Tempo: Üretici ve Yürütücü

İş akışını düşünürken CPU’yu çoğu zaman üretici, GPU’yu yürütücü olarak ayır: biri "bu karede ne değişti?" sorusunu toparlar; diğeri

"bu değişiklik ekranda nasıl görünür?" sorusunu piksel ölçeğinde çözer.

Bu ayrım, grafik API’sinin doğası gereği bir sıra ve aralık meselesidir: komutların hazırlanması ile GPU’nun işi bitirmesi aynı anda bitmek zorunda değildir; ama kullanıcı için "tek kare" olarak birleşirler.

İçerik Odağı: WebGL / WebGPU dünyasında CPU, sahnenin senaryosunu yazar; GPU ise bu senaryonun ekrana yansıyan görsel sonucunu üretir.

Tarayıcıda bu senaryo çoğu zaman requestAnimationFrame ile ritimlenir: her tetikte önce mantık ( update ), sonra çizim ( render ) çağrısı gelir; ikisinin süresi aynı bütçeyi paylaşır.

Bu ayrım, 3D Web'e Geçiş listesinde ki Core & Script Base sayfasındaki update → render ritmini okumayı kolaylaştırır: CPU tarafında

"ne oldu?", GPU tarafında "görüntü nasıl oluştu?" sorularını aynı karede üst üste bindirmeden cevaplamayı hedeflersin.

Derinlik: İş akışı sadece "paralel = her şey GPU’da" demek değildir; senkronizasyon noktaları kareyi bekletir.

Sıcak yolda sık readPixels benzeri işlemler, paralelliği teoride var edip pratikte seri beklemeye çevirebilir.

Pratik sezgi: Duvar metaforunu kareye çevir: önce "ustanın not defteri", sonra "robotların iş emri".

Not defteri her satırda değişiyorsa, robotlar sürekli dur-kalk yapar; bu da bir sonraki bölümde göreceğimiz köprü trafiği stresini büyütür.

Alt başlık: 3D performansta en sık “gizli katil” saf hesap değil; taşıma maliyetidir. RAM → VRAM köprüsünü gereksiz şişirmek, GPU boşta kalsa bile kareyi düşürür.

Darboğaz Çoğu Zaman "Hesap" Değil, Taşıma

3D grafikte en sert performans problemlerinden biri, saf işlem gücü değil; veri taşımadır.

Koordinatlar, indeks tamponları ve dokular, sistem belleğinden ( RAM ) GPU belleğine ( VRAM ) otobüs üzerinden aktarılır; köprü hızlı olsa bile

"ne sıklıkla ve ne hacimde" sorusu kare bütçesini belirler.

Sahne ilk yüklendiğinde bu pompalama kaçınılmazdır; asıl risk, her karede devasa tamponları yeniden göndermeye çalışmaktır: işlemciler güçlü olsa bile köprü doygunluğu stutter üretir.

Bu bölüm, bir önceki başlıktaki üretici / yürütücü ayrımının "ara katmanı"dır: CPU tarafında hazırlanan veri, burada fiziksel olarak GPU’nun okuyacağı adrese taşınır; taşıma pahalıysa, GPU boşta kalsa bile kare yetişmez.

İki Faz: Bootstrap Köprüsü vs. Kare İçi Güncelleme

İlk yüklemede büyük aktarımlar normaldir; çünkü amaç, varlıkları VRAM’de ikamete almaktır.

Sorun genelde runtime’da "her karede aynı dev paketi" göndermeye dönüşür.

Kare içinde ideal tablo şudur: çoğu şey zaten GPU’da durur; CPU yalnızca uniform benzeri küçük parametreler veya sınırlı bir alt bölge güncellemesi gönderir.

Büyük geometriyi her seferinde yeniden itmek, çoğu projede ölçeklenme hatasının ana işaretidir.

İçerik Odağı: Köprüyü optimize etmek, çoğu zaman "daha az veri" ve "daha az sık" demektir: aynı dokuyu on kez yüklemek yerine paylaşmak; aynı köşeyi on kez yazdırmak yerine instancing ile tek çağrıda çoğaltmak gibi.

Web tarafında bu disiplin, motorların soyutlaması altında gizlenir; fakat performans profili çıktığında ilk bakman gereken yerlerden biri upload sıklığı ve tampon boyutlarıdır — shader mikro optimizasyonundan önce.

Derinlik: Taşıma maliyeti yalnızca bayt sayısı değildir; hizalama, düzen ve gereksiz yapısal dolgu ( struct padding ) da köprüyü şişirir.

Ayrıca GPU tarafında aynı veriyi tekrar tekrar okutmak ( aşırı doku örnekleme veya düzensiz erişim gibi ), VRAM içinde ikinci bir

"gizli taşıma faturası" üretebilir.

Derin Not: İyi bir 3D mimarisi ( HoloDepth laboratuvarında da vurgulanan yaklaşım ), veriyi mümkün olduğunca bir kez GPU’ya yerleştirip orada tutmayı; güncellemeleri ise küçük uniform / seçici tampon yamalarıyla sınırlamayı hedefler.

Bu yüzden "dynamic buffer upload" ihtiyacını erken görür; instancing, atlasing veya paylaşımlı geometri gibi tekniklerle köprü trafiğini ölçeklenebilir hale getirirsin.

Aynı materyali ve aynı geometri önbelleğini sahne genelinde yeniden kullanmak, hem bellek hem köprü için iki kat kazançtır.

Pratik sezgi: Profilde takılma görürsen, önce "bu karede RAM→VRAM ne geçti?" diye sor; cevap uzunsa, GPU’da ne kadar akıllı shader yazdığın ikinci planda kalır.