GPU에서 텍스처가 차지하는 메모리 양은 얼마입니까?


9

디스크의 큰 png는 몇 메가 바이트를 차지할 수 있지만 GPU에는 동일한 png가 압축되지 않은 형식으로 저장되어 훨씬 더 많은 공간을 차지한다고 생각합니다. 이것이 사실입니까? 사실이라면 얼마나 많은 공간이 있습니까?

답변:


16

JPG 및 PNG 파일은 거의 항상 디스크보다 작습니다. 원시 RGB 데이터를 획득하려면 즉시 압축을 풀어야하므로로드에 더 많은 처리 성능과 더 많은 RAM이 필요합니다. 따라서 많은 현대식 엔진은 메모리와 동일한 형식을 디스크에 저장하도록 선택하여 텍스처의 메모리 요구 사항과 크기는 동일하지만 PNG 또는 JPG보다 큰 파일을 생성합니다. RGB / RGBA 및 S3TC / DXTn / BCn은 처리없이 메모리로 직접 읽어 오기 때문에 가장 널리 사용되는 형식입니다 (DXT 텍스처는 미리 압축되어 있음).

따라서 서로 다른 일반적인 텍스처 형식의 크기는 다음과 같습니다.

  • L (휘도, 예 : 그레이 스케일) : 너비 * 높이 * 1 바이트.
  • LA (휘도 및 알파, 글꼴에 공통) : 너비 * 높이 * 2 바이트.
  • RGB (컬러, 알파 없음) : 너비 * 높이 * 3 바이트
  • RGBA (알파 색상) : 너비 * 높이 * 4 바이트.
  • DXT1 / BC1 (컬러, 이진 알파) : (폭 * 높이 * 4 바이트) / 8 (8 : 1 압축 비율).
  • DXT3 / BC2 (컬러, 샤프 알파) / DXT5 / BC3 (컬러, 그라디언트 알파) : (폭 * 높이 * 4 바이트) / 4 (4 : 1 압축 비율).

밉맵이 있는 이미지를 사용하는 경우 텍스처에 4/3의 메모리가 필요합니다. 또한, 텍스처 폭과 높이는 오래되거나 성능이 떨어지는 하드웨어에서, 그리고 매우 제한된 하드웨어에서는 사각형의 힘을 가지도록 내부적으로 반올림 될 수 있습니다.

DXT에 대한 자세한 정보 : 손실 압축입니다. 즉, 텍스처를 압축 할 때 일부 컬러 데이터가 손실됩니다. 이것은 텍스처에 부정적인 영향을 미치며 날카로운 경계선을 왜곡하고 그라디언트에 "블록"을 만듭니다. 그러나 이점은 단점보다 훨씬 낫습니다 (DXT에서 심하게 나빠 보이는 텍스처가있는 경우 압축되지 않은 상태로 유지하십시오. 다른 것들은 크기 손실을 보충합니다). 또한 픽셀은 고정 크기 블록으로 압축되므로 텍스처 너비와 높이는 4의 배수 여야합니다.


디스크의 텍스처 형식은 압축률이 높은 형식 일 수 있으므로 메모리 형식을 직접 직렬화하는 디스크 형식을 제외하고 VRAM에서와 동일한 디스크 공간을 차지하지 않습니다.

물론 언리얼 엔진, 소스 등으로 제작 된 게임에 사용 된 에셋을 확인할 수 있습니다. 요즘에는 리소스를 압축하지 않은 디스크 공간이 충분하기 때문에 일반적으로 디스크에 압축되지 않습니다. 저장된 공간은 각로드에서 파일을 압축 해제하는 데 필요한 추가 RAM 및 CPU 시간을 보충하지 않습니다.
r2d2rigo

1
엔진마다 다릅니다. 더 큰 엔진, 특히 콘솔에서 작동하는 많은 엔진은 메모리 형식과 동일하거나 가까운 디스크 형식을 사용합니다. 그러나 PNG 또는 JPEG 자산이 포함 된 PC 전용 게임을 쉽게 찾을 수 있습니다. 어쨌든 시간을 지배 할 부하를 위해 디스크로 가야한다면. 또한 Mike는 디스크 형식으로 PNG 및 JPEG를 구체적으로 언급합니다.

RGB 형식은 일반적으로 GPU에 실제로 존재하지 않는다는 점을 제외하고는 대부분 정확합니다. 참조 : opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads
Maximus Minimus

9

분명히 : 형식에 따라 다릅니다.

256 x 256 픽셀 정사각형 텍스처를 봅시다. ColorXNA에서 알파 채널을 사용하여 압축되지 않은 32 비트 인 경우 256KB ( 256*256*4바이트) 가 걸립니다 .

16 비트 형식 (예 :)Bgr565 은 분명히 128KB의 절반 입니다.

그런 다음 압축 형식으로 전환하십시오. XNA에는 DXT1, DXT3 및 DXT5 ( S3 압축 이라고도 함 )가 있습니다. 이것은 손실 압축 형식입니다. 또한 블록 기반 형식입니다. 즉 , 픽셀이있는 블록을 알고 있기 때문에 샘플링 할 수 있습니다 . 더 적은 대역폭을 사용하기 때문에 더 빠릅니다.

DXT1의 압축 비율은 8 : 1이고 DXT3 및 DXT5의 경우 4 : 1입니다.

따라서 256x256의 DXT1 이미지는 32KB 입니다. 그리고 DXT3 또는 DXT5는 64KB 입니다.

그리고 밉맵이 있습니다. 이 기능을 사용하면 이전 크기의 절반 크기로 그래픽 메모리에 일련의 이미지가 생성됩니다. 256x256 이미지의 경우 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1입니다. 밉 매핑이 적용된 텍스처 는 원본 크기의 약 133 % 입니다.


4

대부분의 GPU는 매우 구체적인 압축 형식 만 읽을 수 있습니다. 예. BC *, DXT *는 png와 같은 형식이 아닙니다. 예, .png가 디스크보다 비디오 메모리에서 더 많은 공간을 차지한다는 것은 사실입니다.

텍스처는 비디오 메모리와 시스템 메모리 모두에 압축 또는 비 압축으로 저장 될 수 있습니다.

비 압축 텍스처의 경우 일반적으로 시스템 메모리의 비 압축 형식과 동일한 크기의 비디오 메모리 공간이 필요합니다.

DXT1 압축 텍스처 용. GPU는 텍스처에 4x4 타일 당 8 바이트를 저장합니다. 압축되지 않은 데이터 (RGB 채널당 8 비트)는 일반적으로 4x4x3 = 48 바이트이므로 압축 비율은 6 : 1입니다. DXT3 / DXT5 압축 텍스처의 경우 GPU는 텍스처의 각 4x4 타일 당 16 바이트를 저장합니다. 3 : 1의 압축 비율이 약간 낮습니다.

압축되지 않은 텍스처와 압축 된 텍스처 모두에 대한 몇 가지주의 사항이 있습니다.

  • 대부분의 메모리는 고정 크기의 페이지 (GPU에 따라 크기가 다름)에 할당됩니다. 예. 4KB이며 종종 하위 할당되지 않고 다른 GPU 데이터와 공유되지 않습니다. 즉. 텍스처 풋 프린트가 페이지 크기보다 작은 경우 vid mem의 풋 프린트는 여전히 페이지 크기입니다.

  • 일부 gpus에는 매우 특정한 정렬 요구 사항이 있습니다. 과거 일부 GPU에서는 텍스처 크기가 2의 제곱이어야한다는 요구 사항이있었습니다. 텍스처에서 샘플링 할 때 액세스 지역성을 개선하기 위해 종종 스위블 표현을 지원해야했습니다 (Morton Ordering : http://en.wikipedia.org/wiki/Z-order_(curve ) 참조). 즉, 이러한 요구 사항을 유지하기 위해 홀수 크기의 텍스처가 패딩됩니다 (일반적으로이 패딩은 드라이버가 처리 함). 현대 gpus에서 morton-order가 반드시 사용되는 것은 아니지만 gpu의 특정 요구 사항을 지원하기 위해 여전히 팽만감이있을 수 있습니다.

  • 텍스쳐의 여러 표현은 메모리에 언제라도, 특히 버리기 잠금을 사용하는 경우 메모리에 존재할 수 있습니다. GPU에서 더 이상 표현을 사용하지 않을 때까지 메모리 사용량을 증가시킬 수 있습니다 (일반적으로 CPU 렌더링의 몇 프레임 뒤에 있음).

  • 밉 매핑을 활성화하면 추가 밉은 평균적으로 기본 밉 레벨의 약 3 분의 1을 소비합니다. 위의 경고에 기반한 YMMV.


0

AFAIK 이미지 너비 * 높이 * BPP이며 PNG, JPG 또는 BMP 인 경우 독립적입니다. DDS 또는 기타 압축 형식이 어떻게 배치되는지 모르겠습니다.

밉 매핑은 비디오 메모리에 대한 필요성을 증가시킵니다.

이 주제에 대한 나의 지식은 약간 구식 일 수 있습니다. 얼마 전에 3D를 포기했습니다.


2
이미지는 또한 한 줄의 끝과 다음 줄의 픽셀 사이의 바이트 수인 피치 (또는 보폭)를 갖습니다. 아무도 내가 잘못 생각할 수 있도록 이것을 언급하지 않았습니다.
CiscoIPPhone

1
일반적으로 "피치"는 바이트 단위의 스캔 라인 길이 (자유형 및 SDL에서와 같음)를 나타내며 "스트라이드"는 픽셀 또는 스캔 라인 일 수있는 요소 사이의 간격을 나타냅니다 (OpenGL 및 Python의 세 번째 슬라이스 인수에서와 같이). 이미지 처리에는 두 값이 모두 필요하지만 "보통"pitch = width * bytes_per_pixel 및 stride = 0입니다.이 용어는 느슨하게 사용되며 혼동되기 때문에 선택한 라이브러리에 대한 API 문서를 확인하는 것이 가장 좋습니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.