Modern donanım gerçek zamanlı olarak korunurken bir sahnede kaç çokgen ulaşabilir ve oraya nasıl ulaşılır?

Oldukça basit, bazı açılardan, ama kendim dahil birçok insanın cevabını gerçekten bilmediği bir soru. GPU üreticileri genellikle çok yüksek sayılardan bahseder ve çeşitli oyun motorlarının desteklediğini iddia ettikleri çokgen sayıları arasındaki yayılma, genellikle birden fazla büyüklük sırasına yayılır ve yine de büyük ölçüde birçok değişkene bağlıdır.

Bunun geniş, oldukça açık uçlu bir soru olduğunun farkındayım ve bunun için özür dilerim, yine de burada olmanın değerli bir soru olacağını düşündüm.

Bence gerçek zamanın interaktif olan her şey olduğu kabul edilir. Ve etkileşimli olarak "girdiye yanıt verir, ancak animasyonun pürüzlü görünmesi gerçeği düzgün değildir" olarak tanımlanır.
Dolayısıyla, gerçek zaman kişinin temsil etmesi gereken hareketlerin hızına bağlı olacaktır. Sinema 24 FPS'de projelendirilir ve birçok vaka için yeterince gerçek zamanlıdır.

Daha sonra bir makinenin kaç poligonla başa çıkabileceğini kendiniz kontrol ederek kolayca doğrulayabilirsiniz. Basit bir test ve FPS sayacı olarak küçük bir VBO yaması oluşturun, birçok DirectX veya OpenGL örneği size bu kıyaslama testi için mükemmel bir test yatağı verecektir.

Gerçek zamanlı olarak yaklaşık 1 milyon çokgen görüntüleyebileceğiniz üst düzey bir grafik kartınız olup olmadığını göreceksiniz. Ancak, dediğiniz gibi, motorlar bu kadar kolay destek talep etmeyecektir, çünkü gerçek dünya sahne verileri çokgen sayısıyla ilgisi olmayan bir dizi performans domuzuna neden olacaktır.

Var:

• doldurma oranı
  • doku örnekleme
  • ROP çıkışı
• çağrı çekmek
• hedef anahtarları oluşturma
• arabellek güncellemeleri (tek tip veya diğer)
• Fazla çizim
• gölgelendirici karmaşıklığı
• boru hattı karmaşıklığı (kullanılan herhangi bir geri besleme? yinelemeli geometri gölgelemesi? oklüzyon?)
• noktaları CPU ile senkronize etme (piksel okuma?)
• çokgen zenginliği

Belirli bir grafik kartının zayıf ve güçlü noktalarına bağlı olarak, bu noktalardan biri veya diğeri darboğaz olacaktır. Kesinlikle "orada, bu" diyebileceğiniz gibi değil.

DÜZENLE:

Bunu eklemek istedim, biri belirli bir kartın GFlops spec figürünü kullanamaz ve çokgen itme kapasitesine doğrusal olarak eşleştiremez. Çokgen işleminin, burada ayrıntılı olarak açıklandığı gibi grafik boru hattında sıralı bir darboğazdan geçmesi gerektiği için: https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR: Köşeler, sıralı bir şey olan ilkel montajdan önce küçük bir önbelleğe sığmalıdır (tepe tamponu sırası önemlidir).

GeForce 7800'ü (9 yaşında?) Bu yılki 980 ile karşılaştırırsanız, yapabildiği saniyedeki işlem sayısı bin kat arttı. Ancak, çokgenleri bin kat daha hızlı itmeyeceğine bahse girebilirsiniz (bu basit metrikle saniyede 200 milyar civarında olacaktır).

EDIT2:

"Durum anahtarlarında ve diğer genel giderlerde çok fazla verimlilik kaybetmemek" gibi "bir motoru optimize etmek için ne yapabilir" sorusunu yanıtlamak.
Bu, motorlar kadar eski bir sorudur. Ve tarih ilerledikçe daha karmaşık hale geliyor.

Gerçekten de gerçek dünya durumunda, tipik sahne verileri birçok malzeme, birçok doku, birçok farklı gölgelendirici, birçok render hedefi ve geçişi ve birçok köşe tamponu vb. Birlikte çalıştığım bir motor paket kavramıyla çalıştı:

Bir paket, bir çizim çağrısı ile oluşturulabilen şeydir.
Aşağıdakiler için tanımlayıcılar içerir:

• köşe tamponu
• dizin arabelleği
• kamera (geçişi ve oluşturma hedefini verir)
• malzeme kimliği (gölgelendirici, dokular ve UBO verir)
• göz mesafesi
• görünür

Bu nedenle, her karenin ilk adımı, görünürlük önceliği veren, daha sonra geçiren, sonra malzeme, sonra geometri ve son olarak mesafeyi veren bir işleçle bir sıralama işlevi kullanarak paket listesinde hızlı bir sıralama yapmaktır.

Yakın nesneleri çizmek, erken Z kaldırma işlemini en üst düzeye çıkarmak için ihtiyatlı davranır.
Geçişler sabit adımlardır, bu yüzden onlara saygı duymaktan başka seçeneğimiz yoktur.
Malzeme, oluşturma hedeflerinden sonra geçiş yapmak için en pahalı şeydir.

Farklı malzeme kimlikleri arasında bile, gölgelendirici değişikliklerinin sayısını (malzeme durumu değiştirme işlemleri içinde en pahalı olan) ve ikinci olarak doku bağlama değişikliklerini azaltmak için sezgisel bir ölçüt kullanılarak bir alt sipariş yapılabilir.

Tüm bu sıralamadan sonra, gerekli görüldüğü takdirde mega doku, sanal doku ve niteliksiz render ( link ) uygulanabilir.

Motor API'sı hakkında da ortak bir şey, istemcinin gerektirdiği durum belirleme komutlarının verilmesini ertelemektir. Bir müşteri "kamera 0'ı ayarla" isterse, sadece bu isteği saklamak en iyisidir ve daha sonra müşteri "kamera 1'i ayarla" derse, ancak aralarında başka komutlar yoksa, motor ilk komutun işe yaramazlığını algılayıp bırakabilir . Bu, "tamamen korunmuş" bir paradigma kullanılarak mümkün olan artıklık ortadan kaldırmasıdır. "Anında" paradigmaya karşı çıkarak, yerel API'nin üzerinde sadece bir sarıcı olacak ve komutları istemci koduyla sipariş edildiği gibi yayınlayacaktır. ( örnek: virtrev )

Ve son olarak, modern donanım ile, çok pahalı (geliştirmek için), ancak potansiyel olarak oldukça ödüllendirici bir adım, API'yi metal / manto / vulkan / DX12 stiline geçirmek ve render komutlarını elle hazırlamaktır.

Görüntü oluşturma komutları hazırlayan bir motor, her karenin üzerine yazılan bir "komut listesi" içeren bir arabellek oluşturur.

Genellikle çerçeve "bütçe" bir kavram vardır, bir oyun göze alabilir. Her şeyi 16 milisaniyede yapmanız gerekir, böylece GPU zamanını "lightpre geçişi için 2 ms", "malzeme geçişi için 4 ms", "dolaylı aydınlatma için 6 ms", "postprosesler için 4 ms" bölümünü açıkça ayırırsınız ...