Berapa banyak poligon dalam sebuah adegan yang dapat dijangkau perangkat keras modern dengan tetap mempertahankan waktu nyata, dan bagaimana cara mencapainya?

Pertanyaan yang cukup mendasar, dalam beberapa hal, tetapi satu yang banyak orang, termasuk saya sendiri, tidak benar-benar tahu jawabannya. Pabrikan GPU sering mengutip angka yang sangat tinggi, dan persebaran di antara jumlah poligon yang diklaim oleh berbagai mesin permainan sering kali mencakup banyak pesanan, dan kemudian masih sangat bergantung pada banyak variabel.

Saya sadar bahwa ini adalah pertanyaan yang luas, cukup banyak, dan saya minta maaf untuk itu, saya hanya berpikir bahwa itu akan menjadi pertanyaan berharga untuk diajukan di sini.

Saya pikir secara umum diterima bahwa real time adalah segala sesuatu yang di atas interaktif. Dan interaktif didefinisikan sebagai "merespon input tetapi tidak mulus pada kenyataan bahwa animasi tersebut tampak jaggy".
Jadi waktu nyata akan tergantung pada kecepatan gerakan yang perlu diwakili. Sinema memproyeksikan pada 24 FPS dan cukup real time untuk banyak kasus.

Lalu berapa banyak poligon yang dapat ditangani mesin mudah diverifikasi dengan memeriksa sendiri. Cukup buat patch VBO kecil sebagai tes sederhana dan penghitung FPS, banyak sampel DirectX atau OpenGL akan memberi Anda test bed sempurna untuk benchmark ini.

Anda akan menemukan jika Anda memiliki kartu grafis kelas atas yang dapat Anda tampilkan sekitar 1 juta poligon secara real time. Namun, seperti yang Anda katakan, mesin tidak akan mengklaim dukungan dengan mudah karena data adegan dunia nyata akan menyebabkan sejumlah babi kinerja yang tidak terkait dengan jumlah poligon.

Kamu punya:

• tingkat pengisian
  • sampling tekstur
  • Output ROP
• membuat panggilan
• render target switch
• pembaruan buffer (seragam atau lainnya)
• penarikan berlebih
• kompleksitas shader
• kompleksitas pipa (umpan balik apa saja yang digunakan? iterasi geometri bayangan? oklusi?)
• poin sinkronisasi dengan CPU (pembacaan piksel?)
• kekayaan poligon

Bergantung pada titik lemah dan kuat dari kartu grafis tertentu, salah satu dari titik-titik ini akan menjadi hambatan. Ini tidak seperti Anda dapat mengatakan dengan pasti "itu, itu dia".

EDIT:

Saya ingin menambahkan bahwa, seseorang tidak dapat menggunakan angka spesifikasi GFlops dari satu kartu tertentu dan memetakannya secara linear ke kapasitas dorong poligon. Karena fakta bahwa perawatan poligon harus melalui bottleneck berurutan dalam pipa grafik seperti yang dijelaskan dengan sangat rinci di sini: https://fgiesen.wordpress.com/2011/07/03/a-trip-through-the-graphics -pipeline-2011-part-3 /
TLDR: simpul harus masuk ke dalam cache kecil sebelum perakitan primitif yang secara native merupakan hal yang berurutan (urutan vertex buffer penting).

Jika Anda membandingkan GeForce 7800 (berusia 9 tahun?) Dengan tahun 980 ini, tampaknya jumlah operasi per detik yang dimilikinya mampu meningkat seribu kali lipat. Tetapi Anda dapat bertaruh bahwa itu tidak akan mendorong poligon seribu kali lebih cepat (yang akan menjadi sekitar 200 miliar per detik dengan metrik sederhana ini).

EDIT2:

Untuk menjawab pertanyaan "apa yang dapat dilakukan seseorang untuk mengoptimalkan mesin", seperti pada "tidak kehilangan terlalu banyak efisiensi di sakelar keadaan dan overhead lainnya".
Itu adalah pertanyaan setua mesin itu sendiri. Dan menjadi lebih kompleks seiring dengan perkembangan sejarah.

Memang dalam situasi dunia nyata, data adegan tipikal akan mengandung banyak bahan, banyak tekstur, banyak shader berbeda, banyak membuat target dan operan, dan banyak buffer sudut dan sebagainya. Satu mesin yang saya gunakan bekerja dengan gagasan paket:

Satu paket adalah apa yang dapat dirender dengan satu panggilan undian.
Ini berisi pengidentifikasi untuk:

• buffer vertex
• buffer indeks
• kamera (memberikan target pass dan render)
• id material (memberi shader, tekstur, dan UBO)
• jarak ke mata
• terlihat

Jadi langkah pertama dari setiap frame adalah menjalankan pengurutan cepat pada daftar paket menggunakan fungsi pengurutan dengan operator yang mengutamakan visibilitas, lalu lulus, kemudian materi, lalu geometri dan akhirnya jarak.

Mendekatkan objek mendapatkan prirority untuk memaksimalkan pemusnahan Z awal.
Pass adalah langkah tetap, jadi kami tidak punya pilihan selain menghormatinya.
Bahan adalah hal yang paling mahal untuk diubah setelah target dibuat.

Bahkan di antara ID bahan yang berbeda, sub-pemesanan dapat dilakukan dengan menggunakan kriteria heuristik untuk mengurangi jumlah perubahan shader (paling mahal di dalam operasi pengalihan keadaan material), dan perubahan mengikat tekstur kedua.

Setelah semua pemesanan ini, seseorang dapat menerapkan mega texturing, texturing virtual, dan rendering atribut ( tautan ) jika dianggap perlu.

Tentang engine API juga satu hal yang umum adalah menunda penerbitan perintah pengaturan negara yang diperlukan oleh klien. Jika klien meminta "set kamera 0", yang terbaik hanya menyimpan permintaan ini dan jika nanti klien memanggil "set kamera 1" tetapi tanpa ada perintah lain di antaranya, mesin dapat mendeteksi kegunaan dari perintah pertama dan menjatuhkannya. . Ini adalah penghapusan redundansi, yang dimungkinkan dengan menggunakan paradigma "sepenuhnya dipertahankan". Dengan menentang paradigma "langsung", yang akan menjadi pembungkus di atas API asli dan mengeluarkan perintah tepat seperti yang diperintahkan oleh kode klien. ( contoh: virtrev )

Dan akhirnya, dengan perangkat keras modern, yang sangat mahal (untuk dikembangkan), tetapi langkah yang berpotensi sangat bermanfaat untuk dilakukan adalah beralih API ke gaya logam / mantel / vulkan / DX12 dan menyiapkan perintah rendering dengan tangan.

Mesin yang menyiapkan perintah rendering membuat buffer yang menyimpan "daftar perintah" yang ditimpa pada setiap frame.

Biasanya ada gagasan bingkai "anggaran", sebuah game mampu. Anda perlu melakukan semuanya dalam 16 milidetik, sehingga Anda dengan jelas mempartisi waktu GPU "2 ms untuk pass lightpre", "4 ms untuk pass bahan", "6 ms untuk penerangan tidak langsung", "4 ms untuk postprocesses" ...