Mengapa sumber daya ubin diperlukan?

Sumber daya ubin diperlukan sehingga memori unit pemrosesan grafis (GPU) yang lebih sedikit terbuang untuk menyimpan wilayah permukaan yang diketahui aplikasi tidak akan diakses, dan perangkat keras dapat memahami cara memfilter di seluruh petak peta yang berdekatan.

Dalam sistem grafis (yaitu, sistem operasi, driver tampilan, dan perangkat keras grafis) tanpa dukungan sumber daya ubin, sistem grafis mengelola semua alokasi memori Direct3D pada granularitas sub sumber daya. Untuk Buffer, seluruh Buffer adalah subsumber daya. Untuk Tekstur (misalnya, Texture2D), setiap tingkat mip adalah sub sumber daya; untuk array tekstur (misalnya, Texture2DArray), setiap tingkat mip pada poong array tertentu adalah subsumber daya. Sistem grafis hanya memaparkan kemampuan untuk mengelola pemetaan alokasi pada granularitas sub sumber daya ini. Dalam konteks sumber daya ubin, "pemetaan" mengacu pada pembuatan data yang terlihat oleh GPU.

Misalkan aplikasi tahu bahwa operasi penyajian tertentu hanya perlu mengakses sebagian kecil rantai mipmap gambar (bahkan mungkin tidak area penuh dari mipmap tertentu). Idealnya, aplikasi ini dapat menginformasikan sistem grafis tentang kebutuhan ini. Sistem grafis kemudian hanya akan repot-repot untuk memastikan bahwa memori yang diperlukan dipetakan pada GPU tanpa halaman dalam terlalu banyak memori. Pada kenyataannya, tanpa dukungan sumber daya petak peta, sistem grafis hanya dapat diberitahu tentang memori yang perlu dipetakan pada GPU pada granularitas sub sumber daya (misalnya, rentang tingkat mipmap penuh yang dapat diakses). Tidak ada kesalahan permintaan dalam sistem grafis, jadi berpotensi banyak kelebihan memori GPU harus digunakan untuk membuat sub sumber daya penuh dipetakan sebelum perintah penyajian yang mereferensikan bagian mana pun dari memori dijalankan. Ini hanyalah salah satu masalah yang membuat penggunaan alokasi memori besar sulit di Direct3D tanpa dukungan sumber daya ubin.

Direct3D 11 mendukung permukaan Texture2D dengan hingga 16384 piksel di sisi tertentu. Gambar yang lebarnya 16384 dengan tinggi 16384 dan 4 byte per piksel akan menggunakan memori video 1GB (dan menambahkan mipmap akan menggandakan jumlah tersebut). Dalam praktiknya, semua 1GB jarang perlu dirujuk dalam satu operasi penyajian.

Beberapa pengembang game memodelkan permukaan medan sebesar 128K sebesar 128K. Cara mereka mendapatkan ini untuk bekerja pada GPU yang ada adalah dengan memecah permukaan menjadi ubin yang cukup kecil untuk ditangani perangkat keras. Aplikasi harus mencari tahu petak peta mana yang mungkin diperlukan dan memuatnya ke dalam cache tekstur pada GPU - sistem paging perangkat lunak. Kelemahan signifikan dari pendekatan ini berasal dari perangkat keras yang tidak mengetahui apa pun tentang penomoran yang sedang berlangsung: Ketika bagian dari gambar perlu ditampilkan pada layar yang menganga petak peta, perangkat keras tidak tahu cara melakukan pemfilteran fungsi tetap (yaitu, efisien) di seluruh petak peta. Ini berarti aplikasi yang mengelola ubin perangkat lunaknya sendiri harus menggunakan pemfilteran tekstur manual dalam kode shader (yang menjadi sangat mahal jika filter anisotropik berkualitas baik diinginkan) dan/atau membuang selokan penulisan memori di sekitar ubin yang berisi data dari petak peta tetangga sehingga pemfilteran perangkat keras fungsi tetap dapat terus memberikan bantuan.

Jika representasi petak peta alokasi permukaan bisa menjadi fitur kelas satu dalam sistem grafis, aplikasi dapat memberi tahu perangkat keras petak peta mana yang akan disediakan. Dengan cara ini, lebih sedikit memori GPU yang terbuang untuk menyimpan wilayah permukaan yang diketahui aplikasi tidak akan diakses, dan perangkat keras dapat memahami cara memfilter di seluruh ubin yang berdekatan, mengurangi beberapa rasa sakit yang dialami oleh pengembang yang melakukan pemilahan perangkat lunak sendiri.

Tetapi untuk memberikan solusi lengkap, sesuatu harus dilakukan untuk menangani fakta bahwa, terlepas dari apakah ubin dalam permukaan didukung, dimensi permukaan maksimum saat ini adalah 16384 - tidak di dekat 128K + yang sudah diinginkan aplikasi. Hanya mengharuskan perangkat keras untuk mendukung ukuran tekstur yang lebih besar adalah salah satu pendekatan, namun ada biaya dan/atau tradeoff yang signifikan untuk pergi ke rute ini. Jalur filter tekstur dan jalur penyajian Direct3D 11 sudah jenuh dalam hal presisi dalam mendukung tekstur 16K dengan persyaratan lain, seperti mendukung jangkauan viewport yang jatuh dari permukaan selama penyajian, atau mendukung tekstur yang membungkus tepi permukaan selama pemfilteran. Kemungkinannya adalah mendefinisikan tradeoff seperti ukuran tekstur meningkat melebihi 16K, fungsionalitas/presisi diberikan dengan cara tertentu. Namun, bahkan dengan konsesi ini, biaya perangkat keras tambahan mungkin diperlukan dalam hal kemampuan mengatasi di seluruh sistem perangkat keras untuk pergi ke ukuran tekstur yang lebih besar.

Salah satu masalah yang mulai berperan saat tekstur menjadi sangat besar adalah bahwa koordinat tekstur titik mengambang presisi tunggal (dan interpolator terkait untuk mendukung rasterisasi) kehabisan presisi untuk menentukan lokasi di permukaan secara akurat. Pemfilteran tekstur jittery akan mengakibatkan. Salah satu pilihan mahal adalah membutuhkan dukungan interpolator presisi ganda, meskipun itu bisa berlebihan mengingat alternatif yang wajar.

Nama alternatif untuk sumber daya ubin adalah "tekstur jarang." "Sparse" menyampaikan sifat ubin sumber daya serta mungkin alasan utama untuk memetakannya - bahwa tidak semuanya diharapkan untuk dipetakan sekaligus. Bahkan, aplikasi dapat dengan mudah menulis sumber daya petak di mana tidak ada data yang ditulis untuk semua wilayah +mips sumber daya, dengan sengaja. Jadi, konten itu sendiri bisa jarang, dan pemetaan konten dalam memori GPU pada waktu tertentu akan menjadi subset dari itu (bahkan lebih jarang).

Skenario lain yang dapat dilayani oleh sumber daya ubin adalah memungkinkan beberapa sumber daya dari dimensi/format yang berbeda untuk berbagi memori yang sama. Terkadang aplikasi memiliki sekumpulan sumber daya eksklusif yang diketahui tidak digunakan pada saat yang sama, atau sumber daya yang dibuat hanya untuk penggunaan yang sangat singkat dan kemudian dihancurkan, diikuti dengan pembuatan sumber daya lain. Bentuk umumitas yang dapat jatuh dari "sumber daya ubin" adalah bahwa dimungkinkan untuk memungkinkan pengguna untuk mengarahkan beberapa sumber daya yang berbeda pada memori yang sama (tumpang tindih). Dengan kata lain, pembuatan dan penghancuran "sumber daya" (yang menentukan dimensi/format dan sebagainya) dapat diurai dari manajemen memori yang mendasar sumber daya dari sudut pandang aplikasi.

Topik terkait

Sumber daya berjenjang