Bagikan melalui

Kebutuhan akan sumber daya streaming

Sumber daya streaming diperlukan sehingga memori GPU tidak membuang-buang penyimpanan wilayah permukaan yang tidak akan diakses, dan untuk memberi tahu perangkat keras cara memfilter di seluruh petak peta yang berdekatan.

Sumber daya streaming atau tekstur jarang

Sumber daya streaming (disebut sumber daya ubin di Direct3D 11), adalah sumber daya logis besar yang menggunakan sejumlah kecil memori fisik.

Nama lain untuk sumber daya streaming adalah tekstur jarang. "Sparse" menyampaikan sifat sumber daya yang ubin serta mungkin alasan utama untuk memetakannya - bahwa tidak semuanya diharapkan untuk dipetakan sekaligus. Bahkan, aplikasi dapat dengan sengaja menulis sumber daya streaming 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 unit pemrosesan grafis (GPU) pada waktu tertentu akan menjadi subset dari itu (bahkan lebih jarang).

Tanpa ubin, alokasi memori dikelola pada granularitas sub sumber daya

Dalam sistem grafis (yaitu, sistem operasi, driver tampilan, dan perangkat keras grafis) tanpa dukungan sumber daya streaming, sistem grafis mengelola semua alokasi memori Direct3D pada granularitas subresource.

Untuk buffer, seluruh buffer adalah sub-sumber daya.

Untuk Tekstur, (misalnya, Texture2D), setiap tingkat mip adalah sub-sumber daya; untuk array tekstur, (misalnya, Texture2DArray) setiap tingkat mip pada ikatan array tertentu adalah sub-sumber daya. Sistem grafis hanya mengekspos kemampuan untuk mengelola pemetaan alokasi pada granularitas sub sumber daya ini. Dalam konteks sumber daya streaming, "pemetaan" mengacu pada membuat data terlihat oleh GPU.

Tanpa pemetaan, tidak dapat mengakses hanya sebagian kecil rantai mipmap

Misalkan aplikasi tahu bahwa operasi penyajian tertentu hanya perlu mengakses sebagian kecil rantai mipmap gambar (bahkan mungkin bukan area penuh dari mipmap tertentu). Idealnya, aplikasi 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 streaming, 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 yang dipetakan sebelum perintah penyajian yang mereferensikan bagian mana pun dari memori dijalankan. Ini hanyalah satu masalah yang membuat penggunaan alokasi memori besar sulit di Direct3D tanpa dukungan sumber daya streaming.

Halaman perangkat lunak untuk memecah permukaan menjadi petak peta yang lebih kecil

Penomoran perangkat lunak dapat digunakan untuk memecah permukaan menjadi ubin yang cukup kecil untuk ditangani perangkat keras.

Direct3D mendukung permukaan Texture2D dengan hingga 16384 piksel di sisi tertentu. Gambar yang lebarnya 16384 dengan tinggi 16384 dan 4 byte per piksel akan mengonsumsi memori video 1GB (dan menambahkan mipmap akan menggandakan jumlah tersebut). Dalam praktiknya, semua 1GB jarang perlu direferensikan 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 halaman perangkat lunak.

Kelemahan signifikan dari pendekatan tersebut berasal dari perangkat keras yang tidak mengetahui apa pun tentang penomoran halaman yang sedang berlangsung: Ketika bagian dari gambar perlu ditampilkan pada layar yang melapisi petak peta, perangkat keras tidak tahu cara melakukan pemfilteran fungsi tetap (yaitu, efisien) di seluruh petak peta. Ini berarti aplikasi yang mengelola petak peta 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 petak peta yang berisi data dari ubin tetangga sehingga pemfilteran perangkat keras fungsi tetap dapat terus memberikan beberapa bantuan.

Membuat representasi ubin dari alokasi permukaan menjadi fitur kelas satu

Jika representasi ubin alokasi permukaan adalah fitur kelas satu dalam sistem grafis, aplikasi dapat memberi tahu perangkat keras petak 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, meringankan beberapa rasa sakit yang dialami oleh pengembang yang melakukan ubin 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 sudah jenuh dalam hal presisi dalam mendukung tekstur 16K dengan persyaratan lain, seperti mendukung tingkat viewport yang jatuh dari permukaan selama penyajian, atau mendukung pembungkusan tekstur dari tepi permukaan selama pemfilteran. Kemungkinannya adalah mendefinisikan tradeoff seperti ukuran tekstur meningkat di luar 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.

Masalah dengan tekstur besar: presisi untuk lokasi di permukaan

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

Mengaktifkan beberapa sumber daya dari dimensi yang berbeda untuk berbagi memori

Skenario lain yang dapat dilayani oleh sumber daya streaming adalah memungkinkan beberapa sumber daya dari dimensi/format yang berbeda untuk berbagi memori yang sama. Terkadang aplikasi memiliki serangkaian 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 kegeneralan yang dapat jatuh dari "sumber daya streaming" 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 dipisahkan dari manajemen memori yang mendasar sumber daya dari sudut pandang aplikasi.

Sumber daya streaming