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


11

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.


2
Saya tidak berpikir pertanyaan itu terlalu terbuka, tetapi setiap jawaban numerik akan salah dalam 12 bulan.
Dan Hulme

@ DanHulme Ya, tetapi pendekatan yang digunakan untuk mencapai efisiensi semacam itu tetap sama. Dan ketika tidak, saya telah melihat pertanyaan yang membutuhkan pembaruan jawaban secara berkala di situs pertukaran stackex lainnya, jadi saya pikir itu baik-baik saja.
Llamageddon

7
Ini benar-benar mustahil untuk dijawab. Pertama-tama, apa itu "waktu nyata" —60fps? 30? Kurang? Kedua, jawabannya akan sangat bervariasi berdasarkan GPU apa yang Anda miliki dan resolusi apa yang Anda render. Ketiga, jawabannya akan sangat bervariasi tergantung pada detail bagaimana rendering bekerja. Batas kompleksitas adegan lebih rumit daripada hanya jumlah poligon per se, tetapi melibatkan hal-hal seperti jumlah panggilan draw, perubahan status, render pass dan sebagainya — yang dipengaruhi oleh bagaimana mesin bekerja, bagaimana para seniman membangun adegan, dan sebagainya ...
Nathan Reed

1
@Lamageddon Mempertimbangkan komentar Anda, saya tidak yakin apa yang sebenarnya Anda minta. Di satu sisi, judul pertanyaan Anda cukup jelas (maksimal geometri dan cara melakukannya), tetapi seperti yang Nathan katakan, ini agak tidak mungkin dijawab. Di sisi lain, dalam komentar Anda, Anda mengatakan ingin tahu cara meminimalkan biaya per bingkai. Ini adalah pertanyaan yang sangat luas, karena Anda dapat meningkatkan / mengoptimalkan shader, grafik adegan, model, tekstur, penggunaan API, hanya segala sesuatu yang melakukan beberapa bagian dari rendering Anda. Anda mungkin dapat menulis seluruh buku tentang ini (jika belum dilakukan oleh seseorang).
Nero

1
ini agak terlambat, tetapi di sini Anda dapat melihat jala STATIC dengan 24.000.000 Verteks di Blender. Dan saya dapat memutarnya HALUS dengan 40 FPS. Saya pikir sungguh menakjubkan apa yang dapat dilakukan oleh kartu grafis modern.
user6420

Jawaban:


5

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" ...


1
Satu juta sepertinya agak rendah bagi saya.
joojaa

ambil saja berapa MPoly / s yang mampu dimiliki kartu, dan itulah FPS yang akan menghasilkan 1 juta. Saya baru saja mengingat percobaan untuk penyaji medan pada ATI4800HD. Jika Anda mengambil daftar ini en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units mereka tidak memberikan info Vertices mulai dari era arsitektur terpadu. tetapi perangkat keras berusia 10 tahun tampaknya mengiklankan sekitar 40 FPS untuk 1 juta segitiga. + cf sunting dalam jawaban saya
v.oddou

@ v.oddou Ya, tetapi untuk mendekati angka itu, Anda perlu melakukan batching geometri, atau membuat instance, dalam kasus adegan dinamis, dan itulah yang saya tanyakan. Bagaimana tidak menghambat diri Anda 2% dari jalan menuju apa yang bisa dilakukan perangkat keras.
Llamageddon

@Llamageddon aaah, begitu ya, itu memang pertanyaan. Biarkan saya melihat apa yang bisa saya katakan tentang itu. (EDIT2)
v.oddou

Jawaban mendalam yang luar biasa! Saya telah membuat beberapa pengeditan kecil, sebagai pengguna alih-alih sebagai moderator. Jangan ragu untuk membatalkan apa pun / semua jika mereka tidak sesuai dengan niat Anda.
trichoplax
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.