타일형 리소스가 필요한 이유는 무엇인가요?
바둑판식 리소스가 필요하므로 GPU(그래픽 처리 장치) 메모리가 낭비되어 애플리케이션이 액세스하지 못할 것으로 알고 있는 표면 영역을 저장하고 하드웨어가 인접한 타일을 필터링하는 방법을 이해할 수 있습니다.
타일식 리소스가 지원되지 않는 그래픽 시스템(즉, 운영 체제, 디스플레이 드라이버 및 그래픽 하드웨어)에서 그래픽 시스템은 하위 리소스 세분성에서 모든 Direct3D 메모리 할당을 관리합니다. 버퍼의 경우 전체 버퍼는 하위 리소스입니다. 텍스처(예: Texture2D)의 경우 각 밉 수준은 하위 리소스입니다. 텍스처 배열(예: Texture2DArray)의 경우 지정된 배열 조각의 각 밉 수준은 하위 리소스입니다. 그래픽 시스템은 이러한 하위 리소스의 세분화 수준에서 메모리 할당 매핑을 관리할 수밖에 없습니다. 타일식 리소스의 컨텍스트에서 "매핑"은 GPU에 데이터를 표시하도록 하는 것을 의미합니다.
애플리케이션이 특정 렌더링 연산만 작은 부분의 이미지 Mipmap 사슬(일정한 Mipmap의 전체 영역이 아닐 수도 있음)에 접근해야 한다는 사실을 알고 있다고 가정하겠습니다. 이때 애플리케이션이 그래픽 시스템에게 이 요건에 대해 알릴 수 있다면 가장 이상적입니다. 그렇다면 그래픽 시스템이 지나치게 많은 메모리를 호출하지 않고 필요한 메모리만 GPU에 매핑할 수 있도록 제어할 것입니다. 실제로 타일식 리소스 지원이 없으면 그래픽 시스템은 하위 리소스 세분성(예: 액세스할 수 있는 전체 Mipmap 수준 범위)에서 GPU에 매핑해야 하는 메모리에 대해서만 알릴 수 있습니다. 둘 중 무엇이든 그래픽 시스템에서 메모리 수요에 대한 오류는 없기 때문에 메모리를 참조하는 렌더링 명령을 실행하려면 전체 하위 리소스를 매핑하는 데 지나치게 많은 GPU 메모리를 잠재적으로 사용할 수 밖에 없습니다. 이는 타일형 리소스 지원 없이 Direct3D에서 대용량 메모리 할당을 사용하기 어려운 한 가지 문제일 뿐입니다.
Direct3D 11은 지정된 쪽에서 최대 16384픽셀의 Texture2D 표면을 지원합니다. 픽셀 수가 16384x16384이고 픽셀당 4바이트인 이미지는 1GB의 비디오 메모리를 소모합니다(Mipmap이 추가되면 소모량은 2배로 늘어납니다). 실제로 단일 렌더링 연산에서 1GB를 모두 참조할 필요는 거의 없습니다.
일부 게임 개발자들은 최대 128k x 128k의 크기로 지형 표면을 모델링합니다. 기존 GPU에서 이렇게 모델링할 수 있는 방법은 하드웨어에서 처리할 수 있을 만큼 적은 수의 타일로 표면을 세분화하는 것입니다. 애플리케이션은 먼저 어떤 타일이 필요한지 판단한 후 타일을 소프트웨어 페이징 시스템인 GPU의 텍스처 캐시에 로드합니다. 이 방법의 중요한 단점은 진행 중인 페이징에 대해 아무것도 모르는 하드웨어에서 발생합니다. 타일을 가로지르는 이미지의 일부를 화면에 표시해야 하는 경우 하드웨어는 타일에서 고정 함수(즉, 효율적인) 필터링을 수행하는 방법을 모릅니다. 이 말은 자체 소프트웨어 타일링을 관리하는 애플리케이션이 셰이더 코드의 수동 텍스처 필터링에 의존할 수 밖에 없을 뿐만 아니라(양호한 품질의 이방성 필터를 원하는 경우 비용이 매우 고가임) 고정 함수 하드웨어 필터링이 계속해서 이용하려면 데이터가 포함된 타일 주위의 메모리 작성 여백(gutter)을 피할 수 없다는 것을 의미합니다.
표면 할당의 타일 표현이 그래픽 시스템의 첫 번째 클래스 기능이 될 수 있는 경우 애플리케이션은 하드웨어에 사용할 수 있는 타일을 알릴 수 있습니다. 그렇게 되면 애플리케이션이 접근할 필요 없는 표면 지역을 저장하는 데 GPU 메모리를 낭비하지 않을 뿐만 아니라 하드웨어가 인접 타일의 필터링 방법을 판단하기 때문에 직접 소프트웨어 타일링을 실행하는 개발자의 부담을 일부 줄여줄 수 있습니다.
하지만 종합적인 솔루션을 위해서는 표면 내 타일링 지원 여부에 상관없이 현재 최대 표면 크기가 16384이지만 애플리케이션에 필요한 128K+에는 미치지도 못한다는 사실에 대처할 수 있는 무언가가 필요합니다. 대용량의 텍스처 크기를 지원하는 하드웨어가 한 가지 방법이 될 수는 있지만 비용을 비롯해 이를 위해 상쇄되는 부분 또한 만만치 않습니다. Direct3D 11의 텍스처 필터 경로 및 렌더링 경로는 렌더링 중에 표면에서 떨어지는 뷰포트 익스텐트 지원 또는 필터링 중 표면 가장자리에서 텍스처 래핑 지원과 같은 다른 요구 사항으로 16K 텍스처를 지원하는 정밀도 측면에서 이미 포화 상태입니다. 한 가지 방법으로 텍스처 크기가 16K를 넘어 커질수록 기능이나 정밀도를 일정 부분 포기하는 방식의 상쇄 관계를 정의하는 것이 가능합니다. 이러한 상쇄 관계에도 불구하고 하드웨어 시스템에서 대용량의 텍스처 크기를 처리할 수 있는 기능과 관련하여 하드웨어 비용이 추가로 발생할 수도 있습니다.
텍스처의 용량이 커지면서 발생하는 한 가지 문제는 단정밀도 부동 소수점 텍스처 좌표(및 래스터화 지원을 위한 관련 보간)가 표면의 위치를 정확히 지정할 수 있는 정밀도가 부족하다는 데 있습니다. 그러면 텍스처 필터링도 어려워질 수 있습니다. 합리적 대안을 감안했을 때 지나칠 수도 있지만 한 가지 비용이 많이 드는 방법으로 배정밀도 보간 지원을 요구하는 것도 가능합니다.
타일식 리소스의 대체 이름은 "스파스 텍스처"입니다. "스파스"는 리소스의 타일식 특성과 타일링의 주된 이유를 모두 전달합니다. 모든 리소스가 한 번에 매핑되는 것은 아닙니다. 실제로 애플리케이션은 의도적으로 리소스의 모든 지역+mips에 대해 데이터를 작성하지 않는 타일형 리소스를 작성할 수 있습니다. 따라서 콘텐츠 자체는 스파스일 수 있으며 지정된 시간에 GPU 메모리의 콘텐츠 매핑은 해당 하위 집합(더 스파스)이 될 수 있습니다.
타일식 리소스에서 사용할 수 있는 또 다른 시나리오는 서로 다른 차원/형식의 여러 리소스가 동일한 메모리를 공유할 수 있도록 하는 것입니다. 간혹 애플리케이션은 동시에 사용하지 않는 것으로 알려진 리소스 집합을 독점하거나, 혹은 잠시 사용한 후 제거한 다음 다른 리소스를 생성할 목적으로 생성되는 리소스를 가지고 있습니다. "타일형 리소스"에서 벗어날 수 있는 일반성의 한 형태는 사용자가 동일한(겹치는) 메모리에서 여러 다른 리소스를 가리킬 수 있다는 것입니다. 다시 말해서 크기.형식 등을 정의하는 "리소스"의 생성 및 제거가 애플리케이션의 관점에서 리소스를 뒷받침하는 메모리 관리와 분리될 수 있습니다.
관련 항목