CPU ve GPU Üzerinde Geometrik Dönüşümler


9

Birçok 3B programın normalde vektör / matris hesaplamaları ve CPU'daki geometrik dönüşümleri yaptığını fark ettim. Herkes bu hesaplamaları GPU'daki köşe gölgelendiricilerine taşımada bir avantaj buldu mu?

Yanıtlar:


3

Genel olarak konuşursak: Mesh dönüşümleri GPU'da yapılır. Dönüşüm matrisini GPU'ya gönderirsiniz ve gölgelendirici bunu mesh'in tüm vertic'lerine uygular.

Matrisin kendisini hesaplamak için GPU'yu kullanmak farklı bir konudur ve GPU'da aslında daha yavaştır, çünkü son dönüşüm matrisini belirlemeye yardımcı olmak için gerekli kareden kareye değişen çok fazla depolanmış değer vardır. Bu verileri CPU'ya / CPU'dan göndermek - GPU yavaştır. Ayrıca, CPU'da hesaplamalar bir kez yapılırken, GPU'da her köşe için yapılacaktır.


Wrt "GPU üzerinde aslında yavaş" bölümü; bu çok geniş bir ifadedir. GPU'daki her bir tepe noktası için matris oluşturmaktan bahsediyorsanız, performansınız darboğazlarınıza bağlı olacaktır. Yavaş performans ancak GPU'ya bağlı ALU / kayıt olmanız durumunda olur, ki durum böyle değildir. Aynı şeyi bir CPU'da yapmak da bu darboğaz senaryoları altında daha yavaş olacaktır. Bu bir örnek olduğu yaygın GPU üzerinde yapılan: anında vertex shader yapı köşe tanjant uzay matrisleri bant genişliği getirmek köşe kaydedin. Yine, darboğazlarınıza bağlı olarak, YMMV.
jpaver

Aşağı inemiyorum, ama bu cevap aşağı inmeli. "GPU'da aslında daha yavaş" demek çok yanlış.
Adam

3

GPU olmayan işlemcilerde birçok geometrik dönüşüm yapılabilir, ancak hedef platform dikkate alınmalıdır. Kilometreniz, hangi platformu hedeflediğinize ve bu platformun darboğazlarına göre değişir.

Göz önünde bulundurulması gereken bir nokta, geometriyi oluşturan aygıt ile geometriyi oluşturan aygıt arasındaki veri yolu bant genişliğidir.

Tipik bir modern PC sisteminde, CPU PCIe veri yolunun bir tarafındadır (http://en.wikipedia.org/wiki/PCI_Express) ve GPU diğer tarafındadır. Kare başına oluşturulan verileri CPU'dan GPU'ya (ve tersi) aktarabilmenin tek yolu bu veriyoludur. Bu, bu otobüsün aktarım hızı ile sınırlı olabileceğiniz anlamına gelir. Hedef platformunuzda 16 şeritli PCIe 2.x varsa, 8GB / s bant genişliğiniz vardır. Uygulamada, PCIe üzerinden yapılan aktarımlar% 100 verimli değildir, çünkü aktarımlarınız sırasında protokol için bazı bant genişliği tüketilir. Aktarımlarınızın boyutuna bağlı olarak, sadece paket başına ek yükte bant genişliğinizin% 5-10'unu kaybedebilirsiniz.

Örneğin. 16 şeritli PCIe 2.x çalıştıran bir PC platformu göz önüne alındığında, GPU'ya besleme için kare başına ne kadar veri oluşturabilirsiniz? Çalışmayı 60 fps'de istediğinizi varsayarsak, PCIe 2.x için çerçeve başına 8GB / 60 = 136MB anlamına gelir. Sürücü iletişim yükünü ve PCIe aktarım protokolü yükünü hesaba katmak için bazı (konuklanmış)% 90 faktörle çarpıldığında, PCIe 2.x bant genişliği ile sınırlandırılmadan kare başına yaklaşık 120 Mb veri üretebilirsiniz.

Cevaplamanız gereken başka bir soru: Bu 120Mb veri üretimi, hedef CPU'nuzda saniyenin 1 / 60'ında kolayca elde edilebilir mi? CPU'nuzda bir dizi başka oyun görevi yerine getirmeniz gerektiğini hatırlayarak, dönüştürülen verileri oluşturmak için zaman eksikliğinizle karşılaşabilirsiniz. Sadece saf ALU verimi açısından, bu sizi CPU'da sınırlandırabilir. CPU'dan sysmem veriyollarına gelince, bant genişliği ile de sınırlı olabilirsiniz (bu, son CPU'larda değişir, ancak ~ 8.5GB / s civarındadır).

Pekala, o zaman hangi faktörler bir GPU'da daha uygulanabilir hale getirir? Bir faktör GPU ile yerel video belleği arasındaki bant genişliği olan GPU bellek bant genişliği. Çağdaş orta menzilli GPU'larda bu video belleği bant genişliği 200GB / s kadar yüksek olabilir (evet, PCIe 2.x bant genişliğinin 25 katı). Diğer bir faktör ise GPU'nun büyük ölçüde paralel olması, yüzlerce ALU'ya sahip olması ve bir seferde binlerce iş parçacığı çalıştırarak bellek erişim gecikmesini gizleyebilmesidir.

Tüm bu faktörler, GPU üzerinde daha fazla iş itmenin bariz kazancına katkıda bulunabilir, ancak yine de hedef platformunuza bağlı olarak YMMV.


1

"Mesh dönüşümleri" ile ne demek istiyorsun? Geometriyi bir dizi matrisle dönüştürme? Bu günlerde çoğu oyun GPU'nun basit dönüşümleri, kaplamaları, vb. İşlemesine izin verecek. Ve çoğu, bunu yapmak için köşe gölgelendiricileri kullanacak. Bazı platformlarda gölgelendiriciniz yoktur veya bunları CPU'da yapmanın başka avantajları da vardır. Örneğin, PS3'te, SPU'ların kaplama ve dönüşümü ele almasına izin vererek RSX'ten biraz yük alabilirsiniz. Çoklu geçiş aydınlatması yapıyorsanız, CPU'yu kaplama yapmak avantajlı olabilir, çünkü bunu sadece bir kez yapmanız ve her bir render geçişi için çizilecek sonuçları göndermeniz gerekir. Yani istisnalar var, ancak genel olarak çoğu oyun bunları GPU'da ve gölgelendiricilerde yapıyor.

Yoksa genel vektör matematiği için GPU kullanmak gibi meraklı bir şey mi demek istediniz? Bugünlerde CUDA gibi sistemlerle oldukça genel C kodu çalıştırabilen genel amaçlı GPU'larımız var. Ağır vektör matematiği için bundan faydalanmak mümkündür ve orada bunu yapan programlar olduğunu biliyorum. Şahsen onunla herhangi bir deneyimim yok.


soruyu açıklığa kavuşturmak için "örgü dönüşümü" nü "geometrik dönüşüm" olarak değiştirdi. Ayrıca gelecek yıl gibi erken kullanılabilir opencl es bekliyorum.
zmdat

0

GPU'da her şeyin işlenmesinin mantıklı olabileceği durumlar vardır, ancak bir gölgelendiricinin içinde sabitleri ayarlayamazsınız ve bir çizim çağrısından önce CPU tarafı dışında bunları ayarlayacak başka bir yer yoktur.

GPU'da kemik dönüşüm matrisleri gibi sabitlerinizi özel bir başlatma programı ile hesaplayabilseniz bile, muhtemelen istemezsiniz. GPU paralel yürütmede gerçekten iyidir, ancak çok daha düşük bir saat hızına sahiptir.

Bir hiyerarşiyi dönüştürmek önemsiz bir şekilde paralelleştirilemez, çünkü alt düğümler ebeveynlere bağlıdır, ancak bir kafes içindeki tüm köşeleri dönüştürmek, çünkü köşeler birbirinden hesaplamalı bağımsızdır.

Genel kural:

  • Seri işleme: CPU
  • Paralel işleme: GPU
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.