Bagaimana permainan 3D sangat efisien? [Tutup]


188

Ada sesuatu yang tidak pernah saya mengerti. Bagaimana gim PC besar seperti GTA IV dapat menggunakan 50% CPU saya dan berjalan pada 60fps sedangkan demo DX dari Teapot @ 60fps yang berputar menggunakan 30% kekalahan?


124
Saya tidak melihat apa yang salah dengan pertanyaan ini - sangat wajar untuk penasaran tentang bagaimana pengembang lain telah mencapai hal-hal tertentu. Kita harus mendorong keingintahuan semacam ini, tidak menghukumnya dengan suara dekat.
John Feminella

2
@ user146780: yang mengajukan pertanyaan ... Programmer terbaik yang pernah saya temui bekerja di CGI. Gurus dari SGI, orang yang bekerja secara paralelisasi Adobe Photoshop, dll. Orang-orang di sini tidak menyadari betapa rumitnya menulis game modern atau betapa terampilnya coders ini. Jika Anda ingin pengalaman yang merendahkan hati, lihat apa yang dilakukan orang Jerman dari Cryotech dengan mesin Crysis. Ada video di Youtube. Anda tidak akan mempercayainya. Ini bukan hanya tentang "menggunakan octrees". Biasanya programmer ini jauh lebih terampil daripada programmer rata-rata. Dan Anda dapat bertaruh bahwa coders GT4 sangat bagus.
SyntaxT3rr0r

2
Anda membuat gta4 berjalan pada kecepatan 60fps !? GW! gta4 adalah POS yang berjalan sangat buruk, saya pernah mendengar Force unleashed juga. Saya akan mengatakan Euphoria adalah pelakunya. jujur, "penggunaan CPU" adalah cara yang sangat buruk untuk membandingkan, cukup membuka frame rate dan melihat mana yang berjalan paling cepat, itulah cara yang tepat untuk melakukannya. juga, ingat, "permainan rumit" ini walaupun mungkin menghasilkan banyak hal, masih ada hanya barang seharga layar, dan jika itu ditampilkan dalam urutan yang benar, Anda mungkin berakhir dengan jumlah piksel yang hampir sama dengan pekerjaan Anda Demo "sederhana", dan kerja piksel benar-benar yang membunuhnya.
matt

8
Anda memerlukan profiler yang menunjukkan seberapa banyak GPU (Graphics Processing Unit) digunakan. Saya yakin GTA IV menunjukkan Anda ~ 99%, dan demo 3%.
0scar

Dari pengalaman, sekitar 10% dari programmer game yang pernah saya ajak bekerja sama bagusnya, sisanya rata-rata di terbaik. Beberapa sangat tidak kompeten.
Skizz

Jawaban:


69

Secara umum, itu karena

  1. Permainan menjadi optimal tentang apa yang harus mereka render, dan
  2. Mereka mengambil keuntungan khusus dari perangkat keras Anda.

Misalnya, satu optimasi mudah yang dapat Anda lakukan melibatkan tidak benar-benar mencoba menggambar hal-hal yang tidak dapat dilihat. Pertimbangkan pemandangan kompleks seperti lanskap kota dari Grand Theft Auto IV . Penyaji sebenarnya tidak merender semua bangunan dan struktur. Alih-alih, ini hanya menampilkan apa yang dapat dilihat kamera. Jika Anda bisa terbang ke belakang gedung-gedung yang sama, menghadap kamera asli, Anda akan melihat struktur cangkang cekung yang sudah setengah jadi. Setiap titik yang tidak dapat dilihat oleh kamera tidak dirender - karena Anda tidak dapat melihatnya, tidak perlu mencoba menunjukkannya kepada Anda.

Selain itu, instruksi yang dioptimalkan dan teknik khusus ada ketika Anda berkembang melawan perangkat keras tertentu, untuk memungkinkan speedup yang lebih baik.

Bagian lain dari pertanyaan Anda adalah mengapa demo menggunakan banyak CPU:

... sementara demo DX dari Teapot @ 60fps yang berputar menggunakan 30% kekalahan?

Demo API grafis (seperti dxdemo) umum untuk kembali ke apa yang disebut perender perangkat lunak ketika perangkat keras Anda tidak mendukung semua fitur yang diperlukan untuk menunjukkan contoh yang bagus. Fitur-fitur ini mungkin termasuk hal-hal seperti bayangan, refleksi, penelusuran sinar, fisika, dan lain-lain.

Ini meniru fungsi perangkat keras berfitur lengkap yang tidak mungkin ada, untuk memamerkan semua fitur API. Tetapi karena perangkat keras itu sebenarnya tidak ada, itu berjalan pada CPU Anda sebagai gantinya. Itu jauh lebih tidak efisien daripada mendelegasikan ke kartu grafis - karenanya penggunaan CPU Anda tinggi.


3
Demo DX menggunakan perangkat keras Anda juga. Jadi, apa yang 'istimewa'?
tur1ng

3
tetapi demo tidak mungkin menjadi optimal tentang hal itu.
μBio

2
@ tur1ng, demo teko, misalnya, mungkin mengaktifkan refleksi , bayangan , dan efek lainnya.
Nick Dandoulakis

2
Teko mungkin memiliki lebih banyak poligon daripada adegan GTA4. Faktanya adalah, bottleneck saat ini dalam rendering grafis lebih banyak efek tekstur seperti teknik bump mapping yang diturunkan untuk menambahkan detail dan efek post rendering lainnya.
Klaim

5
Tekstur - teko dibuat dari sejumlah besar segitiga individu semua dengan interaksi normal dan pencahayaan. Apa yang tampak seperti dunia 3d yang luar biasa rumit dalam permainan seringkali merupakan blok besar yang cukup sederhana yang ditutupi dengan gambar terperinci. Banyak '3d' adalah bayangan pintar dan efek artistik perspektif dalam gambar 2d statis yang digambar pada bentuk 3d
Martin Beckett

96

Kesabaran, keterampilan teknis, dan daya tahan.

Poin pertama adalah bahwa Demo DX terutama merupakan alat bantu pengajaran sehingga dilakukan untuk kejelasan, bukan kecepatan eksekusi.

Ini adalah subjek yang cukup besar untuk menyingkat tetapi pengembangan game terutama tentang memahami data Anda dan jalur eksekusi Anda ke tingkat yang hampir patologis.

  1. Kode Anda dirancang berdasarkan dua hal - data Anda dan perangkat keras target Anda.
  2. Kode tercepat adalah kode yang tidak pernah dieksekusi - urutkan data Anda menjadi beberapa batch dan hanya lakukan operasi mahal pada data yang Anda perlukan
  3. Bagaimana Anda menyimpan data Anda adalah kunci - bertujuan untuk akses yang berdekatan ini memungkinkan Anda untuk batch proses dengan kecepatan tinggi.
  4. Paralelkan segala yang Anda bisa
  5. CPU modern cepat, RAM modern sangat lambat. Kehilangan cache sangat mematikan.
  6. Dorong GPU sebanyak yang Anda bisa - ini memiliki memori lokal cepat sehingga dapat merambah data tetapi Anda perlu membantunya dengan mengatur data Anda dengan benar.
  7. Hindari melakukan banyak switch renderstate (lagi-lagi batch data vertex serupa bersama-sama) karena ini menyebabkan GPU terhenti
  8. Remas tekstur Anda dan pastikan keduanya adalah kekuatan dua - ini meningkatkan kinerja cache tekstur pada GPU.
  9. Gunakan level detail sebanyak yang Anda bisa - versi rendah / menengah / tinggi dari model 3D dan beralih berdasarkan jarak dari pemain kamera - tidak ada gunanya merender versi resolusi tinggi jika hanya 5 piksel di layar.

39

Game 3D sangat bagus untuk menipu mata Anda. Sebagai contoh, ada teknik yang disebut screen space ambient occlusion (SSAO) yang akan memberikan nuansa yang lebih realistis dengan membayangi bagian-bagian adegan yang dekat dengan diskontinuitas permukaan. Jika Anda melihat sudut-sudut dinding Anda, Anda akan melihat mereka tampak sedikit lebih gelap daripada bagian tengah dalam banyak kasus.

Efek yang sama dapat dicapai dengan menggunakan radiositas, yang didasarkan pada simulasi yang agak akurat. Radiositas juga akan memperhitungkan lebih banyak efek lampu memantul, dll. Tetapi ini mahal secara komputasi - ini adalah teknik penelusuran sinar.

Ini hanya satu contoh. Ada ratusan algoritma untuk grafik komputer waktu nyata dan pada dasarnya didasarkan pada perkiraan yang baik dan biasanya membuat banyak asumsi. Misalnya, penyortiran spasial harus dipilih dengan sangat hati-hati tergantung pada kecepatan, posisi khas kamera serta jumlah perubahan pada geometri pemandangan.

'Optimalisasi' ini sangat besar - Anda dapat mengimplementasikan suatu algoritma secara efisien dan membuatnya berjalan 10 kali lebih cepat, tetapi memilih algoritma yang cerdas yang menghasilkan hasil yang serupa ("curang") dapat membuat Anda beralih dari O (N ^ 4) ke O ( log (N)).

Mengoptimalkan implementasi sebenarnya adalah apa yang membuat game lebih efisien, tetapi itu hanya optimasi linier.


30

Eeeeek!

Saya tahu bahwa pertanyaan ini sudah lama, tetapi menarik bahwa tidak ada yang menyebutkan VSync !!! ???

Anda membandingkan penggunaan CPU game pada 60fps dengan penggunaan CPU dari demo teko di 60fps.

Bukankah sudah jelas, bahwa keduanya berjalan (lebih atau kurang) tepat pada 60fps? Itu mengarah pada jawaban ...

Kedua aplikasi berjalan dengan vsync diaktifkan! Ini berarti (dumbed-down) bahwa framerate rendering dikunci ke "interval kosong vertikal" monitor Anda. Perangkat keras grafis (dan / atau driver) hanya akan memberikan maksimum. 60fps. 60fps = 60Hz (Hz = per detik) refresh rate. Jadi, Anda mungkin menggunakan CRT yang agak tua dan berkedip atau layar LCD biasa. Pada CRT berjalan pada 100Hz Anda mungkin akan melihat framerates hingga 100Hz. VSync juga berlaku dalam cara yang mirip dengan display LCD (mereka biasanya memiliki kecepatan refresh 60Hz).

Jadi, demo teko sebenarnya dapat berjalan jauh lebih efisien! Jika menggunakan 30% waktu CPU (dibandingkan dengan 50% waktu CPU untuk GTA IV), maka mungkin menggunakan lebih sedikit waktu cpu setiap frame, dan hanya menunggu lebih lama untuk interval kosong vertikal berikutnya. Untuk membandingkan kedua aplikasi, Anda harus menonaktifkan vsync dan mengukur lagi (Anda akan mengukur fps yang jauh lebih tinggi untuk kedua aplikasi).

Kadang-kadang ok untuk menonaktifkan vsync (sebagian besar game memiliki opsi dalam pengaturannya). Terkadang Anda akan melihat "merobek artefak" ketika vsync dinonaktifkan.

Anda dapat menemukan detailnya dan mengapa itu digunakan di wikipedia: http://en.wikipedia.org/wiki/Vsync


Saya setuju, untuk mendapatkan perbandingan yang lebih baik Anda harus menonaktifkan vsync. Namun, akar masalah masih ada. 30% untuk teko vs 50% penggunaan cpu untuk permainan adalah perbedaan yang lebih kecil dari yang biasanya diharapkan. Tapi saya ingat pada hari-hari awal ketika pemetaan lingkungan mulai menjadi populer dan demo nVidia yang keren pada saat itu adalah teko yang dipetakan oleh lingkungan yang berputar. Demo-demo itu biasanya bahkan tidak mencapai 60 fps pada hari itu. Saya kira maksud saya adalah bahwa demo teko ini sering mendorong batas-batas efek visual baru.
Steve Wortham

25

Sementara banyak jawaban di sini memberikan indikasi yang sangat baik tentang bagaimana saya akan menjawab pertanyaan sederhana mengapa

Mungkin contoh terbaik (tentunya salah satu yang paling terkenal) adalah perangkat lunak Id. Mereka menyadari sangat awal, pada zaman Commander Keen (jauh sebelum 3D) bahwa datang dengan cara yang cerdas untuk mencapai sesuatu 1 , bahkan jika itu bergantung pada perangkat keras modern (dalam hal ini kartu grafis EGA!) Yang secara grafis lebih unggul daripada kompetisi yang akan membuat game Anda menonjol. Ini benar tetapi mereka lebih jauh menyadari bahwa, daripada harus datang dengan permainan baru dan konten sendiri mereka dapat melisensikan teknologi, sehingga mendapatkan penghasilan dari orang lain sementara mampu mengembangkan mesin generasi berikutnya dan dengan demikian melompati kompetisi lagi .

Kemampuan para programmer ini (ditambah dengan pengetahuan bisnis) adalah apa yang membuat mereka kaya.

Yang mengatakan itu belum tentu uang yang memotivasi orang semacam itu. Mungkin hanya keinginan untuk mencapai, untuk mencapai. Uang yang mereka peroleh di hari-hari awal hanya berarti bahwa mereka sekarang memiliki waktu untuk mencurahkan apa yang mereka nikmati. Dan sementara banyak yang memiliki minat luar hampir semua masih program dan mencoba mencari cara untuk melakukan lebih baik daripada iterasi terakhir.

Sederhananya orang yang menulis demo teko kemungkinan memiliki satu atau lebih masalah berikut:

  • lebih sedikit waktu
  • lebih sedikit sumber daya
  • kurang insentif hadiah
  • kurang kompetisi internal dan eksternal
  • tujuan yang lebih rendah
  • lebih sedikit talenta

Yang terakhir mungkin terdengar keras 2 tetapi jelas ada beberapa yang lebih baik daripada yang lain, kurva lonceng kadang-kadang memiliki ujung yang ekstrem dan mereka cenderung tertarik pada ujung ekstrem yang sesuai dari apa yang dilakukan dengan keterampilan itu.

Tujuan yang lebih kecil yang kemungkinan besar menjadi alasan utama. Target dari demo teko adalah hanya itu, sebuah demo. Tapi bukan demo dari skill programmer 3 . Ini akan menjadi demo dari satu sisi kecil dari OS (besar), dalam hal ini rendering DX.

Bagi mereka yang melihat demo itu tidak akan mater itu digunakan lebih banyak CPU daripada yang diperlukan selama itu terlihat cukup baik. Tidak akan ada insentif untuk menghilangkan limbah ketika tidak akan ada penerima manfaat. Sebagai perbandingan, sebuah game akan senang memiliki siklus cadangan untuk AI yang lebih baik, suara yang lebih baik, lebih banyak poligon, lebih banyak efek.


  1. dalam hal ini, gulir mulus pada perangkat keras PC
  2. Mungkin lebih dari saya jadi kami jelas tentang itu
  3. sebenarnya itu akan menjadi demo untuk manajernya juga, tapi sekali lagi drive di sini adalah waktu dan / atau kualitas visual.

17

Karena beberapa alasan

  • Mesin game 3D sangat dioptimalkan
  • sebagian besar pekerjaan dilakukan oleh adaptor grafis Anda
  • 50% Hm, saya kira Anda memiliki dual core dan hanya satu core yang digunakan ;-)

EDIT: Untuk memberikan beberapa angka

2,8 Ghz Athlon-64 dengan NV-6800 GPU. Hasilnya adalah:

  • CPU: 72,78 Mflops
  • GPU: 2440,32 Mflops

@stacker: apakah Anda menyiratkan bahwa semua perhitungan yang terjadi dalam game 3D terbaik yang tidak dilakukan oleh GPU sebenarnya adalah mono-threaded dan, jika tidak sengaja, akan mengisi 100% CPU? Berarti perf game akan terikat pada satu inti non-GPU? Saya merasa sangat sulit untuk percaya.
SyntaxT3rr0r

4
Itu tidak menyiratkan program ini adalah satu-threaded - itu hanya menyiratkan bahwa setidaknya satu utas berjalan secepat mungkin. Yang masuk akal, karena mengapa Anda ingin itu berjalan lebih lambat? Di sisi lain, banyak gim yang hampir seluruhnya mono-threaded. Sangat sulit untuk menulis simulasi kompleks dengan cara yang efektif ketika multithreading karena situasi tipikal dalam sistem bersamaan / terdistribusi menerima sedikit latensi untuk membeli lebih banyak throughput tidak baik untuk permainan yang seharusnya responsif.
Kylotan

8

Terkadang sebuah adegan mungkin memiliki lebih banyak kejadian daripada yang terlihat. Sebagai contoh, teko berputar dengan ribuan titik, pemetaan lingkungan, pemetaan benjolan, dan pixel shaders kompleks lainnya yang diberikan secara bersamaan berjumlah total banyak pemrosesan. Seringkali demo teko ini dimaksudkan untuk memamerkan semacam efek khusus. Mereka juga mungkin tidak selalu memanfaatkan GPU ketika kinerja absolut bukanlah tujuannya.

Dalam gim Anda mungkin melihat efek yang serupa tetapi biasanya dilakukan dengan cara yang dikompromikan dalam upaya untuk memaksimalkan frame rate. Optimalisasi ini mencakup semua yang Anda lihat dalam game. Masalahnya menjadi, "Bagaimana kita bisa membuat adegan paling spektakuler dan realistis dengan kekuatan pemrosesan paling sedikit?" Itulah yang membuat programmer game beberapa pengoptimal terbaik di sekitar.


4
  1. Manajemen adegan. kd-tree, culling frustrum, bsps, kotak pembatas pusaka, set visibilitas parsial.
  2. Tuhan Mengalihkan versi detail yang lebih rendah untuk menggantikan objek jauh.
  3. Penipu. Suka LOD tetapi bahkan bukan objek hanya gambar atau 'papan iklan'.
  4. SIMD.
  5. Manajemen memori khusus. Memori selaras, kurang fragmentasi.
  6. Struktur data khusus (yaitu tidak ada STL, template yang relatif minimal).
  7. Perakitan di tempat, terutama untuk SIMD.

4

Dengan semua jawaban yang memenuhi syarat dan baik yang diberikan, salah satu yang masih hilang adalah: Penghitung penggunaan CPU Windows tidak terlalu dapat diandalkan. Saya kira demo teko sederhana ini hanya memanggil fungsi rendering di loop idle-nya, memblokir buffer swap.

Sekarang penghitung pemanfaatan CPU Windows hanya melihat berapa banyak waktu CPU dihabiskan dalam setiap proses, tetapi tidak bagaimana waktu CPU ini digunakan. Coba tambahkan a

Sleep(0);

tepat setelah kembali dari fungsi rendering, dan bandingkan.


Saya memiliki demo teko DX yang selalu menggunakan 25% CPU saya. Ternyata itu karena saya menggunakan quad core dan, untuk mengunci loop game pada 60 fps, saya memiliki loop "Apakah kita sudah sampai" yang terus-menerus memeriksa waktu. Saya mengubahnya menjadi sleep (timeToNextFrame) dan penggunaan cpu turun menjadi mendekati 0.
Jonathan Pierce

3

Selain itu, ada banyak trik dari sudut pandang artistik untuk menghemat daya komputasi. Dalam banyak gim, terutama yang lebih tua, bayangan dihitung sebelumnya dan "dipanggang" tepat di tekstur peta. Banyak kali, para seniman mencoba menggunakan pesawat (dua segitiga) untuk mewakili hal-hal seperti pohon dan efek khusus ketika sebagian besar terlihat sama. Kabut dalam gim adalah cara mudah untuk menghindari render objek yang jauh, dan seringkali, gim akan memiliki banyak resolusi dari setiap objek untuk pandangan jauh, tengah, dan dekat.


1

Inti dari jawaban apa pun seharusnya adalah ini - Transformasi yang dilakukan mesin 3D sebagian besar ditentukan dalam penambahan dan perkalian (aljabar linier) (tanpa cabang atau lompatan), operasi menggambar suatu bingkai tunggal sering ditentukan dengan cara yang banyak pekerjaan add-mul seperti itu dapat dilakukan secara paralel. Inti GPU adalah add-mul's yang sangat bagus, dan mereka memiliki puluhan atau ratusan inti add-mull.

CPU dibiarkan melakukan hal-hal sederhana - seperti AI dan logika game lainnya.


1

Bagaimana gim PC besar seperti GTA IV dapat menggunakan 50% CPU saya dan berjalan pada 60fps sedangkan demo DX dari Teapot @ 60fps yang berputar menggunakan 30% kekalahan?

Sementara GTA sangat mungkin lebih efisien daripada demo DX, mengukur efisiensi CPU dengan cara ini pada dasarnya rusak. Efisiensi dapat didefinisikan misalnya dengan berapa banyak pekerjaan yang Anda lakukan per waktu tertentu. Contoh tandingan sederhana: menelurkan satu utas per CPU logis dan biarkan loop infinite sederhana berjalan di atasnya. Anda akan mendapatkan penggunaan CPU 100%, tetapi tidak efisien, karena tidak ada pekerjaan yang bermanfaat dilakukan.

Ini juga mengarah pada sebuah jawaban: bagaimana sebuah game bisa efisien? Saat memprogram "game besar yang hebat", upaya besar didedikasikan untuk mengoptimalkan game di semua aspek (yang saat ini biasanya juga mencakup optimasi multi-core). Sedangkan untuk demo DX, intinya tidak berjalan cepat, melainkan menunjukkan konsep.


1

Saya pikir Anda harus melihat pemanfaatan GPU daripada CPU ... Saya bertaruh kartu grafis jauh lebih sibuk di GTA IV daripada di sampel Teapot (seharusnya praktis tidak digunakan).

Mungkin Anda bisa menggunakan monitor seperti ini untuk memeriksa:

http://downloads.guru3d.com/Rivatuner-GPU-Monitor-Vista-Sidebar-Gadget-download-2185.html

Juga framerate adalah sesuatu yang perlu dipertimbangkan, mungkin sampel teko berjalan dengan kecepatan penuh (mungkin 1000fps) dan sebagian besar permainan terbatas pada frekuensi refresh monitor (sekitar 60fps).


1

Lihatlah jawabannya di vsync; itulah sebabnya mereka menjalankan frame rate yang sama.

Kedua, CPU ketinggalan memimpin dalam sebuah game. Penjelasan yang disederhanakan adalah bahwa loop game utama hanya loop infinite:

while(1) { 
  update();
  render();
}

Bahkan jika gim Anda (atau dalam hal ini, teko) tidak melakukan banyak hal, Anda masih memakan CPU di loop Anda.

50% cpu di GTA adalah "lebih produktif" daripada 30% dalam demo, karena lebih dari itu kemungkinannya tidak melakukan banyak hal sama sekali; tetapi GTA memperbarui banyak detail. Bahkan menambahkan "Tidur (10)" ke demo mungkin akan menurunkan CPU sebesar satu ton.

Terakhir lihat penggunaan GPU. Demo mungkin mengambil <1% pada kartu video modern sementara GTA mungkin akan menjadi mayoritas saat bermain game.

Singkatnya, tolok ukur dan pengukuran Anda tidak akurat.


1

Demo teko DX tidak menggunakan 30% dari CPU melakukan pekerjaan yang bermanfaat. Ini sibuk menunggu karena tidak ada lagi yang bisa dilakukan.


0

Dari apa yang saya ketahui tentang seri Unreal beberapa konvensi rusak seperti enkapsulasi. Kode dikompilasi menjadi bytecode atau langsung ke kode mesin tergantung pada gim. Juga, objek dirender dan dikemas dalam bentuk jerat dan hal-hal seperti tekstur, pencahayaan dan bayangan dihitung sebelumnya sedangkan animasi 3d murni mengharuskan ini untuk waktu nyata ini. Ketika permainan benar-benar berjalan ada juga beberapa optimasi seperti hanya menampilkan bagian-bagian yang terlihat dari suatu objek dan menampilkan detail tekstur hanya ketika menutup. Akhirnya, ada kemungkinan bahwa video game dirancang untuk mendapatkan yang terbaik dari suatu platform pada waktu tertentu (mis: Intelx86 MMX / SSE, DirectX, ...).


0

Saya pikir ada bagian penting dari jawaban yang hilang di sini. Sebagian besar jawaban memberi tahu Anda "Ketahui data Anda". Faktanya adalah bahwa Anda harus, dengan cara yang sama dan dengan tingkat kepentingan yang sama, juga tahu Anda:

  • CPU (jam dan cache)
  • Memori (frekuensi dan latensi)
  • Hard drive (dalam hal kecepatan dan waktu pencarian)
  • GPU (# Skor, jam dan Memori / Temboloknya)
  • Antarmuka: pengontrol data, revisi PCI, dll.

TETAPI , di atas semua itu, dengan komputer modern saat ini, Anda tidak akan pernah bisa memutar video 1080p sungguhan di >> 30ftp (gambar 1080p tunggal dalam 64bit membutuhkan waktu 15.000 Ko / 14.9 MB). Alasan untuk itu adalah karena pengambilan sampel / presisi. Sebuah gim video tidak akan pernah menggunakan presisi ganda (64 bit) untuk piksel, gambar, data, dll ..., melainkan menggunakan presisi khusus yang lebih rendah (~ 4-8 bit) dan kadang-kadang kurang presisi yang diperbesar dengan teknik interpolasi untuk memungkinkan perhitungan yang masuk akal waktu.

Ada teknik lain juga seperti Memotong data (baik dengan standar OpenGL dan implementasi perangkat lunak), kompresi data, dll. Perlu diingat, bahwa GPU saat ini dapat> 300 kali lebih cepat dari CPU saat ini dalam hal kemampuan perangkat keras. Namun, programmer yang baik mungkin mendapatkan faktor 10-20x, kecuali masalah Anda sepenuhnya dioptimalkan dan sepenuhnya dapat diparalelkan (terutama tugas yang dapat diparalelkan).

Berdasarkan pengalaman, saya dapat memberi tahu Anda bahwa pengoptimalan seperti kurva eksponensial. Untuk mencapai kinerja optimal, waktu yang dibutuhkan mungkin sangat penting.

Jadi untuk kembali ke teko, Anda harus melihat bagaimana geometri diwakili, disampel dan dengan presisi apa yang dilihat di GTA 5, dalam hal geometri / tekstur dan yang paling penting, detailnya (presisi, pengambilan sampel, dll.)

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.