Katakanlah saya ingin membuat kotak; teksturnya adalah "square.png."
Apakah lebih mudah bagi komputer untuk merendernya jika teksturnya hanya warna polos?
Dan bagaimana jika itu adalah tekstur yang sangat bising dengan warna-warna acak di sana-sini?
Atau bagaimana jika tekstur itu berisik dalam arti bahwa setiap piksel di dalamnya berbeda satu sama lain, tetapi hanya dengan sedikit saja?
Jawaban:
Seperti kebanyakan hal dalam pengembangan game, dan terutama dalam grafis game, jawabannya adalah "itu tergantung"
Resolusi tekstur Anda dapat berdampak pada kecepatan rendering. Semakin banyak piksel yang dikandungnya, semakin banyak data mentah yang ada untuk diunggah ke GPU, dan semakin sedikit tekstur yang dapat ditampung dalam cache pada satu waktu, sehingga shader mungkin menekan lebih banyak jeda saat menunggu bagian kanan tekstur untuk ditarik ke dalam cache.
Menggunakan mipmapping dapat mengurangi dampak ini. Dengan mipmaps, kami menyimpan rantai versi yang dirampingkan dari tekstur, yang pada awalnya terdengar seperti lebih banyak memori untuk digunakan. Tapi itu memungkinkan kita membaca dari versi yang lebih kecil ketika tekstur ditampilkan pada ukuran kecil di layar (seperti objek yang jauh dalam perspektif), jadi sampel kami menggunakan cache tekstur dengan lebih baik, daripada melompat-lompat. Ini juga mengurangi alias.
Konten tekstur Anda tidak memiliki dampak pada efisiensi rendering sebagian besar waktu.
Sebuah warna hanyalah sekelompok angka sejauh menyangkut GPU, jadi tidak peduli berapa angka-angka itu, itu hanya menyalurkan mereka melalui matematika dengan cara yang sama. Itu tidak melakukan sesuatu yang mewah seperti mengingat "Oh, saya telah melihat piksel dalam warna hijau ini sebelumnya, saya hanya akan menggunakan kembali output yang sama yang saya hitung terakhir kali saya melihat input ini" jadi apakah tekstur Anda semuanya satu warna atau kilau acak, GPU Anda melakukan pekerjaan yang sama.
Tidak seperti format seperti PNG & JPG, yang mengkompres lebih efisien di area gambar yang dapat diprediksi, dan memakan lebih banyak bit di wilayah kompleks, format tekstur GPU seperti BTC, ETC, PVRTC, atau bahkan RGBA mentah menggunakan jumlah bit yang tetap per blok. piksel. Jadi, membuat tekstur Anda lebih atau kurang terperinci sambil mempertahankan format kompresi yang sama tidak akan mengubah ukuran datanya atau berdampak pada transfer data dan efisiensi terkait cache.
Tetapi, jika Anda menggunakan jenis detail tertentu yang kompresi Anda sebelumnya tidak terpelihara dengan baik, Anda mungkin terpaksa mengubah seluruh gambar Anda untuk menggunakan format yang berbeda, yang lagi-lagi dapat mengubah ukuran datanya.
Inilah tanda bintang terbesar dalam situasi ini: Anda mungkin menggunakan input warna tekstur ini untuk membuat keputusan, seperti if()cabang. Di sini, detail penting untuk kecepatan.
Unit shading GPU bekerja pada blok piksel dalam batch, menjalankan instruksi yang sama secara paralel pada beberapa aliran data. Jadi, ketika beberapa piksel dalam blok mengambil satu cabang dari ifdan piksel lainnya mengambil yang lain, seluruh kumpulan harus melalui kedua cabang (menutupi hasil yang tidak berlaku untuk satu set piksel atau yang lainnya)
Jika input Anda berubah dengan cara yang halus / dapat diprediksi, maka Anda mungkin akan memiliki banyak blok yang hanya perlu mengambil satu cabang, dan kasing kedua cabang ini akan terbatas pada pita sempit di sekitar perbatasan transisi. Tetapi jika input Anda adalah acak-ish, kami berharap sebagian besar blok mengambil kedua cabang dan memperlambat rendering.
Ini juga bisa terjadi jika Anda menggunakan satu tekstur untuk mengontrol pencarian menjadi tekstur kedua, seperti distorsi atau peta indeks. Jika tekstur pertama melompat-lompat secara acak, maka kita akan mengambil sampel dari titik-titik tersebar, acak-ish dari tekstur kedua, membuat kurang konsisten menggunakan cache tekstur kita dan menunggu lebih lama untuk mendapatkan data yang kita butuhkan, rata-rata.
Jadi, secara keseluruhan: tidak, konten tekstur tidak memiliki banyak dampak pada kecepatan rendering, kecuali untuk kasus-kasus ketika itu terjadi. ;)
npiksel ke-5, Anda harus melewati setiap piksel sebelum itu. Dengan lebar byte byte yang konstan, hanya saja start_of_buffer + width * n, yang jauh lebih cepat, terutama untuk ukuran besar n.
Bersamaan dengan jawaban DMGregory yang sangat baik di atas, mungkin ada satu kasus di mana kompleksitas "tekstur" dapat memengaruhi kinerja rendering dan di situlah hasil render sebelumnya digunakan sebagai sumber pada yang berikutnya, mis. Peta bayangan / refleksi / peta lingkungan.
Beberapa perangkat keras modern mungkin menerapkan kompresi lossless ke buffer ini: misalnya PowerVR memiliki PVRIC , AMD, Delta Color Compression , dan ARM memiliki sesuatu yang serupa. Tujuan dari teknik kompresi ini adalah untuk mengurangi bandwidth keseluruhan yang, pada gilirannya, dapat meningkatkan kinerja rendering.
Semakin sederhana data, baik kedalaman atau warnanya (integer atau floating-point), semakin baik skema ini akan bekerja. Tentu saja, saya tidak akan menyarankan sengaja menyederhanakan hasil rendering Anda hanya agar ini berfungsi lebih baik, tetapi menghindari menggunakan data yang berisik mungkin membantu dalam beberapa keadaan.
Selain itu, melakukan pengambilan sampel sedikit frame / kedalaman buffer yang menggunakan skema ini, dalam upaya yang sia-sia untuk menurunkan bandwidth, tidak akan membantu karena mereka sangat mungkin berbasis blok.
Lebih lanjut, Anda mungkin menemukan dua pertanyaan dan jawaban yang menarik ini: