[GPG 6 글 5.7] 지연 렌더링 방식에 관해

GPG 시리즈 관련 질답, 논의 공간.

Moderator: 류광

kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

지연 렌더링 방식에 관해

Post by kim05005 »

정말 얼마만에 로그인해서 남기는 글인지 모르겠습니다.

렌더러 구조를 설계하다가 든 생각인데,

지연 렌더링의 방식이 많은 수의 광원을 좀 더 빠르고 유연하게 처리할 수 있도록 고안된 것인데,
기존의 Forward rendering에서는 물체 마다 광원 하나 하나를 처리해줬었다면,
지연 렌더링에서는 기하 버퍼를 통해서 픽셀 단위로 처리를 하게 해줍니다.

최악의 경우에서 기존 Forward rendering의 조명의 복잡도는,
O( 물체의 수 * 광원의 수 ), 단, 모든 픽셀이 모든 물체에 의해 중복 연산되었을 때입니다.

역시 최악의 경우에서 지연 렌더링은,
O( 물체의 수 + 광원의 수), 모든 픽셀이 조명을 받는다고 했을 때겠지요.

그렇다면 Forward rendering에서 중복 연산되는 픽셀이 없도록 하면, 지연 렌더링과 같아지게 되지 않을까요.
Early-Z 기법을 통해서 픽셀 셰이더에서 조명 연산을 하기 전에 중단시킬 수 있다면 복잡도는 지연 렌더링과 같아질 것이라고 생각됩니다.

헌데, Early-Z를 이용한 렌더링 기법이 이미 있었음에도 불구하고 지연 렌더링이 요즘 화두가 되는 것은 어떤 장점이 있기 때문인지 궁금합니다.

단순히 셰이더 프로그램을 분리함으로서 얻는 이점은, 메모리 대역폭의 한계로 인한 병목현상보다는 적을 것이라 개인적으로 생각합니다.
지금도 콜라 좋아해요!
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

관련 GPG 카탈로그 페이지와 연결시켰습니다 :)
.
Posts: 2
Joined: 2009-11-23 16:24

Post by . »

보통 dx 파이프라인에서는 depth test가 pixel(혹은 fragment) 연산 후 수행되는데,
이 depth test를 pixel 연산 전에 해주자는 것이 결국 early-z입니다.

early-z는 하드웨어에서 제공할수도, 소프트웨어적으로 비슷하게 구현하는것도 가능한데요

하드웨어에서 제공하는 early-z는 depth test가 성공하여 해당 pixel이 무시되었을때는 상관이 없지만
아니라면 pixel연산을 계속한다는 것은 변함이 없습니다.

예를 들어, 물체가 시야 방향으로 100개가 늘어서 있고,
재수없게도 맨 뒤의 물체부터 그리기 시작한다면 pixel 연산을 100번 해주는 것은 여전합니다.
이것을 막으려면 오브젝트를 view 순서대로 sorting을 해줘야하는데 이 과정도 비용이 드는것이구요.

소프트웨어적으로 구현한다면 이러한 문제점이 줄겠지만 2-pass가 되고. 또한 이 개념이 deferred-rendering과 크게 다를바가 없지요.


그리고 결정적으로 deferred rendering이 호평을 받는 것은 lighting이라던가, 첫 패스에서 저장했던 z, normal, position값 등등이 post-processing에서 유용하게 사용되기 때문입니다.
Last edited by . on 2010-08-22 22:27, edited 1 time in total.
kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

Post by kim05005 »

류광 wrote:관련 GPG 카탈로그 페이지와 연결시켰습니다 :)
감사합니다 ^^



제가 오히려 알려드리는 입장이 되어서 조금 당혹스럽긴 하네요.
Early-Z를 이용할 때에는 보통 2패스로 사용합니다.
1번째 패스에서는 깊이 버퍼만 채운 뒤에,
2번째 패스에서는 1번째 패스에서 채운 깊이 버퍼를 활용하여 해당 깊이와 동일한 깊이의 픽셀만 그리게끔 합니다.

이렇게 하지 않으면 말씀하신대로 기존의 forward rendering과는 앞에서부터 정렬하여 렌더링하지 않는 이상은 크게 차이가 없겠지요.

위 방법대로 하면, 겹쳐그리기(오버드로우)가 없게 되므로 지연 렌더링과 크게 다를 것이 무엇이 있겠냐는 질문이었습니다..

제가 좀 막연하게 질문을 했던 것 같기도 하네요;
지금도 콜라 좋아해요!
비회원

Post by 비회원 »

kim05005 wrote:
류광 wrote:관련 GPG 카탈로그 페이지와 연결시켰습니다 :)
감사합니다 ^^



제가 오히려 알려드리는 입장이 되어서 조금 당혹스럽긴 하네요.
Early-Z를 이용할 때에는 보통 2패스로 사용합니다.
1번째 패스에서는 깊이 버퍼만 채운 뒤에,
2번째 패스에서는 1번째 패스에서 채운 깊이 버퍼를 활용하여 해당 깊이와 동일한 깊이의 픽셀만 그리게끔 합니다.

이렇게 하지 않으면 말씀하신대로 기존의 forward rendering과는 앞에서부터 정렬하여 렌더링하지 않는 이상은 크게 차이가 없겠지요.

위 방법대로 하면, 겹쳐그리기(오버드로우)가 없게 되므로 지연 렌더링과 크게 다를 것이 무엇이 있겠냐는 질문이었습니다..

제가 좀 막연하게 질문을 했던 것 같기도 하네요;

글을 자세히 안보시고 이런 말씀 하시는게 더 당혹스럽네요.

분명히 제가 글에 Early-z는 두가지 방법으로 가능하다고 설명했고, 2-pass로 사용하는 방법이 소프트웨어적인 방법이고 early-z를 하드웨어에서 지원하는 그래픽 카드도 있습니다. ati는 R300시리즈부터인가 지원하기 시작했고, nvidia는 g80시리즈부터인가 지원하기 시작했습니다.(즉, 아무 그래픽카드나 다 되는 것이 아닙니다)

그리고 픽셀 연산의 중복이 없다면 지연 렌더링과 다를 것이 무엇이 있겠냐고 말하셨듯이, 2-pass에 걸쳐가며 early-z를 쓸 필요가 없는거죠. 지연 렌더링을 쓰면 early-z와 같은 효과를 볼 뿐더러, MRT 지원하는 그래픽 카드도 시중에 상당히 보급되어 있으므로 1pass에 필요한 정보들을 저장하는 것이 가능하구요.

더욱이 dynamic light들이 점점 많아지는 요즘게임에서 라이팅 8개 재한이라는건 뼈아프죠.
kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

Post by kim05005 »

애초의 Early-Z의 소프트웨어적인 방법이 어딨습니까 -_-;
그냥 일반적인 Z Test하고 착각하신 거 같아서 말씀을 드려도..

어차피 지연 렌더링도 광원 개수만큼 조명 패스를 반복해야하는데, 이 점은 마찬가지 아닐까요.
MRT가 된다고해서 다 능사가 아닌 게 제가 적었듯이 대역폭문제가 큽니다.

얻어먹으러 온 주제에 이런 말씀 드리긴 뭣한데, 혼동하시는 건 그렇다고 쳐도 최소한 질문글을 다 읽고 답변해주셨으면 좋겠습니다; 되레 제가 알려드려야 하는 상황이네요.
지금도 콜라 좋아해요!
비회원

Post by 비회원 »

kim05005 wrote:Early-Z를 이용할 때에는 보통 2패스로 사용합니다.
1번째 패스에서는 깊이 버퍼만 채운 뒤에,
2번째 패스에서는 1번째 패스에서 채운 깊이 버퍼를 활용하여 해당 깊이와 동일한 깊이의 픽셀만 그리게끔 합니다.
이 과정은 프로그래머가 코드를 짜서 넣어주지 않으면 기계가 알아서 해줍니까?


early-z가 '위 처럼 해야지 early-z다'인 것도 아니고, 그냥 하나의 개념일뿐입니다.
하드웨어가 지원해주고 조건에 맞으면 사용하는 것이고, 아니면 그러하게 프로그램으로 짜는거죠.
early-z는 그냥 일반적인 depth test(Z-test)를 픽셀 연산 전에 하면 그게 바로 early-z입니다.


대역폭 문제도 deffered rendering이 클 경우가 많겠지만, 항상 크다고 할 순 없죠.
foward rendering도 장면의 복잡도가 높아질수록 대역폭도 커질 뿐더러 복잡도에 따라 들쭉날쭉합니다.
그에 비해 deffered rendering은 대역폭이 클지언정 그 양은 꾸준하구요.


무엇보다 deffered rendering의 장점이 픽셀의 중복 연산을 막아주는 것만이 전부가 아닙니다. 다른 장점이 많기 때문에 대역폭이 크다라는 단점을 감안하고 사용하는 것이지요.
kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

Post by kim05005 »

Early-Z에 관해서는 직접 찾아보시길 바랍니다. 이 스레드가 Early-Z에 관한 스레드가 되어가는 것 같네요.

아무래도 그냥 혼자 해결하는 게 좋을 것 같습니다.
시간 내어 답변해주셔서 감사합니다.
지금도 콜라 좋아해요!
kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

Post by kim05005 »

그리고 짤막하게 나마 조언의 말씀을 드리자면, Early-Z를 소프트웨어적으로 구현하고 자시고가 없습니다. 하드웨어가 지원하지 않으면 말짱 도루묵이지요. 제가 말씀드린 것도 소프트웨어로 구현하고 그런 게 아니라 하드웨어로 지원하는 기능을 이용한 것입니다. 적어도 검색은 하고 오시는 성의는 보였으면 좋겠네요.
지금도 콜라 좋아해요!
비회원

Post by 비회원 »

kim05005 wrote:그리고 짤막하게 나마 조언의 말씀을 드리자면, Early-Z를 소프트웨어적으로 구현하고 자시고가 없습니다. 하드웨어가 지원하지 않으면 말짱 도루묵이지요. 제가 말씀드린 것도 소프트웨어로 구현하고 그런 게 아니라 하드웨어로 지원하는 기능을 이용한 것입니다. 적어도 검색은 하고 오시는 성의는 보였으면 좋겠네요.
궁금한게 Early Z 와 지연 렌더링를 똑같이 환경에서 테스트 해보면
원하는 답을 얻으실수 있지 않나요?


제가 랜더링쪽에는 약해서 그런데 혹 테스트 해보시면 결과좀 부탁드립니다 ㅎㅎ
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

GPG 6권 해당 글에서는 지연 렌더링의 성능 외의 장점으로, "기하 버퍼에 담긴 기하 정보를 이용해서 좀 더 강력한 후처리 효과를 구현할 수 있다"고 말하고 있고요. 앞에서 "."님이 언급했던 것과 같은 내용입니다. (그나저나 .을 ID로 사용할 수 있군요.... 흠)

Wikipedia의 Deferred shading 항목에서는 복잡한 광원이나 셰이더 자원의 관리가 편리하고 소프트웨어 렌더링 파이프라인(아마도 렌더리 파이프라인의 소프트웨어 부분을 말하는 듯)이 단순해진다는 점을 들고 있고요.

어쨌든 픽셀 연산량만으로 따질 일은 아닌 듯 합니다.

그리고 첫 질문글에 나온 "요즘"에 관련해서 쌀밥님의 2009년 7월 글( http://wrice.egloos.com/5000313 )을 인용하자면:
...
사실 콘솔 게임기용 게임 제작을 거의 하지 않는 한국에서는 deferred shading 을 써서 개발하는 게임도 찾아보기 힘들정도로 기술적으로 뒤 떨어져있는데요. ShaderX 7 에서는 이미 deferred shading 은 흔히 사용되는 단계정도로 취급하고, 여기서 더 나아간 새로운 방식인 pre-lighting rendering 을 소개하고 직접 구현하는 것까지 보여줍니다.
...
... GPG 6 번역서가 제 때 나왔다면 좀 나았을지도 모르겠습니다.
kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

Post by kim05005 »

그렇겠군요.
단순히 성능이 아니라 기능에 더 주안을 두어야겠네요.

답변 감사합니다. 좀 더 깊이 생각할 수 있는 기회가 되었습니다.
지금도 콜라 좋아해요!
비회원

Post by 비회원 »

http://www.slideshare.net/pjcozzi/z-buf ... imizations

Early-Z는 Z Fail을 빨리 일으켜서 비싼 픽셀 쉐이딩을 피해가는 테크닉으로

소프트웨어적인(프로그래머 의사적인) 테크닉도 있고 하드웨어적인 테크닉도 있습니다.
kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

Post by kim05005 »

..;
제가 확실히 말씀을 드리자면, 말씀하신대로 Early-Z는 픽셀 셰이더에서의 연산 이전에 Z Test를 함으로써 부하를 줄이는 것이고 이는 하드웨어에서 지원하지 않으면 방법이 없습니다.

보여주신 슬라이드쇼에서는 Early-Z Pass라고 부르네요. 이것 또한 역시 하드웨어가 지원하는 Early-Z를 이용하는 방법이지, 하드웨어가 Early-Z를 지원하지 않을 때 소프트웨어적으로 구현할 수 있는 방법이 아닙니다.
슬라이드쇼에서도 'Software technique to utilize Early-Z...'라고 나오네요.
지금도 콜라 좋아해요!
비회원

Post by 비회원 »

Z값 비교 자체를 하드웨어에서 해주기 때문에 애초에 하드웨어 테크닉이라는 말씀이시군요.
kim05005
Posts: 235
Joined: 2007-03-24 13:23
Location: namespace std
Contact:

Post by kim05005 »

제가 몇 번쨰 말씀드리는 건지 모르겠는데, 그 소프트웨어적 구현이라는 것이 하드웨어가 지원하는 Early-Z를 이용하는 절차입니다.

하드웨어에서 지원하는 버텍스 셰이더를 사용하기 위해서 버텍스 셰이더 프로그램을 컴파일 하는데, 그럼 하드웨어적인 테크닉(하드웨어 버텍스 셰이더) 말고 별도로 셰이더 프로그램 컴파일만으로 버텍스 셰이더 사용이 가능한가요?

대체 무슨 말씀을 하고자 하시는지 모르겠네요.

두 기술은 대체 가능한 동등한 레벨의 기술이 아니어요;
지금도 콜라 좋아해요!
비회원

Post by 비회원 »

지연 렌더링을 최근에 계속 쓰면서 느낀 점이
early- z 가 효율성이 더 좋으며

렌더타겟의 특성상 그래픽 카드 영향을 많이 받았습니다

결론은 두 가지 다 실험하면서 현 플랫폼에 맞는 것을 쓰는 것이
좋다고 봅니다

지연이 많은 인기를 끄는 것은
많은 게임들이 다양화되고
수 많은 특수효과들을 쓰게 되면서

효과의 모음에 대한 결론으로 생각합니다

그리고 뒤로 갈수록 알고리즘을 사용하여
합치는 방법들이 나오기에 그런 매력도 무시할 수 없다고 봅니다
비회원

Post by 비회원 »

비회원 wrote:지연 렌더링을 최근에 계속 쓰면서 느낀 점이
early- z 가 효율성이 더 좋으며

렌더타겟의 특성상 그래픽 카드 영향을 많이 받았습니다
죄송하지만 좀더 구체적인 내용을 알려주실수 없는지요?

어떻게 테스트 되었는지 ,사양은 무엇인지 그래픽카드는 ...등등 그럼 많은 도움이 될거 같습니다
비회원

Re: 지연 렌더링 방식에 관해

Post by 비회원 »

kim05005 wrote: 헌데, Early-Z를 이용한 렌더링 기법이 이미 있었음에도 불구하고 지연 렌더링이 요즘 화두가 되는 것은 어떤 장점이 있기 때문인지 궁금합니다.

Early-Z로 효과를 볼 수 있는 건 "픽셀 셰이딩 부하"를 줄여주는 것 뿐이고,
지연 셰이딩은 라이팅 등의 멀티 패스 렌더링에서 지오메트리 프로세싱을 1회로 줄여줍니다.

이 외에도 지연 셰이딩의 이점이 많지만, 처음 질문 의도인 "Early-Z"와의 비교만을 한다면,
패스 회수와 무관하게 "지오메트리 프로세싱은 단 1회". 이게 핵심이죠.
요샌 지오메트리도 복잡하고, 캐릭터는 본 수도 많고 해서, 지오메트리 및 스키닝 연산 비용이 꽤 높습니다.

렌더 스테이트 설정 등의 엔진의 렌더링 파이프라인 쪽 부하(CPU)도 줄이고요.



그리고, 사실 깊이 복잡도 문제도,
전방 렌더링에서 Early-Z에 의한 효과를 제대로 보려면 거리 순으로 렌더링해야 하는데,
불투명 오브젝트에 대해선 머티리얼 유사도를 고려한 정렬이 보다 선호되기 때문에,
Early-Z 보다 지연 셰이딩이 유리할 수 있습니다.

암튼, 장점은 한 두가지가 아닌데 (물론 단점도..),
질문의 의도인 Early-Z보다도 유리한 점이 있답니다.
비회원

Post by 비회원 »

아.. 지연렌더링..... 우리게임에도 적용시키고 싶었는데

언렬2.5쓰고있는 현재 우리 게임프로젝트의 케릭터 셰이더에서

하드웨어 스키닝과 노멀/스페큘라맵연산을 하고있는데

여기다 집어 넣으려다 명령어수 한계로 인해.. 실패.......PS2.0에서도 연산수 모지람....

엉엉.. ㅠㅠ
Post Reply