[번역] Tiled Forward Shading

개인 공부용으로 번역한 거라 잘못 번역된 내용이 있을 수 있습니다.

또한 원작자의 동의 없이 올려서 언제든 글이 내려갈 수 있습니다.

출처 : GPU Pro 4

 

Tiled Forward Shading
Markus Billeter, Ola Olsson, and Ulf Assarsson

 

4.1 Introduction

우리는 이번 챕터에서 tiled forward shading 알고리즘을 알아볼 것입니다.  Tiled forward shading은 tiled deferred shading의 확장이나 수정한 것입니다. [Balestra and Engstad 08, Swoboda 09,Andersson 09, Lauritzen 10, Olsson and Assarsson 11], 그리고 그것은 전통적인 디퍼드 쉐이딩 방법들을 향상시킵니다. [Hargreaves and Harris 04,Engel 09]

디퍼드 쉐이딩은 2개의 주요 특성을 가집니다: 지오메트리 관리에서 라이팅과 쉐이딩을 분리 그리고 라이팅 계산 수행 수의 최소화 [Hargreaves and Harris 04]. 전자는 더 효율적인 지오메트리 제출과 관리 [Shishkovtsov 05] 그리고 쉐이더와 쉐이더 리소스 관리를 단순화 합니다. 그러나 후자는 현대 GPU에서 문제가 더 적어지고 있습니다. 이것은 쉐이더에서 복잡한 흐름제어와 Uniform buffers 와 GPU memory에 더 복잡한 데이터 구조를 지원하는 것입니다.

전통적인 포워드 파이프라인은 보통 오브젝트들을 하나씩 그립니다. 그리고 각 레스터라이즈 되어진 프래그먼트에 대해 각각의 라이트를 고려합니다. 디퍼드 쉐이딩에서는, 지오메트리를 스크린사이즈의 G-Buffer에 렌더링합니다. [Saito and Takahashi 90], G-Buffer는 각 픽셀에 대한 쉐이딩 데이터를 포함합니다, normal 그리고 depth/position 같은 것들. 그리고나서, 분리된 패스에서, 라이팅과 쉐이딩이 ,예를들면, 라이트 소스들이 하나씩 그러지면서 계산되어집니다. (각각의 라이트 소스는 라이트의 영향 영역을 감싸는 바운드 볼륨으로 표현되어짐). 이 패스에서 각각의 생성되어진 프래그먼트에 대해, 해당 픽셀에 대한 데이터는 G-Buffer 로부터 얻어집니다, 쉐이딩이 계산되어집니다, 그리고 결과는 Output buffer로 Blend 되어집니다. 라이팅 계산이 수행되는 수는 볼수있는 샘플 당 라이트 당 최적에 아주 가깝습니다 (라이트 소소를 표현하기 위해 사용되어진 바운드 볼륨에 다소 의존적).

디퍼드 쉐이딩은 라이팅 계산에 필요한 계산량을 줄이는데 성공했습니다, 그러나 Memory 요구사항(Gbuffer는 한개의 컬러버퍼 보다 더 크다)과 더 높은 메모리 대역폭 사용량의 비용이 증가되었습니다. Tiled deferred shading은 후자를 (Section 4.2) 수정했습니다, 그러나 여전히 큰 G-Buffer가 요구되어집니다.

 

 

 

그림 4.1. 우리는 이 글에서 Tiled forward shading을 알아봅니다. (a) Tiled deferred shading은 일반적인 경우(투명도 없음, MSAA 없음) 약 25% 정도 tiled forward shading 보다 더 뛰어난 반면에 (b) Tiled forward shading은 투명도를 가능하게 합니다. 추가적으로, (c) 우리는 하드웨어에서 지원되는 MSAA를 사용할 수 있습니다, 이러한 것은 디퍼드 쉐이딩에서 모방하는 경우 많은 양의 메모리가 요구됩니다. 게다가, 4x MSAA에서 riled forward shading 은  같은 품질의  디퍼드에서 1.5에서 2 배 정도 더 뛰어납니다. 이미지는 8x MSAA를 보여줍니다, 그것은 디퍼드 렌더링의 메모리 제약 때문에 모방하는 것이 불가능합니다. (d) 마지막으로 우리는 커스텀 쉐이더에 대해서 토론합니다. 표준 포워드 렌더링에서 처럼, 쉐이더들은 지오메트리 청크들에 소속되어질 수 있습니다. 장면은 1024 개의 랜덤하게 배치된 라이트를 포함하며, 그리고 데모는  NVIDIA GTX480 GPU 에서의 실행입니다.

 

 

Tiled forward shading 은 (Tiled) deferred shading의 주요 장점 중 하나를 조합하길 시도합니다. 즉, 조명 계산량 감소 됨과 동시에 포워드 렌더링의 장점. 메모리 요구사항을 줄이는 것 외에도 (포워드 렌더링은 큰 G-Buffer가 필요없습니다.), 반투명 역시 가능하게 해줍니다. [Kircher and Lawrance 09,Enderton et al. 10] (Section 4.5), 멀티샘플링 구조를 가능하게 합니다. [Swoboda 09, Lauritzen 10] (Section 4.6), 그리고 다른 쉐이딩 모델을 지원해야만 하는 경우에 (Section 4.7) Ubershader 들의 사용을 강제하지 않습니다. 그림 4.1에서 이런 다른 측면들의 데모를 보세요.

 

4.2 Recap: Forward, Deferred, and Tiled Shading

포워드, 디퍼드 그리고 Tiled Shading 용어는 이 챕터에서 꽤 자주 등장할 것입니다. 그러므로 우리가 의미하는 것을 무엇인지 정의하게 합니다. 이 용어들은 때때로 커뮤티에서 약간 다르게 사용되어지기 때문입니다. 우리가 여기에서 보고있는 정의들은 [Olsson and Assarsson 11] 에서 사용되어진 것과 일치합니다.

포워드 쉐이딩에서, 우리는 지오메트리가 레스터라이즈 되어질때 라이팅과 쉐이딩 계산이 같은 패스에서 수행되어지는 렌더링 프로세스를 나타냅니다. 이것은 버택스 쉐이더의 표준 설정 구성과 일치합니다. 그것은 지오메트리를 변환하고 프래그먼트 쉐이더가 각각의 레스터라이즈 된 프래그먼트에 대해서 최종 컬러값을 계산하는 것입니다.

디퍼드 쉐이딩은 이 프로세스를 2개로 분리합니다. 첫째로, 지오메트리가 레스터라이즈 되어집니다, 그러나, 포워드 쉐이딩과 대조적으로, 지오메트리 속성을 지오메트리 버퍼 세트(G-Buffers)에 출력합니다. 모든 지오메트리가 이 방식으로 처리되어진 후에, 추가 패스가 라이팅을 계산하거나 전체 쉐이딩이 G-Buffers에 저장되어진 데이터를 사용하여 수행되어집니다.

아주 간단한 형태로, 두번째 패스는(라이팅 패스) 아마 아래와 같이 보일 것입니다.

for each G-buffer sample 
{
	sample_attr = load attributes from G-buffer
	for each light 
	{
		color += shade (sample_attr , light )
	}
	output pixel color;
}

때때로, 반복문의 순서가 뒤바뀌기도 합니다. Section 4.1에서 설명된 디퍼드 알고리즘은 이것의 한 예제입니다.

위에서 라이트 패스는 O(N lights * N samples) 라이트 계산을 요구합니다.

만약 우리가 어떤 라이트가 어떤 샘플에 영향을 주는지 안다면, 우리는 이 숫자를 상당히 줄일 수 있을 것입니다. [Trebilco 09].

Tiled deferred shading은 샘플들을 N x N samples의 타일로 분할함으로써 이것을 합니다. (우리는 N = 32 인 경우 특히 성공적이었다, 그러나 이것은 특정 하드웨어 그리고 어플리케이션에 의존적입니다.) 라이트들은 이 타일들에 할당되어집니다. 우리는 아마 선택적으로 최소와 최대의 각각 타일의 Z-Bound를 계산할 것입니다, 그리고 그것은 우리가 각각의 타일에 영향을 주는 라이트의 수를 더 줄이게 해줍니다. (이것에 대한 추가 토론은 Section 4.4).

Tiled deferred shading의 [Olsson and Assarsson 11] 이점은 아래와 같습니다:

• 각각의 빛을 받은 샘플들에 대해 G-Buffer는 단 한번의 읽기만 함.
• 프레임 버퍼는 한번만 쓰여진다.
• 렌더링 방정식의 공통 식은 인수분해 되어질 수 있고 각의 라이트 당 재계산되는 대신 한번만 계산되어질 수 있다.
• 각 타일 범위에서 작업이 일관되어진다; 즉, 타일안에 각 샘플은 같은 양의 작업을 요구한다(동일한 라이트에 관해 반복함), 그것은 SIMD 같은 아키텍쳐에서 효율적인 구현을 가능하게 한다. (그렇지 않다면, 쉐이더 코드는 많은 분기를 포함한다.)

Tile deferred shading (그리고 대 부분의 디퍼드 테크닉들)이 가치있도록, 대부분의 라이트들은 범위제한을 가지고 있습니다. 만약 모든 라이트들이 잠재적으로 모든 장면에 영향을 준다면, Tiling 하는 것은 명백히 이득이 없습니다. (그림 4.2(a)).

Tiled deferred shading은 Tiled shading으로 일반화 되어질 수 있습니다, 그리고 그것은 Deferred와 forward 변경을 둘다 포함합니다. 기본 tiled shading 알고리즘은 아래와 같습니다:

1. 스크린을 타일로 세분한다.
2. 선택: 각 타일의 최소와 최대 Z-bound들을 찾는다.
3. 각 타일에 라이트를 할당한다.
4. 각 샘플에 대해: 모현재 샘플의 타일에 영향을 주는 모든 라이트를 처리한다.

Step 1은 기본적으로 무료입니다; 만약 우리가 정규 N x N 타일을 사용한다면, 세분화는 암시적입니다. 각 타일의 최소와 최대 Z-bound를 찾는 것은 선택입니다. (Step 2). 예를들어, low depth complexity의 장면에서 탑다운 뷰는 Z 방향에서 추가적인 라이트들의 컬링을 허용하지 않을 것입니다. 다른 케이스는, 그러나, 딱맞는 타일의 Z-bound로 부터의 이득을 얻을 수 있을 것이다, 더 적은 라이트들이 타일에 영향을 주기 때문입니다 (그림 4.2(b)).

 

Tiled defered shading에서, Step 4의 샘플들은 G-Buffer로 부터 얻어집니다. Tiled forward shading에서는, 샘플들이 레스터라이제이션 과정에서 생성되어집니다. 우리는 이 글의 남은 부분에서 후자를 알아볼 것입니다.
우리는 최근 Tiled shading의 확장을 제시했습니다, Clustered shading이라고 불립니다. [Olsson et al. 12b]. Clustered shading은 tiled shading의 확장입니다. 그것은 복잡한 라이트와 지오메트리 구성을 퍼포먼스 측면에서 더욱 견고하게 처리합니다. 그러나, Tiled forward shading은 구현이 아주 많이 간단합니다, 그리고 더 많은 하드웨어들에서 작동합니다. 우리는 Clustered shading 확장에 대해 토론할 것입니다. 그리고 어떻게 그것이 Section 4.8에서 제시된 Tiled forward shading과 상호작용하는지 이야기 할것 입니다.

 

 

그림 4.2. (a) 너무 큰 라이트를 가지는 경우 효과(아래 이미지)" 타일링으로 부터 얻는게 없습니다, 모든 광원들이 모든 타일에 영향을 주기 때문에(노란색으로 그려짐), 위의 그림과 비교했을때, 평균적으로 타일당 하나의 라이트만 있습니다. (b). Top-down 과 first-person 뷰의 비교. Top-down 뷰(위)에서, 모든 라이트는 지면에 근접해있습니다, 그리고 그것은 작은 Z방향으로 작은 변화만 있습니다. 이 경우, 최소 그리고 최대 Z-bound 계산으로 부터 많은 것을 얻을 수 없습니다. first-person 뷰(아래)에서는, 바운드가 도움이 됩니다. (이미지에서 3개의 라이트들이 타일에 전혀 영향을 주지 않음)

 

 

 

4.3 Tiled Forward Shading: Why?

Tiled deferred shading을 포함한 디퍼드 기술들의 주요 강점은 over-draw 때문에 발생하는 over-shading 이 제거되는 것입니다. 그러나, 대부분의 디퍼드 테크닉은 포워드 렌더링과 비교했을때 아래의 약점으로 부터 고통받습니다:

• 투명도/블랜딩이 까다롭습니다, 전통적인 G-buffer들은 버퍼내의 각 위치에 단일 샘플의 저장공간만 허용하기 때문입니다.
• 메모리 저장공간과 대역폭 요구사항이 더 높고 MSAA 그리고 연관된 기술과 함께 하면 더 나빠집니다 (Section 4.6).

반면에 포워드 렌더링은 이 부분을 잘 지원합니다.

• 알파 블랜딩을 통한 투명도
• 하드웨어 기능을 통한 MSAA와 관련 기술들 (더 낮은 메모리 저장공간이 요구됨)

게다가, 포워드 렌더링은 다른 종류의 지오메트리를 위해 서로 다른 쉐이더들과 머터리얼을 간단히 지원할 수 있습니다. 디퍼드 기술들은 보통 Ubershader 로 물러나야 할 것입니다. (혹은 여러 쉐이딩 패스를 처리해야함).

Tiled forward shading의 특별한 장점중 하나는 GPU 하드웨어의 낮은 요구사항입니다. compute shader 그리고 다른 (관련된) 최신 하드웨어 기능 없이 Tiled forward renderer 를 구할 수 있게 해줍니다. 실제로, 프래그먼트 쉐이더에서 dependent texture lookups(역주 : 텍스쳐에서 Texture coordination을 읽어서, 두번째 텍스쳐에서 Texture lookup 이 가능한지 여부, Lookup 할 텍스쳐의 UV가 Shader 컴파일 타임이 결정되지 않는 것이 가능한가 여부 - 참고) 를 지원하는 어떤 하드웨어에서 Tiled forward renderer를 구현할 수 있습니다. 반면에, 만약 compute shader가 가능하다면, 우리는 이것을 하는 동안 이득을 얻을 수 있습니다, 말하자면, 라이트 할당 같은 곳에서 (Section 4.4).

아래의 섹션들에서, 우리는 먼저 tiled forward shading renderer를 제시할 것입니다. 그리고 거기에 우리는 투명도, MSAA 그리고 최종적으로 서로 다른 오브젝트들에 대해 서로 다른 쉐이더를 갖는 것을 실험할 것입니다. 우리는 퍼포먼스와 리소스 소모량을 Tiled deferred shading renderer 와 비교할 것입니다. 그리고 어느 부분에서 Tiled forward renderer 가 좋은지 보여줄 것입니다.

 

4.4 Basic Tiled Forward Shading

우리는 Section 4.2에서 모든 Tiled shading 변형에 대한 기본 알고리즘을 나열했습니다. 명확히 하기 위해, 포워드 변형에 대한 특정 부분을 포함하여 여기서 반복됩니다.

1. 세분화된 스크린을 타일들로
2. 선택: pre-Z 패스 - 지오메트리를 그리고 표준 Z-buffer의 각 샘플에 대한 깊이 값을 저장.
3. 선택: 각 타일에 대해 최소 그리고/혹은 최대 Z-bound를 찾는다.
4. 라이트를 각 타일에 할당
5. 지오메트리를 그리고 각각 생성되어진 프래그먼트에 쉐이딩 계산을 함.

스크린의 세분화. 우리는 정규 N x N 픽셀의 타일들을 사용합니다. (즉, N = 32). 아주 많은 타일을 만드는 것은 더 나쁜 라이트 할당을 만듭니다; 각 타일은 타일의 작은 샘플들의 부분집합에 영향을 미치는 더 많은 광원으로 부터 영향을 받을 것입니다. 아주 작은 타일을 만드는 것은 라이트 할당을 더 비싸고 메모리 공간 요구사항을 증가시킵니다 - 특히 타일들이 충분히 작을때 많은 인접 타일들이 같은 광원들로 부터 영향을 받는 것으로 발견되어집니다.

 

선택 pre-Z 패스. 선택 pre-Z 패스는 2가지 방법으로 도울 수 있습니다. 첫째로, 다음 스탭에서 각 타일에 대해 Z-bound를 찾기를 원한다면 이것이 요구됩니다. 둘째로, 최종 렌더링 패스에서 Early-Z 테스트와 비슷한 하드웨어 기능을 통해 쉐이딩 되어야 하는 샘플의 수를 감소시킬 수 있습니다.

Pre-Z 패스는 불투명 지오메트리만 포함해야 합니다. 투명 지오메트리는 Section 4.5에서 다뤄질 것입니다.

비록 우리의 테스트에서 pre-Z 패스가 장면과 뷰에 종속적이지만 우리는 이것을 추가하는 것이 퍼포먼스를 상당히 향상시킨다는 것을 발견했습니다. 예를 들어, 그림 4.1(a)에 대해, 렌더링 시간은 22.4 ms(위 그림) 그리고 37.0 ms (아래 이미지) 에서 15.6 ms 그리고 18.7 ms 로 각각 줄었습니다.

 

선택 최소 혹은 최대 Z-Bound. 만약 깊이 버퍼가 있다면, 즉, 위에서 설명한 pre-Z 패스, 우리는 이 정보를 Z 방향(깊이) 각 타일의 크기를 찾는 사용할 수 있습니다. 이것은 더 작은 타일당 바운드 볼륨을 수행하면서, 타일에 영향을 주는 라이트를 수를 라이트 할당과정에서 줄여줍니다.

어플리케이션에 따라서, 최소 혹은 최대 바운드만 찾는 것만으로 충분할 수 있습니다 (만약 바운드가필요한 경우). 다시, 투명도(Section 4.5)는 다양한 멀티 샘플링 구조를 할때 (Section 4.6) 처럼 이것과 상호작용 합니다,

위의 pre-Z 테스트와 함께, 최소 혹은 최대 제거는 그림 4.1(a)의 관점에서 더욱더 큰 향상을 이룹니다. pre-Z와 최소 혹은 최대 제거와 함께한 렌더링 시간은 각각 10.9ms (위) 그리고 13.8 (아래) 입니다 - 그것은 Tiled deferred shading (8.5 ms 그리고 10.9 ms)와 비교가능합니다. 제거 그자체는 프래그먼트 쉐이더에서 반복문을 사용하여 구현되어집니다(간단함을 위해) 그리고 현재는 약 0.75 ms (1920 x 1080 해상도)를 얻습니다.

 

라이트 할당. 다음으로, 우리는 라이트를 타일에 할당해야합니다. 기본적으로 우리는 효율적으로 타일에 있는 샘플들에 영향을 주는 라이트들을 찾길 원합니다. 이것은 몇몇 선택 그리고 고려사항들을 요구합니다.

Tile shading 에서, 타일의 수가 상대적으로 작은 곳 (예를들어, 1920 x 1080 에 32 x 32 타일은 약 2040(역주 : 1920/32 * 1080/32)타일들을 산출한다.), 이것은 CPU에서 할당하는 것이 가능하다. 만약 라이트의 수가 상대적으로 적다면 이것은 특별히 맞습니다. (즉, 수 천개 정도). CPU에서, 간단한 구현은 각각의 광원에 대해 스크린스페이스에 정렬된 바운드 박스 (AABB)를 찾는 것입니다. 그리고 AABB의 2D 영역에 포함되어진 모든 타일을 대상으로 반복합니다. 만약 우리가 계산되어진 타일에 대한 최소 그리고 최대 깊이 값이 있다면, 우리는 Z 방향에서 타일 바깥에 있는 라이트를 버리기 위한 추가 테스트를 할 수 있습니다.

GPU에서는, 간단한 brute-force 변형이 적당한 라이트의 양에 대해 작동합니다. (10,000개 정도의 라이트 까지). Brute-force 변형에서, 각 타일은 모든 라이트 소스에 대해서 확인되어집니다. 만약 각 타일이 그것 자신의 스레드 그룹을 얻는다면, 구현은 꽤 간단하고 상대적으로 잘 작동합니다. 명백히, brute-force 알고리즘은 확장이 잘되지 않습니다. 우리의 Clustered shading 구현에서 [Olsson et al. 12b], 우리는 간단한 라이트 계층 (BVH)을 매프레임 만듭니다. 그리고 타일들(clusters)을 이 계층에 대해서 테스트 합니다. 우리는 이 접근이 100만개의 라이트 까지 리얼타임에서 확장가능하다는 것을 보여줍니다. 같은 접근을 tiled shading 에 또한 적용 가능합니다.

 

렌더링 그리고 쉐이딩. 마지막 스탭은 모든 지오메트리를 렌더링 하는 것입니다. 이것을 위한 파이프라인은 표준 포워드 렌더링 파이프라인과 거의 비슷하게 보입니다; 서로다른 쉐이더 그리고 연관된 리소스들은 서로다른 지오메트리 청크에 붙여질 것입니다. 이 스테이지에 프래그먼트 쉐이더외에 다른 변화는 없습니다.

프래그먼트 쉐이더는, 각각의 생성된 샘플에 대해, 어떤 라이트들이 샘플에 영향을 주는지를 어떤 라이트가 샘플의 타일에 할당되어있는지를 확인하므로써 얻어낼 것입니다. (Listing 4.1)

 

4.5 Supporting Transparency

이글의 처음에서 언급한것 처럼, 디퍼드 기술들은 투명도를 다루는데 어려움이 있습니다. 왜냐하면 전통적인 G-Buffer는 각 버퍼의 위치의 단일 샘플로 부터 특성(Attributes)만을 저장하기 때문입니다 [Thibieroz and Gr¨un 10]. 그러나, 포워드렌더링에서는, 우리는 샘플들의 특성들을 저장할 필요가 없습니다. 대신에 우리는 간단히 표준 알파 블랜딩을 사용하여 결과 색상을 블랜드 할 수 있습니다. 알아둬야할 점은 우리는 순서에 따른 투명도 문제를 해결하고 있는 것이 아닙니다. 정확히 말하면, 우리는, 많은 디퍼드 기술과 다르게, 각 레이어가 올바르게 라이팅 처리되는 곳에서 표준 알파 블랜드를 지원합니다. 그러나 어플리케이션은 투명 오브젝트들이 뒤에서 부터 앞으로 적절하게 그려지는 것을 보장해야 합니다. 우리는 기본 포워드 쉐이딩 알고리즘과 비교하면서 아래의 변화를 만들 필요가 있습니다 (Section 4.4).

 

선택 최소 혹은 최대 Z-bound. 우리는 여기서 투명 오브젝트를 고려할 필요가 있습니다, 차폐되지 않은 투명 오브젝트는 타일은 바운드에 타일의 최소 Z-bound ("near plane")를 카메라로 가까이 옮기는데 영향을 주지 않을 것입니다. 우리는 불투명과 투명 지오메티를 둘다 포함하는 단일 타일을 사용하기 보다는 2가지다른 타일 세트를 불투명과 투명 지오메트리에 사용합니다. 불투명 오브젝트와 함께 사용되는 타일의 Z-bound는 Section 4.4에 설명처럼 계산되어 집니다, 그리고 그것은 불투명 오브젝트에 대해서 좋은 라이트 할당을 제공합니다 (그림 4.3(a)).

 

// 1D texture holding per -tile light lists
uniform isampleBuffer tex_tileLightLists;

// uniform buffer holding each tile’s light count and
// start offset of the tile’s light list (in
// tex_tileLightIndices)
uniform TileLightListRanges
{
	ivec2 u_lightListRange[MAX_NUM_TILES];
}
void shading_function( inout FragmentData aFragData )
{
	// ...
	// find fragment ’s tile using gl_FragCoord
	ivec2 tileCoord = ivec2(gl_FragCoord.xy)
		/ ivec2(TILE_SIZE_X , TILE_SIZE_Y);
	int tileIdx = tileCoord.x
		+ tileCoord.y * LIGHT_GRID_SIZE_X;
	// fetch tile’s light data start offset (.y) and
	// number of lights (.x)
	ivec2 lightListRange = u_lightListRange[tileIdx ].xy;
	// iterate over lights affecting this tile
	for( int i = 0; i < lightListRange.x; ++i )
	{
		int lightIndex = lightListRange.y + i;
		// fetch global light ID
		int globalLightId = texelFetch(
		tex_tileLightLists, lightIndex ).x;
		// get the light ’s data (position , colors , ...)
		LightData lightData;
		light_get_data( lightData , globalLightId );
		// compute shading from the light
		shade( aFragData , lightData );
	}
	// ...
}

Listing 4.1. 가져온 샘플에 라이트가 어떻게 영향을 미치는지 보여주는 GLSL 의사코드. 첫째로, 우리는 프레임 버퍼의 위치에 기반하여 프래그먼트가 속해져 있는 타일 (tileidx)을 찾습니다. 각각을 타일에 대해 우리는 2개의 정수를 저장합니다(u_lightListRange array), 하나는 라이트에 영향을 주는 타일의 수, 그리고 다른 하나는 타일당 라이트 리스트 버퍼의 글로벌 오프셋 입니다 (tex_tileLightLists). 라이트 리스트 버퍼는 타일당 정수 숫자를 저장합니다, 각각의 정수는 타일에 영향을 주는 전역적으로 유일한 라이트를 식별합니다.

 

 

 

Figure 4.3. Z-bounds used for (a) opaque and (b) transparent geometries.

 

 

투명 지오메트리에 대해, 우리는 투명 오브젝트의 최소 Z-value를 값과 그리고 최소의 투명 오브젝트와 불투명 오브젝트는 각각 최대 Z-value 를 찾고 싶을 것입니다. 그러나 이것은 다소 복잡합니다, 투명 지오메트리에 몇몇 패스가 요구됩니다; 그러므로 우리는 간단히 불투명 지오메트리로 부터 최대 Z-value를 타일의 Far 방향을 막기 위해서 사용합니다. 이것은 불투명 오브젝트에 의해 가려진 라이트를 버립니다. Near 방향에서는, 우리는 카메라의 near plane으로 타일을 확장합니다. 그림 4.3(b).

분리된 바운드를 사용하는 것은 불투명과 투명 오브젝트를 모두 감싸는 타일을 사용하는 것보다 약간 빠르다는 걸로 나타났습니다; 그림 4.1(b), 분리된 바운드를 사용할때, 렌더링에 151.1 ms (위) 와 21.9 ms (아래) 가 사용됩니다, 불투명과 투명 둘에대해 바운드를 확장하는 것을 사용한것은 16.1 ms 와 23.5 ms 가 사용됩니다.

우리는 이것이 장면에 종속적인 것을 유의해야 합니다. 근사한 것을 혹은 정확한 것을 사용하는지 여부에 상관없이, 우리는 여전히 최종 렌더를 하는 동안 early-Z 와 비슷한 최적화를 하기위해서 불투명 지오메트리로 부터 깊이 버퍼를 사용합니다. 만약 우리가 타일의 실제 바운드를 알아내기 위해서 최소 혹은 최대 제거를 사용하지 않는다면, 투명을 지원하기 위해서 변경은 필요하지 않습니다.

 

라이트 할당. 만약 분리된 세트의 타일이 사용되었다면, 라이트 할당은 2번 이루어 져야합니다. 우리의 경우 특별한 최적화가 가능합니다: 우리는 2차원에서 라이트를 먼저 할당합니다 그리고나서 불투명 오브젝트 뒤에 있는 라이트를 버립니다 (최대 타일로 부터 Z-bound 사용). 이것은 투명 지오메트리를 위한 라이트 리스트를 산출합니다. 불투명 오브젝트에는 우리는 추가적으로 최소 Z-bound 정보를 기반으로 라이트를 버립니다. (Listing 4.2)

 
투명 지오메트리에 대해서, 우리는 투명 오브젝트의 최소 Z-value 그리고 투명과 불투명 오브젝트 각각의 최대 Z-value를 찾길 원할 것입니다.

 

// assign lights to 2D tiles
tiles2D = build_2d_tiles();
lightLists2D = assign_lights_to_2d_tiles( tiles2D );

// draw opaque geometry in pre -Z pass and find tiles ’
// extents in the Z- direction
depthBuffer = render_preZ_pass();
tileZBounds = reduce_z_bounds( tiles2D , depthBuffer );

// for transparent geometry , prune lights against maximum Z- direction
lightListsTrans = prune_lights_max( lightLists2D , tileZBounds );

// for opaque geometry additionally prune lights against
// minimum Z- direction
lightListsOpaque = prune_lights_min( lightListsTrans , tileZBounds );

// ...

// later: rendering
draw( opaque geometry , lightListsOpaque );
draw( trasparent geometry , lightListsTrans );

Listing 4.2. 투명도를 지원하는 렌더링 알고리즘을 설명하는 수도 코드, 그림 4.1(b). 우리는 추가 최적화를 먼저 최대 Z-방향을 기준으로 먼저 라이트를 분기합니다, 그리고 그것은 투명 지오메트리에 대해 라이트 할당을 합니다. 그리고나서 우리는 최소 Z-방향에서 라이트를 분기합니다 그리고 그것은 불투명 지오메트리에 대해 라이트 리스트를 우리에게 제공합니다.

 

렌더링과 쉐이딩. 각각의 불투명과 투명 제오메트리에 대한 적절한 라이트 리스트 세트외에는 특별한 변경이 여기서는 필요하지 않습니다. 먼저, 모든 불투명 오브젝트는 렌더링 되어져야 합니다. 그리고나서 투명 지오메트리는 뒤에서 앞으로 렌더링되어집니다. (우리의 데모에서는, 우리는 오브젝트 기반으로 정렬합니다, 그리고 그것은 투명 오브젝트가 서로 겹치는 경우 몇몇의 결점을 일으킵니다. 이것은 기술의 한계이 라기 보다는 우리 구현의 한계 입니다.)

4.6 Support for MSAA

MSAA와 비슷한 구조를 지원하는 Tiled forward shading에서 아주 간단합니다. 우리는 모든 렌더 타겟이 MSAA가 활성화 된 상태로 생성되어지는 것을 보장할 필요가 있습니다. 추가적으로, 우리는 모든 (멀티)샘플들을 선택 최소 혹은 최대 Z-제가 스탭에 고려할 필요가 있습니다.

우리는 그림 4.4에서 렌더타임에 MSAA의 효과를 보여줍니다. Tiled deferred shading 과 비교한것 처럼, 그것은 반투명을 지원하지 않습니다, 그림 4.4는 Tiled forward의 (그림 4.1(b)) 그리고 (그림 4.1(a))의 반투명을 제외한 타이밍을 포함합니다. 추가로, 우리는 메모리 사용율을 우리의 포워드와 디퍼드 구현에 대해 비교합니다.

 

 

 

그림 4.4. 다양한 MSAA 설정과 함께 tile forward 그리고 tiled deferred shading 에서의 (a) 렌더타임과 (b) 메모리 사용율. 우리는 deferred에서 8x MSAA 프레임 버퍼의 할당이 불가능하다, 그것이 우리가 해당 설정에 대해 타이밍 결과를 사용 불가능한 이유입니다. 메모리 사용율은 32 비트 깊이 버퍼,  32 비트 ambient, 그리고 64 비트 normal, diffuse 그리고 specular 컴포넌트를  G-buffer 기반으로 측정되어진다, . (RGBA16F format 사용)

 

 

 

흥미로운 점은 우리의 최적화 되지 않은 Z-제거 확장은 샘플들의 수에 대해 거의 선형이다: 샘플 1개를 사용한 경우 0.75 ms 에서 8x MSAA를 사용한 경우 5.1 ms. 이 점에서, Z-제거의 기여는 총 프레임 타임의 측면에서 꽤 중요하다. 그러나, 그것은 여전히 우리의 테스트에서 높은 속도를 제공합니다. Z-제거 스텝을 더 최적화 할 가능성도 있습니다, 예를들어, 프레그먼트 쉐이더 대신 컴퓨트 쉐이더를 사용하므로써 가능합니다.

4.7 Supporting Different Shaders

모든 포워드 렌더링과 같이, 우리는 다른 쉐이더와 리소스(텍스쳐들, 유니폼들, 등등)를  다른 지오메트리 청크에 붙일 수 있습니다. 물론, 만약 원한다면, 우리는 여전히 Ubershader 접근법을 포워드 렌더링에서 사용할 수 있습니다. 우리는 3개의 다른 쉐이더 타입을 이 테스트에 구현했습니다, 그림 4.1(d)에서 본것 처럼: 기본 diffuse-specular 쉐이더, two-color car paint를 모방하는 쉐이더 (투명한 거품과 사자를 보세요), 그리고 rim-light 쉐이더 (정면의 중간에 있는 큰 직물을 보세요).

포워드 렌더러는 다른 쉐이더를, 다른 쉐이더 프로그램으로 컴파일 되어진, 다른 지오메트리 청크와 함께 사용합니다. 비교하기 위해, 우리는 이것은 디퍼드 렌더링에서 Ubershader로 구현했습니다. 정수값은 어떤 쉐이더를 사용하여 G-Buffer의 각 샘플을 저장하는지를 나타냅니다. (G-buffer에 있지만 몇몇 사용하지 않은 비트가 있어서, 그래서 우리는 추가 공간을 할당하지 않았습니다.). 디퍼드 쉐이딩 코드는 GLSL에서 런타임 분기를 사용하여 런타임에 적절한 쉐이더 코드를 선택합니다.

다른 쉐이더를 사용하는 것에 대한 퍼포먼스 저하는 포워드 렌더러에서 약간 덜 한것으로 보입니다; diffuse-specular 쉐이딩 에서 위에서 설명한 다른 쉐이더로의 전환은 퍼포먼스를 평균 1.4ms 떨어뜨립니다. 디퍼드 쉐이더에서는 2.2 ms 정도입니다. 그러나 다른뷰에 다른 렌더링 타임의 변화는 같은 크기입니다.

4.8 Conclusion and Further Improvements

우리는 이 챕터에서 tiled forward shading을 봐왔습니다. Tiled forward shading은 Tiled deferred shading 과 표준 포워드 쉐이딩의 장점을 조합합니다. 그것은 조건에 따라 꽤 적합합니다, 예를들어, 응용 프로그램 특수 정보들에 의해 불필요하게 만들어진 알고리즘은 제거될 수 있습니다. 하나의 예는 탑다운 뷰에서 선택 최소 그리고/혹은 최대 Z-bound 계산 입니다.

우리가 최근에 알아본 내용을 확장은 Custered shading 입니다. Tiled shading (포워드와 디퍼드 둘다) 주로 샘플드의 2D grouping을 고려합니다, 그것은 간단하지만 퍼포먼스와 견고함 이슈가 몇몇의 장면과, 뷰 설정에 따라 발생합니다. 이것의 하나의 예는 first-person 같은 카메라를 사용하는 장면에서 많은 끊어짐이 Z-방향(그림 4.5)에서 발생하는 것입니다. Clustered shading에서, 우리는 대신 3D 샘플들의 그룹을 고려합니다. 그것은 이것을 더 우아하게 처리합니다.

Clustered shading의 주요 장점은 뷰 종속성 더 낮아서 높거나 예측불가능한 Z-방향의 복잡도에서도 장면내에 예측가능한 성능을 제공합니다. 단점은 복잡도가 더 높아지 것, 하드웨어 요구사항(우리는 compute shader / CUDA에 많이 의존을 함), 그리고 몇몇의 고정 비용입니다. 예를들어, tiled shading에서, 스크린을 타일로 세분화하는 것은 기본적으로 무료입니다. Clustered shading에서는 이 과정이 더 비싸집니다 - 실제로, 몇몇의 케이스에서 그것은 클러스터링에 의해 제공되어지는 더 나은 라이트를 샘플레 매핑으로 쉐이딩에서 시간을 이득을 얻어냅니다. (그림 4.6). 우리는 역시 Clustered forward shading에 대해서 더 알아보고 있습니다[Olsson et al. 12a], 그리고 그것은 현대 하이엔드 GPU의 컴퓨터 쉐이더 성능에서 좋은 결과를 보여줄 것입니다. 반면에 Tiled forward shading 구현은 더 넓은 범위의 하드웨어에서 구현할 수 있습니다.

 

 

그림 4.5. 이글에서 알아본 tiling  (a)와 clustering (b)로 만들어진 볼륨의 비교, [Olsson et al. 12b]에서 설명된것 처럼. Tiled 볼륨을 찾는 것은 상대적으로 간단하고 표준 프래그먼트 쉐이더에서 가능합니다. Clustering에서 라이트를 클러스에 할당하는 것은 컴퓨트 쉐이더에서 구현되어집니다.

그림 4.6. Tiled forward shading 과 clustered forward shading의 비교. (a) 는 탑다운뷰, tiled forward는 현재 clustered forward 구현의 성능을 뛰어넘습니다. (6.6 ms vs 9.3 ms). (b) first-person 같은 뷰에서, tiled forward는 약간 더 느려집니다. (9.4 ms vs 9.1 ms). First view에서 다소 더 느려지는 반면, 첫번째 뷰에서는 다소 느리지만, clustered shading의 가장 큰 특징은 견고한 퍼포먼스 입니다. 1024개의 랜덤하게 배치된 광원이들이 있습니다.

 

 

 

Bibliography

[Andersson 09] Johan Andersson. “Parallel Graphics in Frostbite - Current & Future.” SIGGRAPH Course: Beyond Programmable Shading, New Orleans, LA, August 6, 2009. (Available at http://s09.idav.ucdavis.edu/talks/ 04-JAndersson-ParallelFrostbite-Siggraph09.pdf.)

 

[Balestra and Engstad 08] Christophe Balestra and P˚al-Kristian Engstad. “The Technology of Uncharted: Drake’s Fortune.” Presentation, Game Developer Conference, San Francisco, CA, 2008. (Available at http://www.naughtydog. com/docs/Naughty-Dog-GDC08-UNCHARTED-Tech.pdf.)

 

[Enderton et al. 10] Eric Enderton, Erik Sintorn, Peter Shirley, and David Luebke. “Stochastic Transparency.” In I3D ’10: Proceedings of the 2010 ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games, pp. 157– 164. New York: ACM, 2010.

 

[Engel 09] Wolfgang Engel. “The Light Pre-Pass Renderer: Renderer Design for Efficient Support of Multiple Lights.” SIGGRAPH Course: Advances in Real-Time Rendering in 3D Graphics and Games, New Orleans, LA, August 3, 2009. (Available at http://www.bungie.net/News/content.aspx? type=topnews&link=Siggraph 09.)

 

[Hargreaves and Harris 04] Shawn Hargreaves and Mark Harris. “Deferred Shading.” Presentation, NVIDIA Developer Conference: 6800 Leagues Under the Sea, London, UK, June 29, 2004. (Available at http://http.download.nvidia.com/developer/presentations/2004/ 6800 Leagues/6800 Leagues Deferred Shading.pdf.)

 

[Kircher and Lawrance 09] Scott Kircher and Alan Lawrance. “Inferred Lighting: Fast Dynamic Lighting and Shadows for Opaque and Translucent Objects.” In Sandbox ’09: Proceedings of the 2009 ACM SIGGRAPH Symposium on Video Games, pp. 39–45. New York: ACM, 2009.

[Lauritzen 10] Andrew Lauritzen. “Deferred Rendering for Current and Future Rendering Pipelines.” SIGGRAPH Course: Beyond Programmable Shading, Los Angeles, CA, July 29, 2010. (Available at http://bps10.idav.ucdavis.edu/ talks/12-lauritzen DeferredShading BPS SIGGRAPH2010.pdf.)

 

[Olsson and Assarsson 11] Ola Olsson and Ulf Assarsson. “Tiled Shading.” Journal of Graphics, GPU, and Game Tools 15:4 (2011), 235–251. (Available at http://www.tandfonline.com/doi/abs/10.1080/2151237X.2011.621761.)

 

[Olsson et al. 12a] Ola Olsson, Markus Billeter, and Ulf Assarsson. “Clustered and Tiled Forward Shading: Supporting Transparency and MSAA.” In SIGGRAPH ’12: ACM SIGGRAPH 2012 Talks, article no. 37. New York: ACM, 2012.

 

[Olsson et al. 12b] Ola Olsson, Markus Billeter, and Ulf Assarsson. “Clustered Deferred and Forward Shading.” In HPG ’12: Proceedings of the Fourth ACD SIGGRPAH/Eurographics Conference on High Performance Graphics, pp. 87–96. Aire-la-Ville, Switzerland: Eurogaphics, 2012.

 

[Saito and Takahashi 90] Takafumi Saito and Tokiichiro Takahashi. “Comprehensible Rendering of 3D Shapes.” SIGGRAPH Comput. Graph. 24:4 (1990), 197–206.

 

[Shishkovtsov 05] Oles Shishkovtsov. “Deferred Shading in S.T.A.L.K.E.R.” In GPU Gems 2, edited by Matt Pharr and Randima Fernando, pp. 143–166. Reading, MA: Addison-Wesley, 2005.

 

[Swoboda 09] Matt Swoboda. “Deferred Lighting and Post Processing on PLAYSTATION 3.” Presentation, Game Developer Conference, San Francisco, 2009. (Available at http://www.technology.scee.net/files/ presentations/gdc2009/DeferredLightingandPostProcessingonPS3.ppt.)

 

[Thibieroz and Gr¨un 10] Nick Thibieroz and Holger Gr¨un. “OIT and GI Using DX11 Linked Lists.” Presentation, Game Developer Conference, San Francisco, CA, 2010. (Available at http://developer.amd.com/gpu assets/ OIT%20and%20Indirect%20Illumination%20using%20DX11%20Linked% 20Lists forweb.ppsx.)

 

[Trebilco 09] Damian Trebilco. “Light Indexed Deferred Rendering.” In ShaderX7: Advanced Rendering Techniques, edited by Wolfgang Engel, pp. 243–256. Hingham, MA: Charles River Media, 2009.</>