Kebutuhan akan sumber daya streaming

Sumber daya streaming diperlukan agar memori GPU tidak terbuang menyimpan wilayah permukaan yang tidak akan diakses, dan untuk memberi tahu perangkat keras cara memfilter di ubin 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 yang jarang. "Jarang" menyampaikan sifat ubin sumber daya serta mungkin alasan utama untuk ubin mereka - bahwa tidak semua dari mereka diharapkan untuk dipetakan sekaligus. Bahkan, sebuah aplikasi dapat dibayangkan 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 graphics processing unit (GPU) pada waktu tertentu akan menjadi subset dari itu (bahkan lebih jarang).

Tanpa ubin, alokasi memori dikelola pada granularitas subresource

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

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

Tanpa ubin, tidak dapat mengakses hanya sebagian kecil dari rantai mipmap

Misalkan aplikasi tahu bahwa operasi rendering tertentu hanya perlu mengakses sebagian kecil dari rantai mipmap gambar (bahkan mungkin bukan 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 dibutuhkan dipetakan pada GPU tanpa paging di terlalu banyak memori.

Pada kenyataannya, tanpa dukungan sumber daya streaming, sistem grafis hanya dapat diinformasikan tentang memori yang perlu dipetakan pada GPU pada granularitas subresource (misalnya, berbagai tingkat mipmap penuh yang dapat diakses). Tidak ada permintaan kesalahan dalam sistem grafis baik, sehingga berpotensi banyak kelebihan memori GPU harus digunakan untuk membuat subresources penuh dipetakan sebelum perintah rendering yang referensi setiap bagian dari memori dijalankan. Ini hanyalah satu masalah yang membuat penggunaan alokasi memori besar sulit di Direct3D tanpa dukungan sumber daya streaming.

Perangkat lunak paging untuk memecah permukaan menjadi ubin yang lebih kecil

Perangkat lunak paging dapat digunakan untuk memecah permukaan menjadi ubin yang cukup kecil untuk ditangani oleh 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 mengkonsumsi memori video 1GB (dan menambahkan mipmap akan menggandakan jumlah itu). Dalam praktiknya, semua 1GB jarang perlu dirujuk dalam satu operasi rendering.

Beberapa pengembang game memodelkan permukaan medan sebesar 128K kali 128K. Cara mereka mendapatkan ini untuk bekerja pada GPU yang ada adalah untuk memecah permukaan menjadi ubin yang cukup kecil untuk hardware untuk menangani. Aplikasi harus mencari tahu ubin mana yang mungkin diperlukan dan memuatnya ke dalam cache tekstur pada GPU - sistem paging perangkat lunak.

Kelemahan yang signifikan dari pendekatan itu berasal dari perangkat keras yang tidak tahu apa-apa tentang paging yang sedang terjadi: Ketika bagian dari gambar perlu ditampilkan pada layar yang mengangkangi ubin, perangkat keras tidak tahu bagaimana melakukan fungsi tetap (yaitu, efisien) penyaringan di ubin. Ini berarti aplikasi yang mengelola ubin perangkat lunaknya sendiri harus menggunakan penyaringan tekstur manual dalam kode shader (yang menjadi sangat mahal jika filter anisotropik berkualitas baik diinginkan) dan / atau limbah memori yang menulis selokan di sekitar ubin yang berisi data dari ubin tetangga sehingga penyaringan perangkat keras fungsi tetap dapat terus memberikan beberapa bantuan.

Membuat representasi ubin dari alokasi permukaan fitur kelas satu

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

Tetapi untuk memberikan solusi lengkap, sesuatu harus dilakukan untuk menghadapi kenyataan bahwa, terlepas dari apakah ubin dalam permukaan didukung, dimensi permukaan maksimum saat ini 16384 - tidak ada di dekat 128K + yang sudah diinginkan aplikasi. Hanya membutuhkan perangkat keras untuk mendukung ukuran tekstur yang lebih besar adalah salah satu pendekatan, namun ada biaya dan / atau tradeoff yang signifikan untuk pergi rute ini.

Jalur filter tekstur dan jalur rendering Direct3D sudah jenuh dalam hal presisi dalam mendukung tekstur 16K dengan persyaratan lain, seperti mendukung luas viewport yang jatuh dari permukaan selama rendering, atau mendukung tekstur yang membungkus tepi permukaan selama penyaringan. Kemungkinannya adalah untuk menentukan tradeoff sedemikian rupa sehingga ketika ukuran tekstur meningkat di luar 16K, fungsionalitas / presisi menyerah dalam beberapa cara. Bahkan dengan konsesi ini, biaya perangkat keras tambahan mungkin diperlukan dalam hal kemampuan pengalamatan di seluruh sistem perangkat keras untuk mencapai ukuran tekstur yang lebih besar.

Masalah dengan tekstur besar: presisi untuk lokasi di permukaan

Salah satu masalah yang ikut bermain sebagai tekstur menjadi sangat besar adalah bahwa koordinat tekstur floating point presisi tunggal (dan interpolator terkait untuk mendukung rasterisasi) kehabisan presisi untuk menentukan lokasi di permukaan secara akurat. Penyaringan tekstur yang gelisah akan terjadi. Salah satu pilihan mahal adalah membutuhkan dukungan interpolator presisi ganda, meskipun itu bisa berlebihan mengingat alternatif yang masuk akal.

Mengaktifkan beberapa sumber daya dengan dimensi 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 kumpulan 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 oleh pembuatan sumber daya lainnya. Suatu bentuk keumuman yang dapat jatuh dari "sumber daya streaming" adalah bahwa hal itu dimungkinkan untuk memungkinkan pengguna untuk mengarahkan beberapa sumber daya yang berbeda pada memori yang sama (tumpang tindih). Dengan kata lain, penciptaan dan penghancuran "sumber daya" (yang menentukan dimensi / format dan sebagainya) dapat dipisahkan dari pengelolaan memori yang mendasari sumber daya dari sudut pandang aplikasi.

Sumber daya streaming