Ile pamięci zajmuje GPU tekstura?


9

Duży png na dysku może zająć tylko kilka megabajtów, ale wyobrażam sobie, że na gpu ten sam png jest przechowywany w nieskompresowanym formacie, który zajmuje znacznie więcej miejsca. Czy to prawda? Jeśli to prawda, ile miejsca?

Odpowiedzi:


16

Pliki JPG i PNG prawie zawsze będą mniejsze na dysku niż w pamięci; muszą one zostać zdekompresowane w locie, aby uzyskać surowe dane RGB, co wymaga większej mocy przetwarzania do ładowania, a następnie więcej pamięci RAM. Tak wiele współczesnych silników decyduje się na zapisywanie tego samego formatu na dysku, co w pamięci, co prowadzi do plików o tym samym rozmiarze co wymagania pamięci tekstury (ale także większych niż PNG lub JPG). RGB / RGBA i S3TC / DXTn / BCn są najczęściej używanymi formatami, ponieważ są odczytywane bezpośrednio do pamięci bez żadnego przetwarzania (tekstury DXT są wstępnie kompresowane).

Oto rozmiary różnych popularnych formatów tekstur:

  • L (luminancja, np. Skala szarości): szerokość * wysokość * 1 bajt.
  • LA (luminancja i alfa, wspólne dla czcionek): szerokość * wysokość * 2 bajty.
  • RGB (kolor, bez alfa): szerokość * wysokość * 3 bajty.
  • RGBA (kolor z alfą): szerokość * wysokość * 4 bajty.
  • DXT1 / BC1 (kolorowy, binarny alfa): (szerokość * wysokość * 4 bajty) / 8 (współczynnik kompresji 8: 1).
  • DXT3 / BC2 (kolor, ostry alfa) / DXT5 / BC3 (kolor, gradient alfa): (szerokość * wysokość * 4 bajty) / 4 (współczynnik kompresji 4: 1).

Jeśli używasz obrazu z mipmapami , tekstura będzie wymagała 4/3 tyle pamięci. Dodatkowo szerokość i wysokość tekstury mogą być zaokrąglane wewnętrznie, aby uzyskać potęgę dwóch na starym lub mniej sprawnym sprzęcie, a na niektórych bardzo ograniczonym sprzęcie, również zmuszonym do bycia kwadratem.

Więcej informacji o DXT: kompresja stratna; oznacza to, że niektóre dane kolorów są tracone podczas kompresji tekstury. Ma to negatywny wpływ na teksturę, zniekształcając ostre krawędzie i tworząc „bloki” na gradientach; ale korzyści są znacznie lepsze niż wady (jeśli masz teksturę, która wygląda strasznie źle w DXT, po prostu nie kompresuj; inne zrekompensują utratę rozmiaru). Ponadto, ponieważ piksele są kompresowane przez bloki o stałym rozmiarze, szerokość i wysokość tekstury muszą być wielokrotnością czterech.


Jest to poprawne, z wyjątkiem pierwszego zdania - format tekstury na dysku może być dowolnym formatem o wysokim stopniu kompresji, więc nie zajmuje tyle samo miejsca na dysku, co w VRAM, z wyjątkiem formatów dysków, które są bezpośrednimi serializacjami formatów pamięci.

Oczywiście, że tak, ale sprawdź zasoby używane w grach zbudowanych z Unreal Engine, Source itp. Zazwyczaj nie są one kompresowane na dysku, ponieważ obecnie jest więcej niż wystarczająco miejsca na dysku, aby pozostawić zasoby nieskompresowane; zaoszczędzone miejsce nie rekompensuje dodatkowej pamięci RAM i czasu procesora potrzebnego do dekompresji plików przy każdym ładowaniu.
r2d2rigo,

1
Myślę, że przekonasz się, że różni się w zależności od silnika. Wiele większych silników - zwłaszcza tych, które działają na konsolach - używa formatu dysku identycznego lub zbliżonego do formatu pamięci. Ale dość łatwo jest znaleźć gry tylko na komputery PC z zasobami PNG lub JPEG. Jeśli musisz przejść na dysk, aby uzyskać obciążenie, które i tak zdominuje Twój czas. Ponadto Mike konkretnie wspomina PNG i JPEG jako format dysku.

W większości poprawne, z wyjątkiem tego, że formaty RGB zwykle nie istnieją w procesorach graficznych; patrz: opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads
Maximus Minimus

9

Oczywiście: To zależy od formatu.

Weźmy teksturę kwadratu 256 na 256 pikseli. Jeśli jest nieskompresowany 32-bit z kanałem alfa ( Colorw XNA), to zajmuje 256 KB ( 256*256*4bajty).

Formaty 16-bitowe (np . :)Bgr565 będą oczywiście o połowę mniejsze - 128 KB .

Następnie przejdziesz do skompresowanych formatów. W XNA masz DXT1, DXT3 i DXT5 (znany również jako kompresja S3 ). Jest to format kompresji stratnej. Jest to również format blokowy - co oznacza, że możesz z niego próbkować (ponieważ wiesz, w którym bloku znajduje się piksel). Jest także szybszy, ponieważ zużywasz mniejszą przepustowość.

Współczynnik kompresji DXT1 wynosi 8: 1, a dla DXT3 i DXT5 wynosi 4: 1.

Obraz 256 x 256 w formacie DXT1 ma rozmiar 32 KB . A DXT3 lub DXT5 to 64 KB .

A potem jest mipmapping . Jeśli ta opcja jest włączona, tworzy to serię obrazów w pamięci graficznej, o połowę mniejszą niż poprzednia. Tak więc dla naszego obrazu 256x256: 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. Tekstura z mipmapowaniem ma około 133% rozmiaru oryginału.


4

Większość procesorów graficznych może odczytywać tylko bardzo określony format kompresji. na przykład. BC *, DXT *, a nie formaty takie jak png. Tak, to prawda, w większości przypadków .png zajmie więcej miejsca w pamięci wideo niż na dysku.

Tekstury mogą być przechowywane skompresowane lub nieskompresowane zarówno w pamięci wideo, jak i pamięci systemowej.

W przypadku nieskompresowanych tekstur ogólną zasadą jest to, że zajmie tyle samo miejsca w pamięci wideo, co w nieskompresowanej formie w pamięci systemowej.

Dla tekstur skompresowanych DXT1. GPU przechowuje 8 bajtów dla każdego kafelka 4x4 w twojej teksturze. Nieskompresowane dane (przy 8 bitach na kanał RGB) zwykle wynosiłyby 4x4x3 = 48 bajtów, więc jest to współczynnik kompresji 6: 1. W przypadku tekstur skompresowanych DXT3 / DXT5 GPU przechowuje 16 bajtów dla każdego kafelka 4x4 w teksturze. To nieco niższy współczynnik kompresji 3: 1.

Istnieje kilka zastrzeżeń dotyczących zarówno nieskompresowanych, jak i skompresowanych tekstur:

  • Większość pamięci jest przydzielana na stronach (których rozmiar różni się w zależności od procesora graficznego) o stałym rozmiarze. na przykład. 4KB i często nie jest to subskrybowane i współdzielone z innymi danymi GPU. To znaczy. jeśli twój ślad tekstury jest mniejszy niż rozmiar strony, ślad w vid mem często będzie nadal miał rozmiar strony.

  • Niektóre gpus mają bardzo specyficzne wymagania dotyczące wyrównania. W przeszłości niektóre procesory graficzne wymagały, aby tekstury miały rozmiar 2. Było to często wymagane do obsługi zamienionej reprezentacji (patrz Morton Ordering: http://en.wikipedia.org/wiki/Z-order_(curve )), aby poprawić lokalizację dostępu podczas próbkowania z tekstury. Oznaczało to, że tekstury o nieparzystych rozmiarach byłyby wypełniane w celu zachowania tych wymagań (zazwyczaj to wypełnienie jest obsługiwane przez kierowcę). Chociaż porządek Morton niekoniecznie jest używany w nowoczesnym gpus, może nadal występować wzdęcie, aby spełnić specyficzne wymagania GPU.

  • W pamięci może istnieć wiele reprezentacji tekstury w dowolnym momencie, szczególnie jeśli używasz na nich blokad odrzucania. Może to spowodować nadmierne zużycie pamięci, dopóki GPU nie będzie już używać reprezentacji (która zwykle jest kilka klatek za renderowaniem procesora)

  • Jeśli włączysz mipmapowanie, dodatkowe mipsy zużyją średnio około jednej trzeciej podstawowego poziomu mipa. YMMV na podstawie powyższych zastrzeżeń.


0

AFAIK to szerokość obrazu * wysokość * BPP, niezależna, jeśli jest to PNG, JPG lub BMP. Nie wiem, jak są ułożone DDS lub inne formaty kompresowalne.

Mapowanie MIP zwiększy zapotrzebowanie na pamięć wideo do.

Moja wiedza w tym temacie może być nieco przestarzała. Jakiś czas temu porzuciłem 3D.


2
Obrazy mają również odstęp (lub krok), który jest liczbą bajtów między końcem jednej linii a początkiem następnej linii pikseli. Nikt inny nie wspomniał o tym, więc mogę się pomylić.
CiscoIPPhone

1
Zwykle „skok” odnosi się do długości linii skanowania w bajtach (jak w Freetype i SDL), a „krok” odnosi się do odstępu między elementami, które mogą być pikselami lub liniami skanowania (jak w argumencie OpenGL i argumentu trzeciego plasterka Pythona). Obie wartości są niezbędne do przetwarzania obrazu, ale „zwykle” pitch = szerokość * bytes_per_pixel i stride = 0. Terminy są często używane luźno i mylone, dlatego najlepiej sprawdzić dokumenty API dla wybranej biblioteki.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.