Berapa banyak memori yang terkandung pada GPU?


9

Sebuah png besar pada disk mungkin hanya memakan beberapa megabyte tapi saya membayangkan bahwa pada GPU png yang sama disimpan dalam format yang tidak terkompresi yang membutuhkan lebih banyak ruang. Apakah ini benar? Jika benar, berapa ruang?

Jawaban:


16

File JPG dan PNG hampir selalu berukuran lebih kecil di dalam disk daripada di memori; mereka perlu didekompresi saat terbang untuk mendapatkan data RGB mentah, sehingga membutuhkan lebih banyak daya pemrosesan untuk memuat dan lebih banyak RAM setelahnya. Begitu banyak mesin modern memilih untuk menyimpan format yang sama pada disk seperti yang mereka lakukan dalam memori, mengarah ke file yang ukurannya sama dengan persyaratan memori tekstur (tetapi juga lebih besar dari PNG atau JPG). RGB / RGBA dan S3TC / DXTn / BCn adalah format yang paling banyak digunakan, karena mereka dibaca langsung ke memori tanpa pemrosesan apa pun (tekstur DXT dikompresi).

Jadi, ini adalah ukuran untuk berbagai format tekstur umum:

  • L (luminance, mis: skala abu-abu): lebar * tinggi * 1 byte.
  • LA (luminance dan alpha, umum untuk font): lebar * tinggi * 2 byte.
  • RGB (warna, tanpa alfa): lebar * tinggi * 3 byte.
  • RGBA (warna dengan alfa): lebar * tinggi * 4 byte.
  • DXT1 / BC1 (warna, alpha biner): (lebar * tinggi * 4 byte) / 8 (rasio kompresi 8: 1).
  • DXT3 / BC2 (warna, alpha tajam) / DXT5 / BC3 (warna, alpha gradien): (lebar * tinggi * 4 byte) / 4 (rasio kompresi 4: 1).

Jika Anda menggunakan gambar dengan mipmaps , teksturnya akan membutuhkan memori 4/3 lebih banyak. Selain itu, lebar dan tinggi tekstur dapat dibulatkan secara internal untuk menjadi kekuatan dua pada perangkat keras lama atau kurang mampu, dan pada beberapa perangkat keras yang sangat terbatas, juga dipaksa menjadi persegi.

Info lebih lanjut tentang DXT: ini adalah kompresi lossy; ini berarti, beberapa data warna hilang saat mengompresi tekstur. Ini memiliki dampak negatif pada tekstur Anda, mendistorsi batas tajam dan membuat "blok" pada gradien; tetapi manfaatnya jauh lebih baik daripada kerugiannya (jika Anda memiliki tekstur yang terlihat sangat buruk di DXT, biarkan saja itu tidak terkompresi; yang lain akan menggantikan kehilangan ukuran). Juga, karena piksel dikompresi oleh blok ukuran tetap, lebar dan tinggi tekstur harus kelipatan empat.


Ini benar kecuali untuk kalimat pertama Anda - format tekstur pada disk dapat berupa format yang sangat terkompresi, dan karenanya tidak mengambil ruang yang sama pada disk seperti pada VRAM kecuali untuk format disk yang merupakan serialisasi langsung dari format memori.

Tentu saja bisa, tetapi periksa aset yang digunakan dalam gim yang dibangun dengan Unreal Engine, Source, dll. Biasanya tidak dikompres pada disk, karena saat ini ada lebih dari cukup ruang disk untuk membuat sumber daya tidak terkompresi; dan ruang yang dihemat tidak menggantikan RAM dan waktu CPU tambahan yang diperlukan untuk mendekompres file pada setiap beban.
r2d2rigo

1
Saya pikir Anda akan menemukan bahwa bervariasi dari mesin ke mesin. Banyak dari mesin yang lebih besar - terutama yang bekerja pada konsol - akan menggunakan format disk yang identik atau dekat dengan format memori. Tetapi cukup mudah untuk menemukan game-game khusus PC yang dikirimkan dengan aset PNG atau JPEG. Jika Anda harus pergi ke disk untuk memuat yang akan mendominasi waktu Anda. Plus, Mike secara khusus menyebutkan PNG dan JPEG sebagai format disk.

Kebanyakan benar kecuali bahwa format RGB biasanya tidak benar-benar ada pada GPU; lihat: opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads
Maximus Minimus

9

Jelas: Itu tergantung pada format.

Mari kita ambil tekstur persegi 256 x 256 piksel. Jika tidak terkompresi 32-bit dengan saluran alpha ( Colordalam XNA) maka dibutuhkan 256KB ( 256*256*4byte).

Format 16-bit (mis . :)Bgr565 jelas akan menjadi setengah ukuran - 128KB .

Kemudian Anda masuk ke format terkompresi. Di XNA Anda memiliki DXT1, DXT3 dan DXT5 (juga dikenal sebagai S3 Compression ). Ini adalah format kompresi lossy. Ini juga merupakan format berbasis blok - yang berarti Anda dapat mengambil sampel darinya (karena Anda tahu di mana blok sebuah piksel berada). Ini juga lebih cepat, karena Anda menggunakan lebih sedikit bandwidth.

Rasio kompresi DXT1 adalah 8: 1 dan untuk DXT3 dan DXT5 adalah 4: 1.

Jadi gambar DXT1 dari 256x256 adalah 32KB . Dan DXT3 atau DXT5 adalah 64KB .

Dan kemudian ada pemetaan . Jika ini diaktifkan, ini menciptakan serangkaian gambar dalam memori grafis masing-masing setengah dari ukuran sebelumnya. Jadi untuk gambar 256x256 kami: 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. Tekstur dengan pemetaan pemetaan adalah sekitar 133% ukuran aslinya.


4

Kebanyakan GPU hanya dapat membaca format kompresi yang sangat spesifik. misalnya. BC *, DXT *, bukan format seperti png. Jadi ya, memang benar sebagian besar bahwa .png akan mengambil lebih banyak ruang dalam memori video daripada pada disk.

Tekstur dapat disimpan terkompresi atau tidak terkompresi dalam memori video dan memori sistem.

Untuk tekstur yang tidak terkompresi, aturan umum adalah bahwa ia akan mengambil jumlah ruang yang sama dalam memori video seperti halnya dalam bentuk yang tidak terkompresi dalam memori sistem.

Untuk tekstur terkompresi DXT1. GPU menyimpan 8 byte untuk setiap ubin 4x4 dalam tekstur Anda. Data yang tidak terkompresi (pada 8-bit per saluran RGB) biasanya 4x4x3 = 48 byte, jadi itu adalah rasio kompresi 6: 1. Untuk tekstur terkompresi DXT3 / DXT5, GPU menyimpan 16 byte untuk setiap ubin 4x4 dalam tekstur Anda. Itu rasio kompresi yang sedikit lebih rendah dari 3: 1.

Ada beberapa peringatan dengan tekstur terkompresi dan terkompresi:

  • Sebagian besar memori dialokasikan dalam halaman (ukurannya bervariasi di antara GPU) dengan ukuran tetap. misalnya. 4KB dan sering yang tidak dialokasikan dan dibagikan dengan data GPU lainnya. Yaitu. jika tapak tekstur Anda lebih kecil dari ukuran halaman, tapak kaki dalam video seringkali masih berupa ukuran halaman.

  • Beberapa GPU memiliki persyaratan penyelarasan yang sangat spesifik. Di masa lalu, beberapa GPU memiliki persyaratan bahwa tekstur menjadi kekuatan 2 ukuran. Ini sering diperlukan untuk mendukung representasi swizzled (lihat Morton Ordering: http://en.wikipedia.org/wiki/Z-order_(curve )) untuk meningkatkan akses lokalitas ketika mengambil sampel dari tekstur. Ini berarti bahwa tekstur dengan ukuran ganjil akan diisi untuk menjaga persyaratan ini (biasanya bantalan ini ditangani oleh pengemudi). Meskipun perintah mortal tidak selalu digunakan dalam GPU modern, mungkin masih ada kembung untuk mendukung persyaratan spesifik GPU.

  • Beberapa representasi tekstur Anda mungkin ada di memori kapan saja, terutama jika Anda menggunakan kunci buangan padanya. Ini dapat mengasapi penggunaan memori Anda sampai representasi tidak lagi digunakan oleh GPU (yang biasanya beberapa frame di belakang rendering CPU)

  • Jika Anda mengaktifkan pemetaan pemetaan, rata-rata tambahan akan mengkonsumsi rata-rata sekitar sepertiga dari tingkat dasar basis. YMMV berdasarkan peringatan di atas.


0

AFAIK itu adalah lebar gambar * tinggi * BPP, tidak tergantung apakah itu PNG, JPG atau BMP. Saya tidak tahu bagaimana DDS atau format kompresi lainnya diletakkan.

Pemetaan-mip akan meningkatkan kebutuhan memori video.

Pengetahuan saya tentang topik ini mungkin sedikit ketinggalan zaman. Saya telah meninggalkan 3D beberapa waktu lalu.


2
Gambar juga memiliki nada (atau langkah), yang merupakan jumlah byte antara akhir satu baris dan awal baris piksel berikutnya. Tidak ada orang lain yang menyebutkan ini sehingga saya bisa salah.
CiscoIPPhone

1
Biasanya "pitch" mengacu pada panjang scanline dalam bytes (seperti pada Freetype dan SDL), dan "stride" mengacu pada spasi antar elemen, yang mungkin berupa pixel atau scanlines (seperti pada argumen slice OpenGL dan Python ke-3). Kedua nilai diperlukan untuk melakukan pemrosesan gambar, tetapi "biasanya" pitch = width * bytes_per_pixel dan stride = 0. Istilah ini sering digunakan secara longgar dan membingungkan, jadi yang terbaik adalah memeriksa dokumen API untuk perpustakaan pilihan Anda.
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.