https://www.mrelusive.com/publications/papers/Software-Virtual-Textures.pdf
위 글을 번역한 것임. Virtual Texture 원리를 이해해보고자 작성해 둠
서론
Virtual Texture는 sparse representation을 제공해서, 렌더링 할 때 모든 텍스처 데이터가 존재할 필요 없이 텍스처 대부분이 두 번째 저장소에 매우 압축된 형태로 존재한다. Virtual Texture는 필요 메모리를 절약해 줄 뿐만 아니라, 그래픽 드라이버 뿐만 아니라 하드웨어 state 변경에 의한 퍼포먼스도 향상시키는데, 그 이유는 많은 Surface가 Surface 단위 텍스처 선택을 하지 않고 1개의 virtual texture를 공유해서 사용할 수 있기 때문이다. 여기에는 address translation, texture filtering, oversubscription, lod snapping, compression, caching, streaming에 대한 솔루션도 포함되어 있다.
소개
virtual texture는 unique 텍스처 데이터의 비용을 상당히 줄일 수 있다.
텍스처의 sparse representation은 메모리 상의 레이아웃을 나타내는데, 이것은 렌더링 할 때 데이터 전체를 필요로 하지 않는다. mip-map 된 텍스처에서, sparse-representation은 이미지상의 서로 다른 위치의 서로 다른 해상도를 사용할 수 있도록 한다. 이것은 모든 주어진 렌더링 된 장면에서는 데이터 전체가 존재하더라도 결국 데이터의 sparse 한 샘플링만을 사용할 것이기 때문이다. 이 sparsity를 이용해서 virtual texture를 사용하는 것은 physical texture page와 page table (=physical texture page로의 가상의 주소를 가리킨다) 이것은 virtual memory system과도 유사하다.
하지만 virtual memory와는 크게 두 가지에서 다르다 - 첫째, 수행을 stall 하지 않고도 약간 흐릿한 데이터로 fallback 할 수 있다. 보통의 virtual memory에서 요청한 데이터를 로드할 때 까지 시스템이 프로세스 수행을 멈춰야 한다. 둘째, 데이터의 손실 압축이 대부분의 사용처에 완전히 허용된다. 이 두 가지 차이가 virtual texture를 퍼포먼스 저하 없이 처리할 수 있도록 하고, 필요 메모리를 크게 줄일 수 있도록 한다.
Virtual Texture는 필요 메모리를 크게 줄일 뿐만 아니라, 지오메트리의 1 batch의 모든 표면이 그려질 수 있도록 한다. 서로 다른 surface라도 같은 virtual texture의 서로 다른 부분을 사용할 수 있고, surface 별 텍스처 선택을 할 필요가 없다. 만약 virtual texture가 공통되게 적용되어 있다면, 지오메트리는 보통 culling 세분화를 위해 여러 batch로 나눠질 뿐이다. 이것은 렌더링 퍼포먼스를 크게 향상시킬 수 있다 - culling을 향상시키고 그래픽 드라이버와 하드웨어에서의 state 변경을 줄여주기 때문이다. virtual texture는 텍셀 단위로 미리 계산된 라이트들을 직접 텍스처 데이터에 저장해서, 독자적으로 텍스처링 된 정적인 월드를 구성하는 것이 가능하고, 이것은 렌덜이 패스 갯수와 state 변경도 줄일 수 있다.
2. 이전 작업들
지형 렌더링에서는 매우 큰 텍스처 데이터 세트를 관리하기 위해, 지오메트리 레벨 오브 디테일(LOD)을 선택하거나 구성하는 동시에 텍스처 LOD를 adaptive하게 선택하는 다양한 접근 방식이 있다. 이러한 접근 방식 중 일부는 미리 계산된 지오메트리 LOD와 함께, 그 안에 텍스처 LOD가 포함된(baked in) 형태를 사용한다. 반면에 다른 방식들은 지오메트리 LOD를 동적으로 생성하면서, 그 과정에서 서로 다른 텍스처 LOD를 할당한다.
이러한 접근 방식들 중 어느 것도 프래그먼트 단위의 텍스처 주소 변환을 통한 Virtual texture를 구현하지는 않는다. 대신, 서로 다른 텍스처 좌표가 미리 계산된 지오메트리 버전들에 따라 제공되거나, 지오메트리가 실시간으로 생성되면서 새로운 텍스처 좌표가 할당된다.
클립맵(clip-map) 은 프래그먼트 단위의 텍스처 주소 변환을 사용하는 버추얼 텍스처를 위한 최초의 효과적인 기법 중 하나이다.
Clipmap
1. The Clipmap: A Virtual Mipmap
ChristopherC. Tanner, Christopher J. Migdal, Michael T. Jones
Proceedings of SIGGRAPH 98, pages 151-158, July 1998 Available Online:
http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Texturing/Clipmap.pdf
2. Clip-mapping on the GPU
Roger Crawfis, Eric Noble, Michael Ford, Frederic Kuck, Eric Wagner
The Ohio State University, OSU-CISRC-4/07-TR24, April 2007
ftp://ftp.cse.ohio-state.edu/pub/tech-report/2007/TR24.pdf
3. Hardware-Independent Clipmapping
Antonio Seoane, Javier Taibo, Luis Hernández
The 15th International Conference in Central Europe on Computer Graphics, Visualization and Computer Vision, 2007 (WSCG 2007)
http://wscg.zcu.cz/WSCG2007/Papers_2007/full/A89-full.pdf
클립맵은 1998년 Tanner 등[7]에 의해 소개되었으며, 밉맵 계층 구조와 유사한 이미지 스택으로 구성된다. 그러나 밉맵이 전체 텍스처를 점점 커지는 이미지로 덮는 반면, 클립맵은 고정된 크기의 레벨을 사용하여 텍스처 위의 하나의 중심 지점을 기준으로 점점 좁아지는 영역만을 덮는다.
하나의 중심 지점을 기준으로 관심 영역(region of interest)을 사용하는 방식은 텍스처 데이터를 지오메트리에 매핑하는 과정을 크게 단순화시키며, 렌더링 중 텍스처 주소 변환의 복잡도도 매우 낮다. 그러나 클립맵은 한 개의 관심 영역을 갖기 때문에 이러한 텍스처 관리 기법을 텍스처 데이터와 지오메트리 간에 자연스러운 공간적 연관성이 있는 환경, 예를 들어 대부분 평평하고 연속적인 지형과 같은 경우로 제한되게 된다.
최근의 버추얼 텍스처 시스템은 훨씬 더 유연하며, 현대 CPU에서 운영체제가 사용하는 가상 메모리 관리 방식을 모방한다
텍스처는 렌더링에 필요한 경우 자동으로 캐시되고 비디오 메모리로 로드되는 작은 페이지들로 나뉜다. 이러한 시스템은 페이지 테이블 또는 매핑 텍스처를 통해 실시간 프래그먼트 단위 텍스처 주소 변환을 수행한다. 지오메트리와 텍스처 페이지 간에 자연스러운 연관성이 항상 존재하는 것은 아니기 때문에, 이러한 버추얼 텍스처 시스템은 어떤 페이지가 메모리에 상주해야 하는지를 결정하기 위해 렌더링 파이프라인으로부터의 피드백이 필요하다. 이 논문은 특수한 그래픽 하드웨어 지원 없이, 소프트웨어만으로 이러한 종류의 버추얼 텍스처 시스템을 구현할 때 발생하는 여러 가지 도전 과제들에 대해 설명한다.
여기에 대한 더 자세한 내용들
Texture Tile Visibility Determination for Dynamic Texture Loading Michael E. Goss, Kei Yuasa EUROGRAPHICS/SIGGRAPH 1998 Workshop on Graphics Hardware, pp. 55-60, Lisbon Portugal, Aug./Sept. 1998
http://www.hpl.hp.com/research/mmsl/publications/3d/texturetilevisibility.pdf
Interactive Display Of Very Large Textures David Cline, Parris K. Egbert Proceedings of the conference on Visualization, pp. 343-350, October 1998
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.4571
A Perceptually-Based Texture Caching Algorithm for Hardware-Based Rendering Reynald Dumont, Fabio Pellacini, James A. Ferwerda Proceedings of the 12th Eurographics Workshop on Rendering Techniques, pp. 249-256, 2001
GLIFT와 같은 시스템은 그래픽 하드웨어 상에서 일반적인 가상 메모리 관리를 위한 소프트웨어 시스템도 존재한다. 이러한 시스템은 품질과 성능 간의 트레이드오프를 가능하게 하는 버추얼 텍스처의 특수한 속성을 자동으로 활용하지는 않는다. 그러나 GLIFT와 같은 시스템은 버추얼 텍스처 시스템을 구축하기 위한 기반으로 사용할 수 있다. 하지만 여기에서는 GLIFT와 같은 범용적인 하위 시스템을 사용하는 대신, 하드웨어에 직접 매핑되는 버추얼 텍스처 시스템에 초점을 맞추고 있다.
3. Software Virtual Texture로 렌더링하기
3.1 주소 변환 (Address Translation)
Virtual Texture 는 작은 페이지들로 나뉘며, 이 페이지들은 렌더링에서 필요해질 때 상주 Physical Page Pool에 로드된다. 이러한 작은 페이지들은 일반적으로 128 x 128 크기의 텍셀 정사각형 블록이며, Physical Page Pool은 이러한 텍셀 블록들로 논리적으로 분할된 완전히 상주하는 텍스처이다. (주 : 이 크기는 언리얼 엔진의 Tile Size 기본값이기도 함, 뒤에서 보겠지만 Tile Size보다 작은 mipmap은 사용되지 않는다)
Virtual Texture 는 매우 클 수 있으며(예를 들어 백만 개의 페이지), 비디오 메모리에 완전히 상주하는 경우는 없다. 반면, Physical Page Pool을 담고 있는 텍스처는 항상 완전히 상주하지만 훨씬 작으며, 일반적으로 4096 x 4096 텍셀(또는 1024개의 페이지) 정도의 크기만 된다.
가장 단순한 형태에서, 가상 주소를 물리 주소로 변환하는 과정은 현재 메모리에 상주한 텍스처 페이지들의 밉맵 계층 구조를 나타내는 쿼드 트리(quad-tree)를 따라가며, 원하는 디테일 수준(LOD)을 찾는 것과 동일하다.
쿼드 트리의 각 노드는, 가상 페이지 내의 가상 주소를 물리 페이지 내의 물리 주소로 변환하기 위한 스케일(scale)과 바이어스(bias)를 제공한다.
스케일은 가상 밉 레벨의 크기와 물리 텍스처의 크기 간의 비율이고, 바이어스는 물리 텍스처에서 물리 페이지의 오프셋에서 가상 밉 레벨에서 가상 페이지의 스케일된 오프셋 을 뺀 값이다.
쿼드 트리를 따라가며 주어진 가상 주소에서 원하는 LOD를 찾는 과정에서,
- 원하는 LOD에 해당하는 노드가 존재하면 그 노드의 스케일과 바이어스를 사용하고,
- 트리가 중간에 끝나버리는 경우에는 마지막 노드의 스케일과 바이어스를 사용해 주소 변환을 수행한다.
이러한 경우에는, 원하는 더 정밀한 밉 레벨의 텍스처 페이지가 물리 페이지 풀에 아직 존재하지 않기 때문에, 더 낮은 해상도의 밉 레벨 페이지로 폴백(fallback) 하게 된다.
아래 그림은 가상 주소를 물리 주소로 변환하는 과정과, 스케일 및 바이어스의 계산 방법을 보여준다.
페이지 경계를 고려한 스케일과 바이어스의 전체 계산 방법은 부록 A(Appendix A)에 나와 있다.
현재 메모리에 상주한 텍스처 페이지들만을 기반으로 한 쿼드 트리 자료 구조만 사용하는 방식은 메모리 페이지 테이블의 크기를 최소화할 수 있지만, 최악의 경우 더 세밀한 LOD에 각각 접근할 때마다 의존적인 읽기가 필요하기 때문에 접근 latency가 발생할 수 있다. 주소 변환은 쿼드 트리를 따라가는 것 말고도, 성능과 메모리 사용 간의 균형을 고려한 다양한 방식으로 구현할 수 있다.
Virtual 주소를 Physical 주소로 변환하는 가장 직관적인 방법 중 하나는, virtual page마다 하나의 텍셀을 가지는 밉맵 텍스처를 사용하여, 그 안에서 scale과 bias값을 조회하는 것이다. 사실상 이 밉맵 텍스처는, 모든 가상 텍스처 페이지에 대해 하나의 노드를 가지는 완전한 쿼드 트리 자료 구조를 저장하는 셈이며, 해당 페이지가 메모리에 상주해 있든 아니든 상관없이 포함된다.
이 페이지 테이블 텍스처에 대해 일반적인 조회(lookup)를 수행하면, 텍스처 하드웨어를 활용해, 주어진 가상 주소에서 원하는 LOD에 해당하는 가상 텍스처 페이지에 가장 가까운 밉 레벨의 가장 가까운 텍셀을 계산할 수 있다. 이 텍스처 조회는 페이지 테이블 텍스처와 가상 텍스처 간의 크기 차이를 보정하기 위해, 페이지 너비의 base-2 로그 값을 사용해 바이어스를 적용한다.
(주 : base-2 logarithm 이란, 어떤 숫지를 log2n 의 형태로 나타내는 것을 의미.
예를 들어, {log_2}16 = 4 인데,2^4 = 16 이기 때문)
이렇게 페이지 테이블 텍스처에서 얻은 스케일과 바이어스는 Virtual 주소를 physical 주소로 직접 매핑하는 데 사용될 수 있다. 만약 원하는 더 정밀한 mip 레벨의 페이지가 아직 physical page pool에 존재하지 않는 경우, 해당 텍스처의 텍셀은 더 낮은(덜 정밀한) mip 레벨의 페이지에 대한 스케일과 바이어스를 저장하고, 이를 사용해 폴백(fallback) 주소 변환을 수행하게 된다.
가상 텍스처와 물리 텍스처가 모두 정사각형인 경우, 두 축(S축과 T축)에 대해 하나의 스케일 값만 있으면 충분하다. 하지만, 가상 페이지를 임의의 물리 페이지에 매핑하려면, 두 개의 바이어스 값 —즉 S-바이어스(S-bias)와 T-바이어스(T-bias) —가 필요하다. 스케일과 바이어스는 충분히 큰 가상 텍스처(예: 경계(border)를 포함하여 1024 x 1024 페이지 이상)를 지원하기 위해, 최소 16비트 정밀도로 저장되어야 한다. 이는 곧, 스케일과 바이어스를 32비트 부동소수점(FP32) 형식으로는 저장할 수 있지만, 16비트 부동소수점(FP16) 형식으로는 저장할 수 없다는 것을 의미한다. 그 이유는 FP16의 가수부(mantissa)가 충분한 비트를 제공하지 못해, 큰 가상 텍스처에서 필요한 정밀도를 유지할 수 없기 때문이다.
가장 간단한 구현 방식은, 세 가지 값(ST-스케일, S-바이어스, T-바이어스) 을 4컴포넌트 32비트 부동소수점 텍스처(FP32x4)에 저장하는 것이다. 이러한 FP32x4 페이지 테이블 텍스처를 사용하는 버추얼 주소 → 물리 주소 변환은 프래그먼트 프로그램(fragment program) 내에서 매우 간단하게 구현할 수 있다. 구현은 텍스처 조회(texture lookup) 1회와 곱셈-덧셈(multiply-add) 연산 하나로 이루어지며, 그 자세한 내용은 부록 A.1(Appendix A.1)에 나와 있다.
안타깝게도, 적당히 큰 크기의 가상 텍스처를 사용할 경우 FP32x4 페이지 테이블 텍스처는 상당한 양의 메모리를 소비하게 된다. 예를 들어, 1024 x 1024 개의 가상 페이지를 가진 가상 텍스처의 경우, 해당 페이지 테이블 텍스처는 약 21.33MB의 메모리를 차지한다.
메모리 사용량을 줄이기 위해, 페이지 테이블을 두 개의 텍스처로 분리할 수 있다.
첫 번째 텍스처는 가상 페이지당 하나의 텍셀을 갖는 밉맵 텍스처로 구성되며, 이전에 설명한 것처럼 이 텍스처에 대한 일반적인 텍스처 조회를 통해, 주어진 가상 주소에서 원하는 LOD에 해당하는 가장 가까운 밉 레벨의 텍셀을 텍스처 하드웨어가 계산하도록 할 수 있다. 하지만 이번에는 스케일(과 바이어스를 저장하는 대신, 이 텍스처의 각 2바이트짜리 텍셀에는 해당 가상 페이지에 매핑될 물리 페이지의 (x, y) 좌표가 저장된다. (2byte : 0 ~ 65,535 가지의 정수 표현 가능) 이 텍스처의 텍셀은, 원하는 더 정밀한 밉 레벨의 물리 페이지가 아직 사용 가능하지 않은 경우, 더 낮은(덜 정밀한) 밉 레벨의 물리 페이지를 가리키게 된다. 즉, 시스템은 해당 가상 페이지에 대해 아직 세밀한 해상도의 데이터를 갖고 있지 않으면, 자동으로 대체 가능한 상위 밉 레벨의 페이지를 사용하여 렌더링한다.
두 번째 텍스처는 밉맵이 없는(non-mip-mapped) FP32x4 텍스처이며, 물리 페이지 하나당 하나의 텍셀을 가진다. 이 텍스처의 각 텍셀은, 해당 물리 페이지에 대해 가상 텍스처 좌표를 물리 텍스처 좌표로 매핑하기 위해 필요한 ST-스케일, S-바이어스, T-바이어스 값을 담고 있다.
이러한 메모리 최적화는 의존적인 텍스처 읽기(dependent texture read)로 인해 약간의 latency를 유발하지만, 가상 페이지당 하나의 텍셀에 부동소수점 스케일과 바이어스를 저장하는 방식에 비해 메모리를 약 8배 절약할 수 있다. 가상 페이지당 2바이트, 물리 페이지당 16바이트(FP32x4 텍셀 1개)를 사용하는 경우, 1024 x 1024 개의 가상 페이지를 갖는 가상 텍스처를 사용한다고 하면 해당 페이지 테이블 텍스처들은 약 2.66MB의 메모리만 소비한다.
일부 그래픽 하드웨어에서는 텍셀당 32비트 초과 데이터를 읽어오는 작업이 비용이 많이 들거나, 병렬로 처리할 수 있는 프래그먼트 수를 제한하는 경우가 있다. 하나의 FP32x4 매핑 텍스처를 사용하는 대신, 스케일과 바이어스를 각각 별도의 단일 컴포넌트 FP32 텍스처 세 개에 저장할 수 있다. 하나는 ST-스케일용, 하나는 S-바이어스용, 하나는 T-바이어스용이다. 세 개의 FP32x1 텍스처를 사용하여 스케일과 바이어스를 저장하는 프래그먼트 프로그램 구현은 부록 A.3에 나와 있다.
일부 플랫폼에서는 사용되는 텍스처 수에 의해 성능이 제한될 수 있다 - 따라서 세 개의 단일 컴포넌트 FP32 텍스처를 사용하는 방식이 최적의 성능을 보장하지 않을 수 있다.
바인딩해야 하는 텍스처 수를 줄이기 위해, 스케일과 바이어스를 16비트 고정소수점 포맷으로 저장할 수 있다. 이 경우, 하나의 단일 컴포넌트 텍스처에 ST-스케일을 저장하고, 두 개의 컴포넌트 텍스처에 S-바이어스와 T-바이어스를 저장한다.
아주 큰 Virtual Texture에 대해서도 Virtual에서 Physical로의 변환이 정확히 이루어질 수 있도록, 사용 가능한 모든 비트를 효과적으로 활용하는 데 주의가 필요하다. 두 개의 16비트 고정소수점 매핑 텍스처를 사용하는 구현 방법은 부록 A.4에 나와 있다. 이 방식을 사용할 경우, Virtual에서 Physical로의 변환은 단순히 texture lookups과 스케일 및 바이어스를 적용하는 곱셈-덧셈만으로 이루어지지 않는다. 16비트 고정소수점 값을 적절한 범위로 변환하기 위해 추가로 두 번의 곱셈과 한 번의 뺄셈 연산이 필요하다.
스케일과 바이어스를 텍스처에 저장하는 대신, Virtual에서 Physical로의 매핑은 Physical Page의 좌표와 밉 레벨을 기반으로 Fragment Program에서 계산할 수도 있다. 물리 페이지의 좌표와 밉 레벨은 하나의 밉맵 텍스처에 저장할 수 있으며, 이는 스케일과 바이어스를 가져오는 데 필요한 의존적인 texture read의 지연 시간을 피할 수 있다. 이 경우에도, 이 텍스처에 대한 regular lookup을 통해 텍스처 하드웨어를 사용하여 주어진 Virtual 주소에 대해 원하는 LOD에 해당하는 Virtual Texture 페이지와 일치하는 가장 가까운 mip 레벨의 텍셀을 계산할 수 있다. 이 텍스처에서 검색된 physical page의 좌표는 physical texture에서 physical page의 왼쪽 상단 모서리까지의 오프셋을 계산하는 데 사용된다. 완전한 physical 주소를 계산하기 위해서는, Virtual 페이지 내의 오프셋을 스케일링하고 그것을 physical page의 왼쪽 상단 모서리에 더해야 한다. 이 Virtual 페이지 내의 오프셋은 올바른 밉 레벨을 계산하기 위해서 필요한데, 이것은 먼저 Physical ㅍ이지의 밉 레벨 (Virtual Page 너비 / mip^2)의 페이지의 너비를 virtual 텍스처의 좌표와 곱하고, 그 fraction 부분으로 얻어진다. 이 Fraction은 physical 페이지 오프셋이 더해지기 전에 올바른 범위 안으로 스케일된다.
컴포넌트당 8bit RGBA인 페이지 테이블 텍스처를 사용할 때는, physical page 좌표는 첫번째 두 컴포넌트들에 저장될 수 있다. 나머지 컴포넌트들 중 하나에 밉 레벨일 저장하는 대신, 마지막 2개 컴포넌트의 16 bit는 physical page 의 mip level 내 페이지들의 너비를 저장하는 데 사용할 수 있다. 16 bit는 아주 넓은 - 10단계의 mip 레벨이 넘는 1024x1024 페이지짜리 Virtual Texture를 지원하기에 충분하다. A.5에 8bit짜리 RGBA 컴포넌트를 사용하는 예제 fragment program이 들어 있다. 8-bit component들은 fragment program에서 사용되기 전에 하드웨어에서 [0,1] 범위의 부동 소수점 범위로 변환된다. 하지만 불행히도 이 변환은 하드웨어에 따라 조금씩 다르다. 어떤 그래픽 하드웨어에서는 8-bit 컴포넌트가 255로 직접 나누어져 FP32로 변환된다. 다른 하드웨어에서는 8-bit 컴포넌트들이 먼저 FP16으로 변환된 다음, FP32로 변환된다. virtual에서 physical로의 변환 연산을 하는 Fragment program은 Physical Page 좌표와 Physical Page의 Mip level 너비를 다시 정수 값으로 변환할 때, 이런 하드웨어에 따른 텍스처 데이터의 변환 차이를 고려해야 한다.
RGBA 8-bit 텍스처를 사용하면, page table은 1024x1024 페이지를 사용할 때 5.33 MB 의 메모리를 사용한다.
메모리가 차지하는 공간을 줄이려면 page table를 5:6:5 RGB 텍스처에 저장할 수 있다. Physical page 좌표는 5-bit 컴포넌트에 저장되고, physical page의 mip level의 페이지 너비는 2-base logarithm 형태로 6-bit 컴포넌트에 저장된다. exp(2) 함수는 fragment program에서 (Physical 페이지의 mip 레벨에서)실제 페이지의 너비를 계산하는 데 사용된다. 5:6:5 값들은 fragment program에서 사용되기 전에 [0,1] 범위의 floating point 범위로 하드웨어에서 변환된다. 불행히도, 8-bit 변환처럼, 이 변환 또한 하드웨어마다 다르다. 일부 하드웨어에서는 5:6:5 값이 먼저 각 구성 요소당 8비트로 변환되며, 이 과정에서 상위 비트를 하위 비트로 복제한다. 예를 들어, 5비트 값의 경우 모든 비트를 8비트 값의 최상위 비트로 복사한 후, 가장 상위의 3비트를 8비트 값의 최하위 3비트에 복제한다.
어떤 하드웨어에서는 이렇게 얻어진 8비트 값들을 255로 나눈 후 FP16으로 변환하고, 이후 다시 FP32로 변환하는 과정을 거친다. 반면 다른 하드웨어에서는 8비트 값을 FP32로 직접 변환하기도 한다. 또 다른 하드웨어에서는 5:6:5 값을 8비트로 변환하지 않고, 비트 복제(bit replication)를 통해 직접 부동소수점(floating-point)으로 변환하기도 한다.
가상 텍스처 주소를 물리 주소로 변환하는 fragment program은 이러한 하드웨어 간의 차이를 모두 고려해야 한다. 상황을 더 복잡하게 만드는 점은, 일부 하드웨어에서는 exp2() 함수가 지수가 정확한 정수일 때조차도 단순한 근사치에 불과하다는 것이다. 예를 들어, exp2(10)이 정확히 1024가 아닐 수도 있다. 이 문제를 해결하기 위해, 지수에 아주 작은 값을 더하여 2^exponent가 항상 2^int(exponent)보다 크되, 2^int(exponent) + 1을 넘지 않도록 한다. 그 후 floor() 함수를 사용해 exp2() 함수의 결과로부터 정확한 2의 정수 거듭제곱 값을 얻는다. 5:6:5 RGB 포맷의 페이지 테이블을 사용하는 fragment program 구현 예시는 부록 A.6에 나와 있다.
가상 텍스처 주소를 물리 주소로 변환하는 여러 방식들의 성능은 플랫폼마다 다르게 나타닌다. 8비트 구성 요소로 이루어진 RGBA 페이지 테이블을 사용하는 구현은 대부분의 플랫폼에서 가장 빠른 방식 중 하나이다. 이 방식은 dependent texture read가 필요하지 않으며, 메모리 대역폭과 연산량 사이에서 적절한 균형을 이루기 때문이다.
하지만 여러 개의 큰 Virtual Texture가 동시에 활성화되어 있는 경우, 페이지 테이블의 크기가 급격히 증가하게 된다. 대안으로, 5:6:5 RGB 페이지 테이블은 메모리를 절반 정도만 사용하며, 메모리 대역폭 요구도 줄일 수 있지만 그만큼 fragment program에서 추가 연산이 필요하다. 연산 비용이 메모리 대역폭이나 지연 시간에 비해 상대적으로 큰 플랫폼에서는, 8:8 페이지 테이블과 별도의 매핑 텍스처를 사용하는 방식이 가장 높은 성능을 발휘할 수 있다.
mip-map된 페이지 테이블 텍스처를 사용하는 방식은, 더 정밀한 LOD(Level of Detail)를 접근할 때마다 dependent texture read가 필요한 쿼드 트리 구조를 사용하는 것보다 훨씬 빠르다.
하지만 쿼드 트리만 저장하는 방식과 비교했을 때, mip-mapped 페이지 테이블 텍스처를 사용할 경우 페이지 테이블의 갱신 비용이 훨씬 더 크다. 예를 들어, Virtual Texture의 첫 번째 페이지가 매핑될 때는 전체 페이지 테이블 텍스처를 단 하나의 texel 값으로 채워야 한다. 그 다음 더 정밀한 페이지가 매핑되면, texel의 4분의 1이 갱신되어야 하며, 이와 같은 방식으로 진행된다. 다행히도 이러한 대규모 페이지 테이블 갱신은 자주 발생하지 않는다.
- 빠른 성능이 중요한 실시간 렌더링 상황에서는 mip-mapped 페이지 테이블 방식이 유리하다.
- 반대로, 메모리 효율과 유연성이 더 중요하고 페이지 갱신이 자주 일어나는 경우에는 쿼드 트리 방식이 적합하다.
쿼드 트리나 페이지 테이블 텍스처를 사용하는 대신, 해시 테이블을 사용해서 레이턴시, 메모리 공간 차지와 연산을 중간책으로 사용할 수 있다. 상주하는 텍스처 페이지들만이 패시 테이블에 저장된다. 페이지의 mip level과 (x,y) 좌표로 이루어진 해시 테이블에서 Virtual 페이지를 찾는다.
좋은 해시 키 함수와 함께, 예를 들어 물리 페이지 수의 두 배 정도 크기인 작은 해시 테이블(예: 2048개의 항목)을 사용하는 경우, 충돌(collision)이 거의 발생하지 않으며, 대부분의 페이지를 단 한 번의 메모리 접근으로 찾아낼 수 있다.
- Hash Key Function: 입력(여기서는 virtual texture page 정보 등)을 고정된 크기의 해시값으로 변환하는 함수.
- Collision: 서로 다른 두 입력이 같은 해시값을 갖게 되는 경우.
- Hash Table Size: 테이블의 항목 수가 충분히 크면 충돌 확률이 낮아지고 빠른 lookup이 가능.
가상 텍스처 쿼드트리에서의 페이지 공간 인덱스를 해시 테이블 크기로 나눈 값을 해시 키로 사용할 수 있다. 그러나 더 나은 결과를 얻기 위해서는, 같은 mip 레벨 내에서 가상 페이지의 (x, y) 좌표를 다시 매핑하여 쿼드트리 내에서 서로 가까운 페이지들이 동일한 해시 테이블 항목으로 매핑되지 않도록 하는 것이 좋다.
해시 테이블은 더 정밀한 mip 레벨의 텍스처 페이지가 물리 페이지 풀에 아직 존재하지 않을 경우, 자동으로 더 낮은 해상도의 텍스처 페이지로 대체(fallback)하는 메커니즘을 제공하지 않는다. 대신, 원하는 페이지를 해시 테이블에서 찾을 수 없을 경우, 더 낮은 해상도의 페이지에 대한 해시 키를 계산하여 해당 페이지를 해시 테이블에서 가져오려 시도해야 한다. 이 더 낮은 mip 페이지도 존재하지 않을 경우, 유효한 페이지를 찾을 때까지 이 과정을 반복해야 한다. 평균적으로는 대부분의 원하는 페이지가 이미 상주해 있을 때, 해시 테이블을 이용한 접근 지연(latency)은 쿼드트리 기반 페이지 테이블보다 훨씬 낮다. 하지만 최악의 경우, 즉 상주해 있는 페이지가 거의 없거나 전혀 없을 때는 여러 개의 해시 키를 계산해야 하며, 여러 번의 메모리 접근이 필요하게 된다. 해시 테이블의 메모리 사용량은 작으며, 쿼드트리 페이지 테이블보다 약간 더 큰 수준에 불과하다. 해시 테이블은 쿼드트리 페이지 테이블과 페이지 테이블 텍스처 사이에서 흥미로운 중간 지점을 제공하긴 하지만, 대부분의 하드웨어에서는 페이지 테이블 텍스처에 직접 접근하는 방식이 선호된다. 그리고 가상 페이지당 2바이트만 사용하는 경우 페이지 테이블 텍스처의 메모리 요구량도 대체로 수용 가능한 수준이다.
3.2 텍스처 필터링
특수 그래픽 하드웨어의 지원 없이 Virtual Texture를 사용할 때 생기는 안타까운 복잡성 중 하나는, 텍스처 유닛이 실제 텍스처 페이지를 인식하지 못하므로 페이지 경계를 넘는 필터링을 수행할 수 없다는 점이다.
Virtual Texture 공간에서 인접한 텍스처 페이지들이 실제로는 물리 텍스처 내에서 서로 인접해 있지 않을 수 있으며, 심지어 가까이조차 위치하지 않을 수도 있다. 이러한 상황에서는 하드웨어 필터링 기능을 사용할 수 없으므로, 텍스처 필터링을 fragment program 내에서 완전히 구현하는 것은 비용이 너무 많이 든다. 몇 가지 fragment program 명령어를 추가로 사용하면, 물리 페이지의 경계에 있는 텍셀 값을 같게 만들어 bi-linear filtering을 사용할 수는 있다. 그러나 이 방식은 물리 페이지 사이의 경계 주소를 사용할 수 없다는 단점이 있다. 즉, 이런 방식으로 "clamp"된 페이지는 실제 물리 페이지 너비보다 한 텍셀 작은 유효 너비만을 가지며, 페이지 가장자리를 따라 반 텍셀 크기의 사용 불가능한 영역이 생긴다. 이러한 clamp된 페이지는 또한 mip level이 전환될 때 텍셀의 위치가 어긋나는 근본적인 문제를 가지며, 이로 인해 눈에 띄는 이음선(seams)이 나타나는 문제가 있다. 하드웨어 bi-linear filtering을 제대로 지원하려면, 각 physical texture page 주위에 텍셀(border texel) 테두리를 추가로 가지고 있어야 한다.
특수한 그래픽 하드웨어 지원 없이 소프트웨어로 구현된 virtual texture는 tri-linear filtering을 투명하게 지원할 수 없다. 하드웨어 가속 tri-linear filtering을 지원하는 가장 간단한 방법은 하나의 mip level을 physical page 형태로 텍스처에 저장하는 것이지만, 이 방식은 메모리 사용량이 약 25% 증가하고, 해당 mip level을 채우기 위한 연산량과 대역폭 요구가 늘어난다는 단점이 있다.
블록 압축된 physical texture를 사용할 때에도, 반드시 더 거친 virtual mip에서 더더욱 거친 physical mip로 매끄러운 전환이 이루어지는 것은 아니다. 예를 들어, 텍스처 페이지에 4 텍셀 경계가 있을 경우, physical texture의 첫 번째 mip level은 크기가 절반이고 2 텍셀 경계와 2 텍셀 오프셋을 가진 페이지로 채워지는데, 이로 인해 virtual mip과 비교했을 때 서로 다른 블록 압축 아티팩트가 발생하게 된다.
tri-linear filtering을 구현하는 또 다른 방법은 렌더링 중에 두 개의 virtual page에 접근하여 이들 사이의 LOD 비율을 결정하고 가중 평균을 계산하는 것이다. mip-mapped page table texture를 사용하는 경우에도, 단일 virtual to physical 변환 비용은 상당한 오버헤드를 수반한다. 다만 두 번째 변환의 일부 오버헤드는 첫 번째 변환 비용 뒤에 숨겨지는 점이 흥미롭다. 그럼에도 불구하고, 두 번의 virtual to physical 변환을 사용하는 Tri-linear 필터링은 여전히 꽤 비용이 많이 든다.
.시각적 품질을 향상시키기 위해서는 Tri-linear 필터링보다 anisotropic 필터링이 더 중요하게 작용하는 경향이 있다. 하드웨어 가속 anisotropic 필터링은 페이지 경계가 1 텍셀보다 넓을 때 지원될 수 있다. 따라서 일반적으로 각 physical page 주변에 4 텍셀의 경계가 사용된다. 다시 말해, 페이지 크기가 128 x 128 텍셀일 경우, 실제 데이터 영역은 120 x 120 텍셀이고, 그 주변을 인접한 virtual page에서 복제된 텍셀로 이루어진 4 텍셀 경계가 둘러싸고 있는 형태이다. 4 텍셀 경계는 하드웨어 지원 압축 포맷(DXT, S3TC, ETC 등)의 4x4 블록 크기와 잘 맞아떨어지며, 최대 8배의 anisotropic 합리적인 품질의 anisotropic 필터링을 가능하게 한다. 이상적으로는 virtual texture 좌표를 사용하여 anisotropic footprint를 계산하고, physical page들은 명시적으로 미분값(derivatives)을 지정하는 texture fetch로 샘플링된다. 이를 위해서는 서로 다른 mip 레벨에서 온 texture 좌표들이 가지는 서로 다른 스케일을 반영하기 위해 미분값들을 스케일링해야 한다. 이 스케일 factor는 virtual mip 레벨 크기와 physical texture 크기 간의 비율이다.
Virtual에서 physical로의 변환에 하나 이상의 매핑 텍스처를 사용하는 경우, 이 스케일 factor는 별도로 저장해야 하며, 이를 위해 추가적인 텍스처 컴포넌트가 필요하다. FP32x4 매핑 텍스처를 사용하는 경우, 사용되지 않는 컴포넌트에 스케일 factor를 저장할 수 있다. 반면, 세 개의 FP32x1 또는 두 개의 16비트 고정소수점 매핑 텍스처를 사용하는 경우에는 스케일 factor를 저장하기 위한 추가적인 텍스처나 컴포넌트를 추가해야 한다. 반면, virtual에서 physical로의 매핑이 fragment program에서 계산되는 경우에는(8:8:8:8 또는 5:6:5 page table 텍스처를 사용하는 경우), 추가 데이터를 저장할 필요가 없다. 이러한 경우에는 부록 A.5 및 A.6에 나와 있는 것처럼 fragment program 내에서 스케일 factor를 계산할 수 있다.
도함수를 계산하고 스케일링하는 작업은 fragment program의 복잡도를 높이며, 일부 하드웨어에서는 명시적 도함수를 사용하는 texture fetch가 더 비싸기 때문에 성능 측면에서 이 방법이 매력적이지 않을 수 있다. 대신, 암시적으로 계산된 도함수를 사용하는 물리 텍스처 좌표 상에서의 하드웨어 가속된 이방성(anisotropy)을 활용할 수 있다. 하지만 이 방법은 가상 페이지 경계를 넘는 quad-fragment의 경우, 물리 텍스처 공간이 경계에서 불연속이기 때문에 잘못된 anisotropic footprint를 만들어내는 문제가 있다. 가상 텍스처 공간에서 인접한 텍스처 페이지들이 물리 텍스처 상에서 반드시 인접하거나 가까운 위치에 매핑되는 것은 아니다. 하지만 가상 페이지 경계를 넘을 때 도함수(derivatives)의 방향이 임의로 크고 잘못 계산될 수 있음에도 불구하고, 최대 이방성(anisotropy)이 경계(border) 너비의 두 배 이하일 경우, 이방성 footprint는 여전히 하나의 physical 텍스처 페이지 내에 제한된다. 페이지 경계에서 발생하는 오류가 있는 footprint는 대부분의 하드웨어에서 성능과 품질 간의 적절한 트레이드오프로 간주된다. 최대 이방성(anisotropy) 값이 높아질수록 이러한 아티팩트는 증가하지만, 실제로는 높은 이방성 설정에서도 품질은 놀라울 정도로 양호하며, 이러한 오류 footprint는 상당한 확대 상태에서만 눈에 띌 정도이다.
불행히도, 구형 ATI/AMD 하드웨어에서 물리 텍스처 좌표에 대해 하드웨어 가속 이방성(anisotropy)을 사용할 경우, 가상 페이지 경계에서 하드웨어가 선택하는 샘플 위치가 페이지 경계를 벗어나기 때문에, 페이지 테두리 너비의 두 배 이하로 최대 anisotropy가 설정되어 있어도 눈에 띄는 아티팩트가 발생할 수 있다. 이러한 하드웨어에서는 mip-mapping이 적용되지 않은 physical 텍스처에 대해 anisotropic 필터링을 수행할 때, 실제 mip 레벨이 아닌 이상적인 mip 레벨을 가정하고 텍스처 공간을 따라 샘플링을 진행하기 때문에, 가상 페이지 경계에서 샘플링 간격이 지나치게 커질 수 있다.
다행히도 대부분의 ATI/AMD 하드웨어에서는 도함수(derivative)를 명시적으로 계산하고, 이를 스케일링한 후, 도함수가 명시된 텍스처 fetch를 사용하는 방식이 성능 면에서도 우수하기 때문에, 이러한 방식이 권장된다.
일반적으로 mip-mapped 텍스처에서 데이터를 가져올 때는, 이방성 필터링을 위해 여러 mip 레벨의 텍셀들을 샘플링하게 된다. 물리 텍스처에 대해 tri-linear 필터링을 지원하기 위해 추가적인 mip 레벨이 제공되더라도, 페이지 테이블 텍스처는 이후에 수행되는 이방성 텍스처 fetch를 고려하지 않고, 일반적인 Texture Lookup을 통해 point-sampling 방식으로 샘플링된다.
이는 서로 독립적인 페이지 매핑들 간에 블렌딩되어 데이터가 손상되는 것을 방지하기 위해, 개별 페이지 매핑을 정확히 가져와야 하기 때문이다. 따라서 페이지 테이블 텍스처는 반드시 point-sampling되어야 한다. 텍스처 하드웨어를 사용해 페이지 테이블 텍스처를 point-sample하는 방식은, 이후에 수행되는 이방성 텍스처 fetch에 적합한 텍스처 디테일을 가진 물리 텍스처 페이지로의 매핑을 보장하지 않는다. 아무런 조정 없이 페이지 테이블을 조회하면, 일반적으로 디테일이 부족하고 너무 조잡한 물리 텍스처 페이지로 매핑되는 결과를 얻게 된다. 이방성 텍스처 fetch에 더 많은 텍스처 디테일을 제공하기 위해, 페이지 테이블 조회 시 최대 이방성 계수의 음의 밑이 2인 로그 값을 바이어스로 적용할 수 있다. 이를 통해 시청자에 대해 비스듬한 각도로 놓인 표면처럼 샘플링 풋프린트가 극대화되는(즉, 이방성이 큰) 경우에도 이방성 텍스처 fetch가 더 높은 디테일의 텍스처를 사용할 수 있게 된다. 하지만 이 방식은 샘플링 풋프린트가 최소가 되는(등방성인) 경우, 즉 시야 방향에 수직인 표면에서는 눈에 띄는 깜빡임(shimmering)이나 앨리어싱(aliasing)을 유발할 수 있다. 이러한 품질 문제를 개선하기 위해, fragment program 내에서 이방성 값을 기반으로 페이지 테이블 텍스처 조회에 사용할 텍스처 LOD(Level of Detail)를 계산할 수 있다. 계산된 LOD는 이후 페이지 테이블 텍스처 조회에 명시적으로 전달된다. 아래는 해당 텍스처 LOD 계산 방법을 보여준다.
const float maxAniso = 4;
const float maxAnisoLog2 = log2( maxAniso );
const float virtPagesWide = 1024;
const float pageWidth = 128;
const float pageBorder = 4;
const float virtTexelsWide = virtPagesWide * ( pageWidth - 2 * pageBorder );
float2 texcoords = virtCoords.xy * virtTexelsWide;
float2 dx = ddx( texcoords );
float2 dy = ddy( texcoords );
float px = dot( dx, dx );
float py = dot( dy, dy );
float maxLod = 0.5 * log2( max( px, py ) ); // log2(sqrt()) = 0.5*log2()
float minLod = 0.5 * log2( min( px, py ) );
float anisoLOD = maxLod - min( maxLod - minLod, maxAnisoLog2 );
물론 텍스처 LOD(Level of Detail)을 계산하는 것은 fragment program의 계산 복잡도를 상당히 증가시킨다. 하지만 흥미로운 점은, 고정된 LOD 바이어스를 사용하는 것에 비해 일부 성능이 향상된다는 것이다. 이는 더 나은 텍스처 캐시 사용 덕분이다. 시야 방향에 거의 수직인 표면의 경우, 계산된 LOD는 더 낮은 해상도의 mip level이 선택되도록 하여 캐시 효율을 높이고, 결과적으로 성능에 긍정적인 영향을 준다.
시야 방향에 거의 수직인 표면의 경우, 계산된 LOD는 텍스처 샘플들이 서로 더 가까워지는 mip level을 선택하게 만든다. 하지만 anisotropic footprint에 따라 mip level을 선택하는 것은 추가적인 fragment program 복잡성 때문에 성능 측면에서 매력적이지 않을 수 있다. 대신, 최대 anisotropy를 4로 설정하고, page table texture 조회에 -2의 상수 바이어스를 적용하는 방식이 품질과 성능 간에 적절한 균형을 이루는 경우가 많는다. 이 방법은 시야와 비스듬한 각도의 표면에서는 훨씬 더 선명한 결과를 보여주며, 시야 방향에 수직인 표면에서 나타나는 깜박임이나 앨리어싱 현상은 보통 크게 문제되지 않는다.
3.3 여러 가상 주소로부터 렌더링하기 (Rendering from Multiple Virtual Addresses)
종종 같은 모델에 대해 서로 다른 텍스처 데이터를 제공하여 커스터마이징하거나 손상, 팀 표시 등을 나타내고자 하는 경우가 있다. 기존의 API 사용 방식에서는 별도의 스킨 텍스처 세트나 모든 스킨을 포함하는 Texture Array를 사용하는 방법이 일반적이다. 그러나 가상 텍스처에서는 스킨별로 단일 큰 가상 텍스처 내에서 고유한 공간을 할당받고, 각 스킨에 대해 기본 텍스처 (s, t) 주소를 제공하여 정점 프로그램에서 가상 텍스처 좌표를 오프셋하는 방식으로 처리할 수 있다. 손상 표현용 스킨은 여러 텍스처 소스를 혼합하기 위해 프래그먼트 당 여러 번의 virtual to physical 변환을 필요로 하지만, 두 번째 변환 비용이 첫 번째 변환 뒤에 자연스럽게 숨겨져 예상보다 비용이 크지 않다. 따라서 프래그먼트 당 두 번의 virtual to physical 변환을 적절히 사용하는 것은 성능을 유지하면서 국부적인 손상을 효과적으로 표현하는 데 매우 유용하다.
3.4 피드백 렌더링(Feedback Rendering)
Sparse representation을 사용하면 텍스처의 일부만 메모리에 적재된 상태로도 렌더링이 가능하지만, 어떤 부분의 텍스처가 메모리에 있어야 하는지를 판단하기 위해 피드백이 필요히다. 텍스처 피드백은 별도의 버퍼에 렌더링되며, 현재 장면에서 사용된 가상 텍스처 페이지들의 가상 페이지 좌표 (x, y), 원하는 MIP 레벨, 그리고 가상 텍스처 ID(여러 개의 가상 텍스처를 구분하기 위함)를 저장한다. 이 정보는 장면 렌더링에 필요한 텍스처 페이지를 메모리에 적재하는 데 사용된다. 피드백은 별도의 렌더링 패스로 렌더링하거나, 기존 렌더링 패스에서 추가적인 렌더 타겟에 렌더링할 수 있다. 피드백을 렌더링하는 방식의 장점은 깊이 테스트가 제대로 수행된다는 점으로, 결과적으로 보이지 않는 텍스처 페이지에 대한 요청으로 가상 텍스처 파이프라인이 불필요하게 부담되지 않도록 한다. 별도의 렌더링 패스를 사용할 경우 피드백 해상도는 훨씬 낮게 설정해도 무방하다(예: 10배 낮은 해상도). 피드백 버퍼에 렌더링할 수 있는 프래그먼트 프로그램은 부록 B에 제시되어 있다.
피드백 렌더링 패스에서는 실제 텍스처 데이터가 아니라 텍스처 좌표만 사용된다. 이는 알파 테스트나 투명한(transparent) 표면이 완전히 불투명한 것으로 간주된다는 것을 의미한다. 실제로, 알파 테스트나 투명한 가상 텍스처 데이터를 사용하여 피드백을 생성하는 것은 일반적으로 불가능하다. 왜냐하면 이러한 텍스처 데이터는 아직 메모리에 적재되지 않았을 수 있고, 해당 텍스처 데이터를 적재하기 위해서는 먼저 올바른 피드백이 생성되어야 하기 때문이다.
알파 테스트나 투명한 표면을 통해 보이는 텍스처 데이터를 제대로 불러오기 위해서는, 완전히 불투명하지 않은 표면들을 일정한 프레임 간격으로 무작위로 피드백 버퍼에 렌더링하는 방식이 사용될 수 있다. 비슷하게, 하나의 표면이 여러 가상 텍스처 소스를 사용하는 경우, 각 렌더 프레임마다 이러한 소스들을 번갈아 사용함으로써 시간이 지나면서 필요한 모든 텍스처 데이터를 불러올 수 있다.
하지만 이 방식은 가상 텍스처 파이프라인을 불안정하게 만드는 경향이 있다. 이는 장면이 바뀌지 않더라도 매 프레임마다 서로 다른 텍스처 페이지가 요청되기 때문이다. 한 프레임에서 요청된 페이지가 이전 프레임에 같은 표면을 위해 요청된 페이지를 교체할 수 있고, 그 결과 시스템이 결코 안정 상태에 도달하지 못하고, 가장 높은 디테일의 텍스처 데이터가 필요한 장면을 렌더링하는 데 실패하게 된다. 페이지가 계속해서 교체되기만 하고, 최종적으로 필요한 고해상도 텍스처는 메모리에 올라오지 못하는 상황이 발생할 수 있다. 표면이 여러 개의 가상 텍스처 소스를 사용하는 경우, 하나의 해결책은 피드백 버퍼에서 서로 다른 픽셀마다 서로 다른 텍스처 소스를 번갈아 사용하는 방식이다. 예를 들어 두 개의 소스에서 렌더링할 경우, 피드백 버퍼 상에서 간단한 체커보드 패턴(체스판 무늬)을 형성하게 된다. 두 개 이상의 소스를 사용할 경우에는 더 복잡한 패턴을 적용할 수 있다. 이 방식은 피드백 버퍼의 해상도가 낮고, 대상 표면이 화면상에서 매우 작아 적은 수의 픽셀만 차지하는 경우에는 피드백 샘플링 부족이 발생할 가능성이 있지만, 실제로는 눈에 띄는 문제로 나타나지 않는다. 따라서 실용적인 해결책으로 널리 사용될 수 있다.
비슷한 방식은 알파 테스트되거나 투명한 표면에도 적용할 수 있다. 이 경우, 해당 표면이 덮고 있는 피드백 버퍼의 픽셀을 서로 번갈아가며 완전히 투명하거나 완전히 불투명하게 간주하는 것이다. 예를 들어 간단한 체커보드 패턴을 사용하여 투명/불투명 상태를 번갈아 적용할 수 있다.
하지만, 여러 개의 알파 테스트 또는 투명 표면이 층을 이루며 겹쳐져 있는 장면에서는 단순한 패턴만으로는 필요한 모든 텍스처 데이터를 충분히 끌어올 수 없다. 이 문제를 완화하기 위해서는 더 복잡한 패턴을 사용하거나, 각 투명 표면마다 서로 다른 패턴을 적용하는 방식이 효과적이다. 이는 스크린도어 트랜스퍼런시(screen-door transparency) 또는 alpha-to-coverage 방식으로 렌더링하는 것과 유사하다. 일부 하드웨어에서는 실제로 이런 기법을 사용할 수 있으며, 피드백 버퍼의 알파 채널을 피드백 데이터 저장 용도로 사용하지 않을 경우 이러한 방식이 피드백 구현에 활용될 수 있다.
최신 그래픽 하드웨어에서는 atomic operations을 지원하기 때문에 픽셀 단위의 연결 리스트(per pixel linked lists)를 구현할 수 있다. 이러한 연결 리스트는 structured append/consume 버퍼라고도 불리며, 픽셀당 임의의 개수의 데이터 요소를 추적할 수 있게 해 준다.
이러한 기능을 활용하면, 투명도 계층별 가상 텍스처 피드백 데이터나 하나의 표면에서 사용되는 서로 다른 가상 텍스처 소스별 피드백 데이터를 각 픽셀에 저장된 체인에 단순히 append하여 추적할 수 있다.
비록 구현 복잡도가 증가하긴 하지만, 이 방법은 알파 테스트된 또는 투명한 표면이 매우 작아서 피드백 버퍼 내 몇 개 픽셀만 덮는 경우에도 피드백 샘플링 부족(undersampling)의 가능성을 줄여준다.
피드백 렌더링 패스의 결과는 별도의 프로세스에서 분석된다. 이 프로세스는 피드백 렌더의 완료를 기다리며 멈출 수도 있지만, 일반적으로 한 프레임 이전의 데이터를 사용하고 한 프레임 지연(latency)이 발생하는 것은 괜찮다.
피드백 분석 과정에서는 화면 버퍼를 순회하면서 페이지 정보를 중복 없이 정리된 고유 페이지 목록으로 압축한다. 결과적으로 이 분석 과정은 현재 씬을 올바르게 렌더링하는 데 필요한 모든 페이지를 포함하는 mip-map 계층의 쿼드트리를 생성하는 역할을 한다.
분석 프로세스는 페이지들을 우선순위(priority) 기준으로 정렬한다.
- 첫 번째 기준: 요청된 mip 레벨과 현재 메모리에 존재하는 mip 레벨 간의 차이가 클수록, 즉 더 낮은 디테일 수준에서 높은 디테일 수준으로 바꿔야 할수록 우선순위가 높아진다.
- 두 번째 기준: 피드백 버퍼에서 특정 페이지가 참조된 샘플 수가 증가하면 해당 페이지의 우선순위가 더 높게 설정된다.
이렇게 정렬된 페이지 목록은 가상 텍스처 시스템이 다음과 같은 작업에 사용된다:
- 현재 메모리에 존재하면서도 화면에 보이는 페이지들의 유지
- 아직 메모리에 없지만 시각적 품질 향상에 가장 큰 영향을 줄 비거주(non-resident) 페이지들을 우선적으로 스트리밍
3.5 Oversubscription
가상 저장공간을 사용하는 모든 시스템에서 물리적 저장공간이 working set을 감당할 만큼 충분하지 않을 때, thrashing이 발생할 수 있다. 이것은 virtual texture 시스템이 성능 저하 없이 대처할 수 있는 경우이다.
만약 숫자가 높은 워터마크보다 더 높을 경우, 시스템이 overscribed 되었다고 간주하고 피드백을 생성할 때 사용되는 LOD bias가 증가한다. 만약 숫자가 low eater mark보다 낮을 경우, 시스템은 undersubscribed 되었다고 간주되고, 피드백에 사용되는 LOD bias가 감소한다. LOD bias의 다이내믹 피드백은 음수가 되지 않도록 항상 clamping 된다. 이 메커니즘은 충분한 디테일을 제공할 수 없는 뷰에서는 thrashing 없이 디테일을 잠시 보류했다가, 시스템이 여유가 생기는 즉시 디테일을 다시 추가한다.
Mip-map 된 텍스처들로부터 렌더링 할 때, 이론적으로 화면 해성도의 4배 이상의 텍셀은 필요 없다. 그러나 (페이지 경계를 고려해서)화면 해상도의 4배보다 더 많이 수용할 수 있는 physical page가 있다면, 시스템은 여전히 oversubscibe 된 상태가 될 것이다 - 텍스처 페이지들의 크기 조합과, geometry가 virtual texture 상에서 unwrap 된 방식이 그 원인이 될 수 있다. 텍스처 공간상에서 비교적 작고 가느다란 오브젝트이면서, 다양한 방향으로 난 여러 개의 면들로 이루어진 오브젝트가 같은 페이지에 모든 면이 unwrap 되었을 경우 상당한 오버헤드를 발생시킬 수 있다. 한 번에 적은 갯수의 면만 보이더라도, 텍스처 페이지 전체가 로드되지만, 그 중 대부분의 텍셀이 보이지 않을 것이기 때문이다. 더 작은 텍스처 페이지를 사용하면, 불필요하게 로드되는 텍셀들의 갯수를 줄일 수 있다. 하지만, 작은 페이지들은 border 때문에 비교적 많은 공간을 낭비하게 되고, 넓은 페이지 ㅔ이블일 때 더 많은 메모리를 필요로 한다. 텍셀이 128x128 크기인 페이지를 사용하는 것이 적당하다.
3.6. LOD Snapping / Texture Popping
아무리 노력을 기울인다 해도, 텍스처 페이지가 필요한 순간과 데이터가 사용 가능하게 되는 순간까지는 상당한 지연이 발생할 수 있다. 이로 인해 페이지의 원하는 LOD가 한 레벨 이상 차이 나다가 올바른 LOD가 갑자기 사용 가능해질 때, 불쾌한 "팝" 현상이 발생할 수 있다. 가장 간단한 접근 방식은, 두 번의 virtual-to-physical 변환을 사용하는 tri-linear filtering을 적용할 경우, 현재 표시되고 있는 LOD와 원하는 LOD 간의 차이가 충분히 작지 않을 때 더 낮은 mip 레벨에서 더 높은 mip 레벨로 전환하는 데 약간의 지연을 포함시키는 것이다. 이 지연은 페이지 테이블이나 매핑 텍스처에 인코딩될 수 있다. bi-linear 또는 단일 mip 레벨을 사용하는 anisotropic filtering이 사용되는 경우에는 다른 접근 방식이 필요하다. 렌더링 중에 tri-linear filtering을 사용하는 대신, 물리 페이지를 더 낮은 mip과 더 높은 mip 간의 일종의 블렌드로 지속적으로 갱신할 수 있다. 더 높은 mip 레벨이 사용 가능해질 때까지 기다렸다가, 낮은 mip 레벨을 업샘플링한 버전으로 시작하여 점진적으로 전환하는 것은 그럴듯한 해결책처럼 보인다. 그러나 업샘플된 이미지가 매핑될 때 샘플 위치가 갑자기 바뀌기 때문에, 이 방식만으로는 텍스처 팝핑 현상을 완전히 제거할 수 없다. 다른 텍스처보다 해상도가 두 배인 텍스처를 생성하더라도, 두 텍스처 모두 텍셀 중심 사이에서 바이리니어 확대(bi-linear magnification)로 렌더링될 때 정확히 동일한 바이리니어 필터 패턴을 생성하는 것은 불가능하다. 바이리니어 확대는 텍셀 중심들 사이로 삼각형의 물결 패턴을 생성하는데, 이것은 두 배 해상도의 텍스처에 복제될 수 없어 바이리니어 확대로는 렌더할 수 없다. 두 배로 확대된 해상도에서는 이 삼각형의 상단과 하단이 잘려나간 패턴을 보여준다. 결과적으로 바이리니어로 확대된 거친 mip으로부터, 이 mip을 업샘플링해서 생성된 더 정밀한 mip으로 전환할 때 눈에 띄는 팝이 나타나게 된다.
더 좋은 솔루션은 거친 mip이 확대되기 전에 upsampling을 수행해서 더 세밀한 mip의 physical 페이지를 만든느 것이다. 뷰포인트가 실제 텍스처된 표면으로 다가올수록, 거친 mip으로부터 업샘플링해서 만들어진 세밀한 mip이 서서히 나타날 것이다. 실제 더 세밀한 mip이 사용 가능해질 때까지, 더 거친 mip으로부터 업샘플링해서 만들어진 mip이 블렌딩될 것이다. 샘플의 위치가 아닌 텍셀의 컬러만 바뀌기 때문에, 갑작스러운 변화는 없을 것이다.
여러 가지 흥미로운 알고리즘을 사용해서 더 거친 mip으로부터 업샘플링해서 더 세밀한 mip을 만들 수 있다. 예를 들어, 더 직관적인 bi-cubic 필터를 사용할 수 있다. 하지만, 더 복잡한 엣지-강화 필터도 사용할 수 있다. 렌더링에 필요해지는 즉시 업샘플링을 통해 더 정밀한 밉맵을 생성하는 방식은, 원래의 텍스처 콘텐츠가 없을 경우에도 흥미로운 디테일을 만들어내는 데 사용할 수 있다.
4. 저장 공간과 스트리밍 (Storage & Streaming)
4.1 저장 공간 & 압축 (Storage & Compression)
범용적으로 적용되는 가상 텍스처를 수용하기 위해, 동일한 물리 페이지들을 담고 있지만 서로 다른 데이터를 저장하는 3개의 물리 페이지 텍스처가 사용된다. 이 3개의 텍스처는 텍셀당 총 10개의 채널을 저장한다. 하나의 텍스처는 YCoCg 색 공간을 사용하여 Diffuse 맵을 저장하며, 이는 렌더링 시 프래그먼트 프로그램에서 다시 RGB로 변환된다. 또 다른 텍스처 1장에는 탄젠트 공간의 노멀 맵의 X, Y 컴포넌트가 저장되는데, 노멀의 Z 컴포넌트는 렌더링 도중 프레그먼트 프로그램에서 도출된다. 같은 텍스처의 채널 1개에 power map 도 저장된다. 마지막으로, 1개의 텍스처에 specular map가 RGB 또는 흑백 컬러로 저장된다. 이 텍스처는 cover mask 를 1-bit alpha로 저장한다.
비디오 메모리의 physical 텍스처는 압축되지 않은 상태 또는 DXT 압축 상태로 저장될 수 있다. DXT 압축은 비디오 메모리 사용량과 렌더링 시 bandwidth 필요량을 줄이기 위해 선호된다. DXT 압축된 텍스처 3장이 physical page 텍스처들을 저장하는 데 사용된다 - 1개의 DXT1은 specular map과 alpha를 저장하고, DXT5 는 YCoCg Diffuse 맵을 저장한다. 도 1개의 DXT5 텍스처ㅔㅇ는 탄제트 공간 노멀 맵과 power map이 저장된다. 압축되지 않았을 때, 각 physical page는 192KB를 차지하지만, DXT 포맷은 physical page 1개당 40kB 를 차지한다.
disk상의 페이지들은 무압축, DXT 압축, 또는 variable bit rate 압축 포맷 - JPEG 같은 DCT 기반 포맷, HD-Photo . JPEG/XR 등으로 압축되어 저장될 수 있다. 독립적으로 텍스처링 된 아주 넓은 월드를 한정된 공간의 광학 디스크에 저장하려면, 높은 압축률이 필요하다. 느린 저장소에서 텍스처 데이터를 스트리밍 할 때 필요 대역폭을 줄이기 위해서도 높은 압축률이 필요하다. 그렇기 때문에, variable bit rate 압축을 사용해 텍스처를 디스크에 저장하면 텍스처 페이지 대부분이 1 ~ 6KB 로 줄일 수 있다.
텍스처 필터링을 위한 4텍셀 인셋 보더(inset border)와 물리 페이지 크기가 128 x 128 텍셀일 경우, 각 페이지당 실제로 사용할 수 있는 유효 텍셀(payload)은 120 x 120 텍셀만 남게 된다. 따라서 올바른 텍스처 필터링을 위한 보더는 약 12%의 추가 텍셀 비용을 초래한다. 보더 텍셀은 디스크에 저장할 필요는 없지만, 실질적으로는 각 페이지가 완전히 독립적으로 동작하도록 하기 위해 이 추가적인 12%의 텍셀을 디스크에 함께 저장하는 것이 훨씬 단순한 방법이다.
4.2 압축률 향상시키기
텍스처 데이터가 디스크로 압축되기 전에, 압축률을 올리기 위한 여러 방법들을 사용해 처리할 수 있다. 예를 들어, diffuse 맵은 사용되는 압축 알고리즘에 따라 4:2:0 으로 YCoCg 로 sub-samping 될 수 있다. 비슷한 방법으로, specular map은 특별한 색상 정보가 없다면 흑백으로변환되거나, 4:2:0 서브샘플링으로 YCoCg 컬러 공간이 사용될 수 있다.
4:2:0 과 YCoCg
실시간 specular reflection의 근사로 미리 계산된 라이팅 솔루션을 사용하면 추가적인 이득을 볼 수 있다. 예를 들어, global illunimation 알고리즘에 기반한 오프라인 radiosity 가 환경의 스태틱 라이팅을 계산하는 데 사용되고, specular reflection만 근사를 통해 실시간으로 계산될 수 있다. 이런 근사값이 제대로 보이려면, specular 맵은 오프라인에서 shadow 부분이 다운스케일 되어 그림자 진 영역에서는 specular reflection이 감소되도록 해야 한다. 이렇게 하면, specular 맵의 다이내믹 레인지를 그림자 진 영역에서 감소시킬 뿐만 아니라, 압축률도 증가시킬 수 있다. specular 맵 값을 완전히 누락할 수 있는 경우도 있다. 만약 환경으로부터 각각의 독립된 텍셀로 들어으는 입사광이 모든 방향에서 거의 같다면(같은 색상과 강도라면), 상수 값의 specular contribution을 미리 라이팅된(pre-lit) diffuse map으로 옮길 수 있고, texel 단위의 epecular 값은 저장할 필요가 없다.
미리 계산된 라이팅이 사용될 경우, 노멀 X 와 Y 컴포넌트를 specular intensity에 따라 스케일링해서 dynamic range 를 줄여 압축률을 높일 수 있다. 미리 계산된 라이팅을 사용하면, 표면의 요철들은 diffuse map에 이미 베이킹 되어 있고, 그 외에는 동적인 specular 반사가 있을 때만 눈에 띄게 된다.
X와 Y 성분의 크기를 줄이면, 런타임에서 계산되는 Z 성분의 크기가 커지게 되어, 탄젠트 공간 노멀은 표면에서 수직으로 향하는 방향으로 수렴하게 된다. 이는 결과적으로 Specular 반사가 줄어들수록 표면의 울퉁불퉁함이 덜 보이게 만든다. Specular 라이팅을 기반으로 인지되는 울퉁불퉁함을 줄이는 것은 약간의 품질 저하를 초래하지만, 그 품질 저하는 보통 미미한 수준이며, 그에 비해 저장 공간 절약 효과는 상당하다.
4.3 Visibility 기반 최적화
대형 가상 텍스처는 고유한 텍스처 데이터의 비용을 줄여주지만, 매우 넓은 가상 세계에서는 사용자(뷰어)가 접근할 수 없거나 멀리서만 볼 수 있는 영역이 많아지는 경우가 흔하다. 특히 컴퓨터 게임에서는 가까이에서 절대 볼 수 없는 표면들이 많이 존재하게 된다. 이러한 이유로, 장면 가시성에 대한 오프라인 brute-force 분석을 수행하여, 전 방향의 가상 텍스처 피드백 데이터를 수집하고 가능한 모든 뷰어 위치에 대해 보일 수 있는(can-be-seen) 데이터를 표시하는 것이 매우 유용할 수 있다. 예를 들어 컴퓨터 게임에서는 이러한 brute-force 방식의 가시성 결정이 플레이어의 내비게이션 공간( (configuration space)의 바닥 표면을 샘플링하는 방식으로 수행될 수 있다. 무엇보다도, 텍셀 단위의 가시성(per-texel visibility)을 캡처하는 것이 유용하다. 저장 공간 요구를 줄이기 위해, 가시성은 가상 텍스처 내 4x4 텍셀당 1비트로 추적할 수 있다. 이렇게 얻어진 가시성 정보는 절대로 보이지 않는 전체 페이지들을 제거하는 데 사용할 수 있다. 다시 말해, 가상 텍스처는 비디오 메모리에 드물게 상주할 뿐만 아니라, 소스 데이터 자체도 드물게 채워질 수 있다. 더 나아가 이 가시성 정보는 페이지 내 보이지 않는 영역을 블러 처리하여 압축률을 높이는 데에도 활용될 수 있다.
둘째로, 텍스처 공간에서 연속적인 지오메트리 조각들(문헌에서는 흔히 "아틀라스(atlas)" 내의 "차트(chart)"라고 불림)에 대해 텍셀 영역 할당을 최적화하기 위한 데이터를 수집할 수 있다. 이 경우에는 텍셀 단위의 가시성을 캡처하는 대신, 각 차트에 대해 다음과 같은 정보를 기록한다: 차트 ID, 관측된 샘플 수, 최소 도함수(derivative), 도함수의 최소 비율, 그리고 최대 비율이다.
이러한 정보는 이후 텍스처 공간에서 객체들의 크기를 조정하는 데 사용된다. 이를 통해 각 객체가 가상 텍스처 상에서 적절한 공간을 차지하도록 할 수 있으며, 이는 단순히 월드 유닛당 텍셀 수를 기준으로 할 뿐만 아니라 가시성까지 고려한 것이다. 이 방식은 예를 들어, 책상 위에 놓인 소다 캔이 책상보다 20배 더 높은 텍셀 밀도를 갖는 상황을 피할 수 있을 뿐만 아니라, 가까이에서 절대 보이지 않는 객체들의 차트는 가상 텍스처에서 축소할 수 있도록 해 준다.
처음 매우 큰 텍스처 아틀라스를 생성할 때는, 각 차트가 얼마나 많은 텍스처 공간을 차지해야 할지 결정할 수 있는 가시성 기반 정보가 존재하지 않기 때문에, 각 차트에 대해 월드 공간 상의 면적을 기반으로 한 추정치를 사용한다. 이후, 차트 단위로 가장 정밀한 LOD(레벨 오브 디테일) 데이터를 수집한 뒤, 이러한 추가 정보를 바탕으로 아틀라스를 다시 최적화하게 된다.
4.4 레이아웃과 Locality
가상 텍스처에 텍스처 데이터를 어떻게 배치하느냐는 실시간 애플리케이션에서 매우 중요하다. 왜냐하면 광디스크의 탐색 시간은 100ms 이상 수준이며, 텍스처 데이터를 인터넷을 통해 스트리밍할 때도 이와 비슷한 지연이 발생할 수 있기 때문이다. 로컬 하드 디스크가 있는 시스템에서는 필요한 데이터를 장시간 동안 불러오지 못하는 위험을 크게 줄일 수 있다. 하지만 안타깝게도 모든 시스템이 하드 디스크를 갖추고 있는 것은 아니며, 일부 시스템은 텍스처 데이터를 캐싱할 수 있는 하드 디스크 공간이 제한적일 수 있다.
가상 텍스처의 레이아웃을 최적화할 때 고려해야 할 여러 가지 주요 지표들이 있다. 가장 중요한 것 중 하나는 텍셀 밀도(texel density)의 일관성을 유지하는 것이다. 이는 결코 화면에 보이지 않는 LOD 텍셀들에 가상 텍스처 공간이 낭비되지 않도록 하기 위함이다. 앞서 설명한 것처럼, 지오메트리 "차트(chart)"의 텍셀 할당은 brute-force로 수집한 가시성 정보를 바탕으로 최적화할 수 있다.
그런 다음 차트들은 가상 텍스처 상에서 가능한 한 공간 낭비를 최소화하도록 배치된다. 차트들은 종종 모양이 불규칙하기 때문에 특정한 상대적 위치에서만 잘 맞물려 배치될 수 있다. 또한 차트들의 배치 효율을 높이기 위해 방향(orientation)을 회전시키는 것도 가능하다. 하지만 가상 주소 지정이 단지 스케일과 바이어스만으로 이루어질 경우, 차트의 방향 변경에 대응하기 위해 지오메트리의 텍스처 좌표를 수정해야 한다. 또한 차트를 회전시키는 것은 최적화 과정을 훨씬 더 복잡하게 만든다.
공간 낭비를 최소화하는 것도 중요하지만, 가상 텍스처 상에서 “차트(chart)”들의 지역성(locality)을 최적화하여 렌더링되는 장면이 가능한 적은 수의 텍스처 페이지를 사용하도록 하는 것도 매우 중요하다. 이는 어려운 최적화 문제이며, 때로는 가상 텍스처 내 공간 낭비 최소화와 상충될 수 있다. 지역성 최적화와 공간 낭비 최소화를 동시에 해결하는 문제는 메쉬 매개변수화(mesh parameterization)와 빈 패킹(bin-packing) 문제의 결합으로, NP-하드 문제에 해당한다. 합리적인 해결책으로는 먼저 3D 이진 공간 분할(Binary Space Partitioning, BSP)을 사용해 차트들을 공간적으로 정렬한 뒤, 트리를 너비 우선 탐색(breadth-first)하면서 2D 텍스처 공간을 2D 지역성을 고려한 공간 채우기 곡선(space-filling curve)을 이용해 할당하는 방법이 있다.
모든 차트가 가상 텍스처 상에 최적으로 배치된 후에는, 렌더링되는 장면이 필요한 텍스처 데이터를 스트리밍할 때 탐색(seek) 시간을 최소화할 수 있도록 광디스크 상에서 텍스처 페이지의 지역성(locality)을 최적화하는 것이 중요하다. 이전 연구[26]에서는 쿼드트리 순서로 페이지를 디스크에 배치하고, 여러 밉맵 레벨을 교차 배치하는 방식을 제안했다. 이 방법은 주로 평탄하고 연속적인 지형에서는 잘 작동하지만, 임의의 3D 환경에 적용되는 가상 텍스처의 경우 상황이 훨씬 더 복잡해진다.
4.5 스트리밍과 캐싱
자주 사용되는 텍스처 페이지를 스트리밍할 때 캐시는 지연 시간을 크게 줄이는 데 활용될 수 있다. 특히 최근에 본 텍스처 페이지를 저장하는 시스템 메모리 내 캐시는, 예를 들어 뷰가 갑자기 이전에 있던 방향으로 돌아갈 때와 같이 이전에 본 영역의 텍스처 데이터를 이용해 물리 페이지를 업데이트하는 지연 시간을 효과적으로 줄여준다.
텍스처 페이지가 광디스크에서 시스템 메모리로 스트리밍될 때, 이후 빠른 접근을 위해 하드 디스크 캐시에 다시 저장될 수 있으며, 이를 통해 매우 긴 탐색 시간(seek time)의 영향을 줄일 수 있다. 고성능 스트리밍을 위해서는 일반적으로 하드 디스크나 광디스크처럼 비교적 느린 저장 장치로부터 텍스처 페이지를 가져오기 위해 여러 소프트웨어 스레드를 사용하며, 각 저장 장치마다 별도의 스레드를 구현하는 경우가 많다.
가변 비트레이트 압축과 DXT 고정 블록 압축 간의 압축 비율이 10:1에서 20:1 범위에 이르기 때문에, 가능한 한 오랫동안 데이터를 완전히 압축된 상태로 유지하여 사용 가능한 메모리를 최적으로 활용하는 것이 중요하다. 텍스처 데이터는 광디스크, 하드 디스크, 시스템 메모리, 그리고 비디오 메모리 내의 물리 페이지 텍스처, 총 4개의 구분된 위치에 저장된다. 이 데이터는 물리 페이지 텍스처를 제외한 모든 캐시 단계에서 가변 비트레이트 압축 형식을 사용한 채로 유지된다.
모든 가상 메모리 시스템과 마찬가지로, 가상 텍스처 시스템도 "고정(pinned down)"된 메모리 영역을 가질 수 있다. 즉, 항상 상주하며 교체할 수 없는 텍스처 페이지들이 존재하는 것이다. 예를 들어, 가상 텍스처의 가장 거친 밉 레벨(coarsest mip level)을 나타내는 텍스처 페이지는 보통 물리 페이지 텍스처에 고정되어, 뷰포인트가 갑자기 완전히 새로운 텍스처 데이터가 있는 장면으로 변경될 때에도 항상 기본으로 사용할 수 있는 텍스처 데이터가 존재하도록 보장한다.
5. 물리 페이지 업데이트 (Physical Page Updates)
5.1 파이프라인 개요
그림 12는 물리 페이지 업데이트 파이프라인의 개요를 보여준다. 장면에 대한 텍스처 피드백은 작은 스크린 버퍼에 렌더링된다. 이 스크린 버퍼의 컬러 값은 현재 렌더링된 장면의 픽셀에 대응하는 가상 텍스처 페이지를 저장하는 데 사용된다. 이 버퍼로부터 피드백 분석은 상주해야 할 텍스처 페이지들의 정렬된 리스트를 생성한다. 피드백 분석에서 정렬된 페이지들은 현재 렌더링 중인 장면의 시각적 품질을 가장 향상시킬 수 있는 비상주(non-resident) 페이지들을 먼저 업데이트하는 데 사용된다. 이미 물리 텍스처에 존재하는 보이는 페이지들은 계속 상주(residency)를 유지한다.
정렬된 각 페이지에 대해, 시스템은 캐시에서 압축된 텍스처 데이터를 가져오려고 시도한다. 캐시 히트가 발생하면 캐시는 압축된 텍스처 데이터를 반환하고, 캐시 미스가 발생한 경우에는 백그라운드에서 데이터를 불러오도록 스케줄링한다. 압축된 텍스처 데이터가 있는 텍스처 페이지에 대해서는 시스템이 새로운 물리 페이지를 할당한다. 새로운 물리 페이지를 사용하기 전에, 해당 페이지를 언맵(unmap)하여 GPU가 더 이상 그 페이지를 사용하지 않고, 대신 상위의 더 거친 부모 페이지로 전환하도록 한다. 압축된 텍스처 페이지는 GPU에서 렌더링할 수 있도록 트랜스코딩된다. 전체 텍스처 페이지의 트랜스코딩이 완료된 후에야 해당 페이지가 매핑되어 GPU가 이 페이지를 사용해 렌더링을 시작한다.
5.2 Replacement Policy
새로운 물리 페이지가 요청된 가상 페이지를 저장하기 위해 할당되어야 할 때, 모든 물리 페이지는 우선순위에 따라 정렬되며, 가장 높은 우선순위를 가진 물리 페이지가 교체 대상으로 선택된다. 우선순위는 우선 해당 페이지의 LOD 레벨을 기준으로 하여, 더 세밀한 밉 맵(finer mip)이 먼저 교체된다. 이는 상주하는 페이지들로 구성된 밉 계층 구조를 나타내는 쿼드트리(quad-tree)가 점차 잎 노드를 제거하거나 추가하면서 구조가 변화한다는 것을 의미한다. 다음으로, 교체 우선순위는 해당 페이지가 마지막으로 사용된 이후 렌더링된 프레임 수가 증가함에 따라 높아진다. 다시 말해, 가장 세밀한 밉 레벨 페이지들은 최근에 가장 적게 사용된(LRU, Least Recently Used) 교체 정책에 따라 교체된다.
5.3 Transcode
매우 높은 압축 비율을 가진 가변 비트레이트 압축(variable bit rate compression)은 광디스크가 제공하는 제한된 저장 공간에 매우 크고 고유한 텍스처로 구성된 세계를 저장하기 위해 사용되며, 텍스처 데이터를 광디스크에서 스트리밍할 때 대역폭 요구량을 줄이는 데에도 활용된다. GPU에서는 메모리 대역폭과 메모리 사용량 측면에서 이점이 있는 고정 비트레이트 DXT 압축 텍스처가 사용된다. 디스크에서 새 텍스처 페이지가 스트리밍되거나 캐시에서 가져와질 때, JPEG 유사 포맷이나 HD-Photo / JPEG-XR 포맷에서 DXT 포맷으로 트랜스코딩되어야 한다. 이 트랜스코딩 과정은 상당한 계산 부하를 유발하며, 사용 가능한 적합한 프로세서에 작업을 분산시키는 병렬 작업 처리 시스템을 통해 병렬로 수행된다. 작업 부하 균형을 개선하기 위해, 트랜스코딩이 필요한 각 페이지마다 두 개의 작업이 추가되며, 각 작업은 페이지 데이터의 일부를 트랜스코딩한다. 일반적인 운영 시에는 렌더 프레임당 약 8~16개의 페이지가 트랜스코딩되며, 이로 인해 총 16 ~32개의 작업이 생성된다. 초당 60프레임에서 페이지당 128 x 128 텍셀 크기의 텍스처 16페이지를 트랜스코딩할 경우, 약 15 메가텍셀/초(MegaTexels per second, MT/s)의 처리량이 발생한다. 텍스처 메모리에 직접 접근할 수 있는 시스템에서는 트랜스코딩 작업이 DXT 압축된 텍스처 블록을 비디오 메모리에 바로 쓸 수 있다.
5.4 비동기 업데이트
텍스처 메모리에 직접 접근할 수 있는 시스템에서는, 페이징 시스템이 GPU와 비동기적으로 동작한다. 매 프레임마다 시스템은 추가적인 텍스처 페이지가 필요할지를 판단하고, 재사용될 페이지들은 즉시 언맵(unmap)된다. 이렇게 하면 GPU는 해당 페이지 대신 더 거친 상위(parent) 페이지를 사용하기 시작한다. 페이지의 텍셀은 해당 페이지가 언맵될 때까지 덮어쓰여지지 않으며, 새로운 페이지가 매핑되는 것도 모든 텍셀이 준비된 이후에야 이루어진다.
이 과정은 페이지 테이블과 물리 페이지가 지속적으로 비동기적으로 업데이트되더라도, 가상 텍스처의 일관성이 유지되도록 보장한다. 물론 텍스처 캐시가 텍스처 메모리와 일치하지 않아 불일치(coherency) 문제가 발생할 위험은 존재하지만, 실제로는 텍스처 캐시를 플러시(flush)하거나 무효화(invalidate)하는 연산이 충분히 자주 발생하기 때문에 오류가 관찰되는 경우는 없다.
6. 결과
6.1 주소 변환
가상 주소에서 물리 주소로의 변환 성능은 부록 C에 제시된 프래그먼트 프로그램을 사용하여 여러 플랫폼에서 측정되었다. 이 성능 테스트에서는 해상도 1280 x 720의 전체 화면을 커버하는 100개의 상주 텍스처 페이지를 사용하여, 화면 정렬된 단일 쿼드(quad)를 렌더링한다.
구형 ATI/AMD 하드웨어에서는 가상 텍스처 좌표를 이용해 비등방성(anisotropic) 풋프린트를 계산하고, 명시적인 도함수(derivatives)를 사용하는 텍스처 페치(texture fetch)를 수행한다. 이는 물리 텍스처 좌표에 대해 하드웨어 가속 비등방성 필터링을 사용하면서 도함수를 암묵적으로 계산할 경우 발생하는 눈에 띄는 아티팩트(artifact)를 피하기 위해 필요하다. ATI/AMD 하드웨어에서 암묵적으로 계산된 도함수를 사용할 경우의 성능은 비교를 위해 표 1에 괄호 안에 표시되어 있다.
6.2 페이지 테이블 업데이트
페이지 테이블 업데이트는 부분적인 페이지 테이블 텍스처 업데이트와, 사용 중인 매핑 텍스처들에 단일 텍셀을 업데이트하는 작업으로 구성된다. 매핑 텍스처를 업데이트하는 것은 단순한 단일 텍셀 쓰기 작업에 불과하며, 비용이 크지 않다. 하지만 어떤 가상 페이지를 매핑하느냐에 따라 페이지 테이블 업데이트는 훨씬 더 비용이 많이 들 수 있다.
가상 페이지가 매핑될 때, 해당 가상 페이지 및 그 MIP 레벨에 해당하는 페이지 테이블 텍셀이 먼저 업데이트된다. 그 다음에는, 매핑된 가상 페이지에 대해 더 세밀한 이미지 디테일을 저장하는 더 낮은 MIP 레벨의 페이지 테이블 텍스처에서도, 2의 제곱 크기의 정사각형 영역에 해당하는 텍셀들이 업데이트된다.
예를 들어, 가장 처음에 가장 거친(coarsest) 가상 텍스처 페이지가 매핑될 경우, 페이지 테이블의 전체 MIP 맵 계층에 있는 모든 텍셀들이 동일한 값으로 설정된다. 이후 더 세밀한(finer) 페이지가 매핑될 때는, 전체 텍셀 중 1/4만 업데이트되어야 한다. 이러한 방식으로 더 세밀한 페이지가 매핑될수록 점진적으로 더 적은 수의 텍셀이 업데이트된다.
이러한 업데이트의 성능은 정사각형 형태의 페이지 테이블 텍스처 영역에 기록되는 텍셀 수에 비례하며, 이는 다시 매핑되는 가상 페이지의 MIP 레벨과 관련된다.
직접 메모리 접근(DMA)이 가능한 시스템에서는, 이러한 업데이트 성능이 메모리 쓰기 속도에 의해서만 제한된다. 그러나 비디오 메모리에 대한 접근이 OpenGL이나 DirectX 같은 API를 통해서만 가능한 시스템에서는 페이지 테이블 업데이트 시 상당한 API 오버헤드가 발생한다.
현재의 그래픽 API들은 서브 이미지에 대한 "memset" 연산(일정한 값으로 채우기)을 지원하지 않고, 오직 서브 이미지 데이터 복사(sub-image data copy)만을 지원한다. 따라서 페이지 테이블의 특정 MIP 레벨에 정사각형 영역을 효과적으로 "memset"하기 위해서는, 동일한 텍셀 값을 메인 메모리의 블록에 여러 번 써서 데이터를 먼저 준비한 다음, 이 데이터를 API를 통해 전송하여 비디오 메모리 상의 정사각형 텍스처 영역을 업데이트해야 한다.
6.3 피드백 분석
피드백 분석의 성능은 피드백 버퍼의 크기에 비례한다. 피드백 버퍼가 작을수록 피드백 분석의 성능은 향상되지만, 그만큼 텍스처 데이터를 더 거칠게 샘플링하게 되어 일부 가상 페이지가 즉시 가시한(visible) 것으로 판단되지 않을 수 있다.
하지만 실제로는, 장면이 렌더링되는 해상도보다 10배 이상 작은 크기의 피드백 버퍼를 사용하더라도 시각적으로 눈에 띄는 이상(anomaly)은 거의 발생하지 않는다. 피드백 분석은 GPU에서 구현할 수도 있다. 그러나 일반적으로는 CPU 자원이 충분히 남기 때문에, 예를 들어 IBM Cell SPE나 멀티코어 PC 같은 플랫폼에서는 CPU에서 처리하는 것이 보통이다. 이러한 플랫폼에서는 80x60 픽셀 크기의 피드백 버퍼를 처리하는 데 약 0.5밀리초 정도의 CPU 시간만 소요된다. 이러한 성능은 피드백 버퍼에서 고유한 페이지 목록을 추출하기 위해 구성된 쿼드 트리(quad-tree)에서 각 페이지의 상위(parent) 노드를 빠르게 찾을 수 있도록 해시 테이블(hash table)을 사용하는 방식으로 달성된다.
6.4 저장 공간
이 시스템에서 사용되는 텍스처 페이지는 128 x 128 텍셀 크기로, 4텍셀의 인셋(inset) 경계(border)를 포함하고 있으며, 실제 유효 페이로드는 120 x 120 텍셀이다. 가용 비디오 메모리를 최적화하여 사용하기 위해, 페이로드가 아닌 경계를 포함한 전체 텍스처 페이지 크기를 2의 거듭제곱(power of two)으로 설정한다.
일부 하드웨어에서는 물리 텍스처의 최대 크기가 2의 거듭제곱(예: 4096 x 4096)으로 제한되기 때문에, 텍스처 페이지 크기를 128 x 128과 같은 2의 거듭제곱으로 맞추면 물리 텍스처 공간을 낭비 없이 정확히 분할하여 페이지를 배치할 수 있다.
물리 텍스처 크기는 일반적으로 4096 x 4096 텍셀로, 이는 32 x 32개의 텍스처 페이지와 같다. 비디오 메모리에 DXT 압축 방식으로 저장될 때, 10개 채널을 저장하는 세 개의 4096 x 4096 물리 텍스처는 총 40MB의 용량을 차지한다.
신형 하드웨어에서는 16k x 16k 텍셀 크기의 더 큰 물리 텍스처를 지원하지만, 구형 하드웨어는 4096 x 4096 텍셀보다 큰 텍스처를 지원하지 않을 수 있다. 구형 하드웨어에서 물리 페이지 수를 늘리기 위해서는 3D 텍스처를 사용할 수 있다. 이 방법은 가상-물리 변환을 약간 더 복잡하게 만들지만, 많은 하드웨어가 3D 텍스처에 대해 이방성 필터링(anisotropic filtering)을 지원하지 않아 이 방법은 매력적이지 않는다.
대신 큐브 맵 텍스처를 사용할 수도 있지만, 이 경우 주소 변환이 훨씬 더 복잡해지는 단점이 있다.
물리 페이지 수를 늘리는 가장 쉬운 방법은 여러 개의 물리 텍스처 세트 형태로 별도의 물리 페이지 풀을 만드는 것이다. 하지만 이 방법은 서로 다른 지오메트리가 각각 다른 풀에서 페이지를 할당받아야 한다는 점을 요구하며, 모든 렌더링된 장면에서 지오메트리 분포가 균등하지 않을 수 있어서 모든 풀이 고르게 채워지지 않을 수도 있다.
물리 페이지 좌표를 바이트 단위로 저장하는 가상-물리 변환 방식은 최대 256 x 256개의 물리 페이지를 지원할 수 있으며, 텍스처 페이지 크기가 128 x 128 텍셀일 때 이는 32k x 32k 텍셀 크기의 물리 텍스처에 해당한다.
반면, 5:6:5 페이지 테이블을 사용하는 가상-물리 변환은 최대 32 x 32개의 물리 페이지만 지원할 수 있으며, 이 경우 텍스처 페이지 크기가 128 x 128 텍셀일 때 물리 텍스처 크기는 4096 x 4096이 된다.
반면, Virtual Texture는 최대 240k x 240k 텍셀(여기서 240k = 2048 * 페이로드 크기) 크기까지 가능하며, 이 경우 2바이트 또는 5:6:5 페이지 테이블 텍스처가 약 10.66MB의 메모리를 사용한다.
최대 크기 대신 보통은 페이지 테이블 텍스처 메모리를 줄이기 위해 120k x 120k 크기의 Virtual Texture가 사용된다. 이 경우 페이지 테이블 텍스처는 약 2.66MB의 메모리를 차지한다.
컴퓨터 게임 RAGE에서는 대부분의 환경이 모든 정적 지오메트리에 대해 하나의 120k x 120k Virtual Texture를 사용하며, 동적 오브젝트에 대해서도 또 다른 120k x 120k Virtual Texture를 사용한다. 매우 큰 야외 환경에서는 정적 지오메트리에 대해 여러 개의 Virtual Texture를 사용하기도 한다. 각 Virtual Texture는 고유한 페이지 테이블을 가지고 있지만, 여러 Virtual Texture가 동일한 Physical page pool을 공유하거나 별도의 Physical page pool에 매핑될 수도 있다.
채널당 12개(그중 2개는 미사용)인 텍셀로 완전히 채워진 압축되지 않은 120k x 120k 가상 텍스처는, 테두리(border)를 제외하면 약 225GB의 저장 공간이 필요하며, 테두리를 포함하면 약 256GB의 저장 공간이 필요하다.
DXT 포맷으로 압축된 경우에도 이러한 가상 텍스처는 여전히 약 53GB를 차지한다.
압축되지 않은 12채널(그중 2채널은 미사용) 120k x 120k Virtual Texture는 테두리 없이 약 225GB의 저장 공간이 필요하며, 테두리를 포함하면 약 256GB가 필요하다. DXT 포맷으로 압축된 경우에도 이러한 Virtual Texture는 약 53GB를 차지한다.
컴퓨터 게임 RAGE의 대부분 정적 환경에서는 120k x 120k Virtual Texture가 완전히 채워져 있지 않다. 가장 세밀한 MIP 텍스처 페이지의 많은 부분은 결코 보이지 않아 저장할 필요가 없다. 또한, 고해상도로 전혀 보이지 않는 페이지의 일부는 흐리게 처리되어 가변 비트레이트 압축률을 크게 향상시킬 수 있다.
표 2에는 컴퓨터 게임 RAGE의 여러 환경에서 정적 지오메트리에 사용되는 가상 텍스처 크기가 나타나 있다.
6.5 Transcode
텍스처 페이지의 트랜스코딩은 상당한 계산 부하를 요구하며, 이를 위해 병렬 작업 처리 시스템을 통해 사용 가능한 적합한 프로세서에 작업을 분산시켜 수행된다. 최신 그래픽 하드웨어에서는 텍스처 페이지 트랜스코딩을 GPU에서 실행하도록 구현할 수 있다. CPU 코어 수가 적은 시스템에서는 GPU에 상당한 계산 부하를 분산시켜 CPU 코어를 다른 용도로 활용할 수 있게 한다. 하지만 구형 그래픽 하드웨어는 트랜스코딩을 구현할 수 있는 기능이 부족하거나, GPU가 이미 렌더링 작업으로 가득 차 추가 계산 부하를 처리할 여유가 없을 수 있다. 이러한 시스템에서는 트랜스코딩을 Cell PPE와 Cell SPE의 하드웨어 스레드 같은 사용 가능한 CPU 코어에서 실행하도록 구현한다. 표 3은 여러 프로세서에서의 DXT 압축 성능을 메가텍셀(MegaTexels) 단위로 초당 처리량(MT/s)으로 보여준다.
다음 그래프들은 여러 프로세서에서 다양한 압축 비율에 따른 가변 비트레이트(variable bit rate) 압축 해제 성능을 메가텍셀(MegaTexels) 단위 초당 처리량(MT/s)으로 나타낸 것이다.
HD-Photo 압축 해제가 JPEG 유사 형식(JPEG-like format)보다 더 많은 연산 비용이 드는 것은 명확하다. 하지만 HD-Photo는 일반적으로 JPEG 유사 데이터 크기의 거의 절반 수준으로 텍스처 데이터를 압축할 수 있으며, 이 과정에서 동일한 화질을 유지하고 보통은 압축으로 인한 불쾌한 왜곡(artifact)을 줄이거나 제거한다.
따라서 HD-Photo와 JPEG 유사 형식 간의 성능 비교 시에는 서로 다른 압축 비율을 고려해야 한다. 예를 들어, 20:1 압축 비율의 JPEG 유사 데이터와 40:1 압축 비율의 HD-Photo 데이터를 비교하는 것이 합리적이다.
또한 JPEG 유사 압축에서는 RGB와 YCoCg 데이터에 대해 4:2:0 서브샘플링(subsampling)이 사용되기 때문에, JPEG 유사 디코더는 HD-Photo 디코더가 처리하는 4:4:4 샘플링 데이터보다 절반 정도의 데이터만 처리한다.
6.6 Visuals
설명된 솔루션을 사용하는 가상 텍스처 시스템은 컴퓨터 게임 RAGE에 성공적으로 구현되어 활용되고 있다. 이 게임은 Microsoft Windows PC, Apple Macintosh PC, Xbox 360, PlayStation 3와 같은 다양한 플랫폼에서 다양한 그래픽 하드웨어를 사용하여 높은 프레임률(60 FPS)로 원활하게 실행된다. 아래는 RAGE 게임의 야외 환경 장면 몇 컷이다.
7. 결론
가상 텍스처는 다른 형태의 가상 메모리와는 몇 가지 중요한 차이점이 있다. 첫째, 약간 흐릿한 데이터로 대체하여 실행을 멈추지 않고도 계속 진행할 수 있다는 점이고, 둘째, 대부분의 용도에서 손실 압축된 데이터도 충분히 허용된다는 점이다. 소프트웨어 기반 가상 텍스처 구현은 이러한 가상 텍스처와 다른 가상 메모리 간의 핵심 차이점을 활용하여 성능을 유지하고 메모리 요구량을 줄이는 대신 품질을 일부 희생하는 방식을 취한다.
특별한 하드웨어 지원 없이 가상 텍스처를 구현하는 것은 도전적인 작업이며, 많은 세부 사항을 고려해야 하고 결국 성능, 메모리 요구량, 품질 간 적절한 균형점을 찾는 문제로 귀결된다. 여기서 제시된 해결책들은 매우 큰 가상 텍스처를 높은 성능으로 구현하면서 품질 저하는 최소화하고, 메모리 사용량도 최소로 유지할 수 있도록 해 준다.
이러한 솔루션을 적용한 가상 텍스처 시스템은 컴퓨터 게임 RAGE에 성공적으로 구현되어, Microsoft Windows PC, Apple Macintosh PC, Xbox 360, PlayStation 3와 같은 다양한 플랫폼의 여러 그래픽 하드웨어에서 구동되고 있다.
Future Directions
텍스처 피드백에 대한 반응형 시스템은 가상 텍스처 시스템이 본질적으로 지연(latency)에 강하기 때문에 효과적이다. 하지만, 별도의 피드백 렌더링 패스는 비용이 발생하므로 일반 렌더링 패스와 결합하는 것이 바람직하다. 이 두 패스를 결합할 때는, 피드백이 적절히 깊이 테스트(depth test)되어야 한다. 그래야 결국 보이지 않는 텍스처 페이지 요청으로 인해 가상 텍스처 파이프라인에 불필요한 부하가 걸리는 것을 방지할 수 있다.
렌더링 파이프라인이 별도의 깊이 전용 패스(depth-only pass)를 구현한다면, 이 깊이 패스에서 피드백을 출력하는 방안을 고려해 볼 만하다. 많은 플랫폼에서 깊이 전용 패스는 깊이 쓰기가 두 배 빠르다는 장점이 있고, 보통 이 렌더링 패스는 지오메트리(버텍스) 처리 능력에 의해 제한된다.
깊이 패스에서 피드백을 출력하면, 깊이 쓰기가 더 이상 두 배 속도로 처리되지 않고, 피드백 계산을 위한 추가 프래그먼트 비용이 발생하여 렌더링 패스가 프래그먼트 처리 능력에 제한될 수 있다. 하지만, 렌더링되는 지오메트리 양과 특정 GPU의 성능 특성에 따라 이 방식은 긍정적인 트레이드오프가 될 수 있다. 그 이유는 피드백 버퍼가 작아서 별도의 피드백 패스는 거의 항상 지오메트리(버텍스) 처리 능력에 제한되기 때문이다.
또한, 다중 렌더 타겟(MRT)을 사용할 경우 깊이, 컬러, 피드백을 한 번의 패스에서 모두 렌더링할 수 있다. 이 방식은 피드백과 페이지 테이블 조회 모두에 대해 비등방성 LOD(Anisotropic Level of Detail) 계산을 사용할 수 있다는 추가적인 장점도 제공한다.
텍스처 필터링은 현재와 미래의 프로그래머블 그래픽 하드웨어에서도 고정 함수(fixed function) 하드웨어로 구현되는 기능이다. 소프트웨어(예: 프래그먼트 프로그램)만으로 텍스처 필터링을 완전히 처리하는 것은 매우 높은 비용이 들기 때문이다.
특별한 그래픽 하드웨어 지원이 없는 가상 텍스처 시스템의 불행한 복잡성 중 하나는, 텍스처 유닛이 실제 텍스처 페이지를 인식하지 못해 페이지 경계를 넘는 필터링을 수행할 수 없다는 점이다. 그러나 만약 가상 주소를 물리 주소로 변환하는 과정이 하드웨어에서 구현된다면, 필요한 각 텍셀(texel)에 대해 주소 변환을 수행하여 올바른 텍스처 필터링을 하드웨어에서 구현할 수 있다.
즉, 하드웨어 구현에서는 트리리니어(tri-linear) 필터링으로 텍스처를 패치할 때 8번의 가상-물리 주소 변환이 필요하며, 이 경우 가장 가까운 상위 mip 레벨의 페이지 코너에 위치한 텍스처는 최대 8개의 서로 다른 텍스처 페이지를 참조할 수 있다. 또한, 비등방성(Anisotropic) 텍스처 패치의 경우에는 이보다 더 많은 가상-물리 주소 변환이 필요할 수 있다.
일반적인 가상 메모리 시스템이 이미 하드웨어에서 구현되어 있다면, 이를 활용해 가상 텍스처 시스템도 하드웨어로 구현하는 것이 바람직하다. 이 경우, 가상 메모리 페이지를 텍스처 페이지 저장에 사용하고, 가상 메모리 페이지 테이블을 텍스처 데이터의 가상-물리 주소 변환에 활용할 수 있다.
하지만 이 방식에는 다음과 같은 복잡한 문제가 있다. 일반 가상 메모리 시스템은 mip 계층 내 텍스처 페이지 간의 관계를 알지 못하기 때문에, 더 세밀한 mip 레벨 페이지가 아직 준비되지 않은 경우에 더 거친(상위) mip 페이지로 자동으로 대체하는 기능이 없다.
예를 들어, 더 세밀한 mip 페이지가 없을 때, 가상 메모리 시스템은 페이지 폴트(page fault)를 반환하고 텍스처 페치를 더 높은 최소 LOD 클램프(minimum LOD clamp)로 다시 시도할 수 있다. 그러나 이 시도도 실패할 수 있으며, 여러 번 재시도를 해야 하는데 이는 성능 저하를 유발한다.
다른 해결책으로는, 가상 메모리 시스템의 페이지 테이블에 추가 정보를 저장하여, 가상-물리 주소 변환 시 더 세밀한 mip 페이지가 없으면 자동으로 상위 mip 페이지로 대체하는 방법이 있다. 하지만 이 방법은 페이지 테이블 크기를 크게 증가시키며, 텍스처 이외의 데이터도 페이지 테이블을 공유하는 경우에는 이 정보가 무의미해지고 낭비된다.
추가 정보를 페이지 테이블에 저장하는 대신, 각 가상 텍스처 페이지에 대해 물리 메모리에 존재하는 최소 LOD를 저장하는 "min LOD" 텍스처를 유지하는 방법도 있다.
이 "min LOD" 텍스처는 가상 메모리 시스템의 페이지 테이블과 완벽하게 동기화되어야 하며, 이를 통해 페이지 폴트를 피할 수 있는 실제 가상 텍스처 조회 시 클램프할 LOD 값을 얻을 수 있다.
하지만, 삼선형 필터링(tri-linear filtering)이나 특히 이방성 필터링(anisotropic filtering)을 사용하는 가상 텍스처 조회는 여러 mip 레벨의 여러 페이지 경계를 넘나들기 때문에, "min LOD" 텍스처는 뒤따르는 가상 텍스처 조회의 footprint(샘플링 범위)에 맞춰 최대값 필터(maximum filter)로 샘플링되어야 한다.
이 때문에 하드웨어에서 "최대값 텍스처 필터"가 구현되어 있어야 하고, 가상 텍스처 조회 footprint로부터 "min LOD" 텍스처의 샘플 footprint를 빠르게 계산하는 방법도 필요하다.
"min LOD" 텍스처는 LOD 스내핑(LOD snapping)이나 텍스처 디테일의 갑작스러운 '팝핑'(popping) 현상을 완화하기 위해서도 활용할 수 있다.
즉, 페이지가 필요해진 시점과 해당 페이지의 데이터가 실제로 준비되는 시점 사이에 지연(latency)이 있더라도, 이 "min LOD" 텍스처의 텍셀 값을 점진적으로 조절하여 새로운 페이지를 부드럽게 블렌딩함으로써 자연스러운 전환 효과를 낼 수 있다.
이 방법은 시각적 충격 없이 디테일이 점차 개선되는 모습을 구현하는 데 매우 효과적이다.
'Graphics , Rendering' 카테고리의 다른 글
| ASTC Texture Format (2) | 2025.06.29 |
|---|---|
| 디퍼드 렌더링, 그리고 포워드 렌더링과 결합하기 (1) | 2023.09.16 |
| 06. BRDF 구현하기(Implementing BRDF) (0) | 2019.11.19 |
| 선형의 중요성 (The Importance of being Linear) (1) | 2018.11.24 |
| Piecewise Power Curve를 이용한 Filmic Tonemapping (0) | 2018.11.09 |
