jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다. 3ds Max를 사용해서 게임용 3D 캐릭터를 셋업하는 방법
이를 위해 오랜 실무를 경험해 온 저자의 고급 노하우들이 공개
위 내용은 GameDevForever의 저자분들의 홍보를 위하여 운영진 자체적으로 올린 광고이며 일체의 수익이 없습니다.(밥좀사줘요~)
Posted by 김포프
콘솔게임 개발의 장점은 한 하드웨어에 특화된 최적화를 할 수 있다는 겁니다. 마이크로소프트나 소니 둘 다 자기네 하드웨어가 더 뛰어나다는 걸 보여주기 위해 조금씩 다른 기능들을 추가하곤 하는데요. 아무래도 그래픽스 프로그래머인 저는 그래픽 관련 쪽의 하드웨어를 주로 다루게 됩니다. 여기서 간단히 설명 드릴 건 Xbox 360의 EDRAM과 PS3의 ZCull 메모리에 대해... 요즘 Darksiders 2게임 최적화 해주다보니 나름 요놈들을 주물러 줄 일이 있어서......

Xbox 360의 EDRAM
일단 Xbox 360의 EDRAM은 렌더타겟 위에 픽셀을 뿌려주는 속도를 빠르게 하기 위한 놈입니다. 보통 렌더타겟 설정하고 메쉬들을 그리면 최종 결과가 렌더타겟하고 연계된 텍스처의 메모리로 들어가잖아요? 근데 bandwidth가 충분치 않아서 여기서 bottleneck이 걸리는 경우가 많습니다. Xbox 360는 이 문제를 해결하려고 EDRAM이란 것을 렌더링 파이프라인 젤 마지막에 설치해서 텍스처 메모리가 아닌 이 하드웨어 메모리에 모든 픽셀들을 그립니다. 즉 렌더타겟 아무리 설정하고 픽셀을 수만개를 그려봐야 최종 텍스처의 메모리에는 아무것도 안들어갑니다. 모든 건 고스란이 EDRAM안에 있죠. 이러면 아무래도 EDRAM 하드웨어 상에서 블렌딩이며 overdraw며 다 처리해서 확실히 빠릅니다. 이렇게 그릴거 다 그린 뒤에 이 EDRAM 안에 있는 최종결과를 텍스처로 옮겨갈 때 쓰는 명령어가 Resolve()입니다.  XNA 개발해보신 분들은 3.0버전인가부터 Resolve()를 직접 호출해줘야 하죠? 바로 Xbox 360하고 PC에서 공통으로 실행되는 API를 제공하기 위해서 그런 겁니다.

근데 문제는 Xbox 360에서는 언제나 EDRAM을 이용해야만 한다는 거죠. 물론 EDRAM을 사용해서 성능상 손해될 것은 없습니다. EDRAM을 사용하지 않는 것보다 성능이 나오지 않는 경우는 없으니까요. 정말 문제는 EDRAM의 크기가 10MB라는 건데요. 총 합이 10MB 를 넘는 렌더타겟들을 한 번에 사용하려면 그대로 뻗습니다......이게 바로 스페이스마린 Xbox 360의 해상도가 진정한 720P가 아닌 이유입니다. 진정한 720P는 1280 X 720 픽셀을 지원해야 하는데 이럴경우 저희 조명패스가 10MB 제한을 넘었거든요.

조명패스에서 사용하는 렌더타겟:

  • 렌더타겟
    • 포맷: A16R16G16B16
    • 바이트 / 픽셀: 8바이트
  • 깊이/스텐실 버퍼 
    • D24S8
    • 바이트 / 픽셀: 4바이트
이걸 1280 X 720으로 메모리 사용량을 계산하면

  • 렌더타겟: 1280 X 720 X 8 = 7,372,800 바이트
  • 깊이/스텐실 버퍼: 1280 X 720 X 4 = 3,686,400 바이트
  • 총합: 11,059,200 바이트 = 10.54 MB (버럭! 0.54메가가 넘다니!)
물론 이런 문제를 해결하기 위해 Predicated Tiling이라는 방법을 사용할 수 있습니다. 하지만 이건 성능 상의 문제도 있고 PS3나 PC 등의 다른 플랫폼도 동시에 지원하는 게임에서 한쪽 플랫폼에만 특화된 코드를 개발하는 일에 인력을 투입하는 것도 좀 돈낭비란 생각이 들어서.... 그냥 저희 멋대로 좌우 40픽셀씩만 잘라냈습니다. 그래서 스페이스마린 Xbox 360 버전의 해상도는 1200 X 720입니다.... -_-..... 이렇게 해서 다시 메모리 사용량을 계산하면 10MB가 조금 안됩니다.

  • 렌더타겟: 1200 X 720 X 8 = 6,912,000바이트
  • 깊이/스텐실 버퍼: 1200 X 720 X 4 = 3,456,000 바이트
  • 총합: 10,368,000 바이트 = 9.89 MB

하지만 최종 TV에 등장하는 해상도는 여전히 1280 x 720입니다. 내부적으로 모든 렌더링을 1200 X 720으로 한 뒤 마지막 단계에서 그냥 1280 x 720으로 업샘플(upsample) 해줍니다... Xbox 360 하드웨어 자체에서 업샘플링을 지원해 주는걸로 기억합니다...품질도 괜찮은 편이고요.

PS3의 ZCULL 메모리
PS3에는 EDRAM같은 건 없습니다. 따라서 Xbox 360에 비해 렌더타겟에 픽셀들을 뿌려주는게 확실히 느립니다. 그 대신 PS3에는 Xbox 360에는 없는 ZCull이라는게 있는데요. ZCull은 계층적 깊이버퍼(Hierarchical Depth Buffer)와 하는 일이 비슷합니다. 보통 깊이 테스트를 통한 픽셀 rejection은 픽셀쉐이더가 실행된 뒤에 하거든요. 그래서 깊이 테스트에 실패하던 말던 픽셀쉐이더를 돌리느라 GPU 사이클을 낭비하곤 하지요.  '깊이테스트에 실패할거면 차라리 픽셀쉐이더조차 돌리지 말자'라는 개념으로 ATI가 추가한게 Hi-Z(계층적깊이)구요. 아마 이게 특허가 걸려있어서 NVidia에서는 그대신 ZCull을 추가하지 않았나 싶습니다. 참고로 Xbox 360에 들어가는 GPU가 ATI, PS3에 들어가는 GPU가 NVidia입니다.

사실 ZCull과 EDRAM은 하는 짓 자체가 전혀 틀린데 그래도 공통점 하나가 있습니다. ZCull도 하드웨어 자체에 붙어있는 메모리가 있죠. 물론 당연 그에 따라 제약도 있을거고.... 물론 EDRAM처럼 렌더타겟의 비트수만큼의 MB를 잡아먹진 않습니다. 그대신 자체적으로 깊이만 판단하면 되니까 그냥 어느정도 해상도까지만 지원해주죠. 이 어느정도 해상도라는게 대략 2048 x 1536입니다. 이정도면 사실 왠만해선 충분한 해상도지만 Cascade Shadow Map 기법에서 cascade를 렌더타겟 하나에 뭉쳐놓으려고 할 때 문제가 생기곤 하죠. 각 cascade가 1024 x 1024고 총 4개의 cascade를 사용한다면 렌더타겟의 크기가 2048 x 2048이 될테니까요.

물론 ZCull이 지원하는 해상도를 넘는 렌더타겟을 사용해도 최종결과는 동일합니다. 즉 뻗지 않습니다.... -_-..... Xbox 360의 EDRAM과는 달리 다 제대로 돌고 결과도 제대론데 문제는 성능이 개떡이 된다는 거죠. PS3의 픽셀쉐이더 속도가 Xbox 360에 비해 느린 것이 보통이라 이 ZCull이 제대로 작동되냐 마냐에 따라 프레임수가 확 차이가 납니다. 소니측에서도 성능향상 방법 1번으로 꼽는게 'ZCull 잘 주물러주기'입니다. 물론 단지 해상도뿐만이 아니라 다른 조건들이 맞아야만 ZCull이 활성화되서 좀 더 다루기 까다로운 것도 있지만..... 역시 PS3는 참 까탈스럽습니다.. ㅎ

어쨌든 이 해상도 꾸겨 맞출려고, 한 때는 cascade의 크기를 768 x 768로 제한했었고... (이러면 카스케이드 4개를 렌더타겟 하나에 뭉쳐도 1536 x 1536이니까요.) 나중에는 차라리 Deferred Shadow라는 기법을 이용해서 이 제한을 피해갔습니다. (물론 디퍼드 샤도우를 사용한 이유는 인접 카스케이드 맵의 혼합을 통한 그림자 품질개선이 주 목적이었습니다.)


대충 제 생각/소망
ZCull이나 EDRAM이나 모두 훌륭한 아이디어임에는 분명합니다. 이거 없었으면 저희 게임에서 이 정도로 성능뽑아줄 수도 없었고요.

다만 EDRAM이 ZCull처럼 해상도에 대해 좀 너그러웠으면 하는 바램이 있습니다. 해상도 지원안되는거면 그냥 성능을 줄여도 좋으니 화면에는 보이는 결과는 옳게? 저희처럼 수백만 달라 들어가는 게임이 아니라면 그 정도 성능이 필요할리가 없거든요. (아님 EDRAM사이즈를 엄청 크게 줘서 콘솔 제조원가를 올린뒤, 그걸 게이머들이 내게 하거나?.... 뭔가 이 옵션은.... 안될거 같죠?  -_- )

그리고 PS3쪽에 바라는 건 ZCull의 까탈을 좀 줄여주거나.... 까탈을 부리고 싶으면 제대로 알려주기라도 하라는... 소니에서 제공하는 프로파일러에서 캡춰하지 않는한 ZCull이 도는지 아닌지 알수가 없어요... 잘 돌던게 다른 프로그래머 실수로 갑자기 고장나도 몇 달 지나서야 발견하고.... (아님 이 해상도 제한을 높이고 콘솔기기를 비싼 값에 팔던가.....? 역시 돈이 문제입니다... -_-  )


포프였습니다.
 

댓글을 달아 주세요

  1. Favicon of http://gamedevforever.com 김포프 2011.12.08 15:51 신고  댓글주소  수정/삭제  댓글쓰기

    첫글부터 너무 딴나라 이야기해서 죄송합니다.... -_-

  2. Favicon of http://gamedevforever.com 대마왕J 2011.12.08 16:05 신고  댓글주소  수정/삭제  댓글쓰기

    우왕 저한테는 어려워요 @_@ ㅋㅋㅋ
    어라 근데 대충 무슨 얘긴지 읽어진다?!??

  3. Favicon of http://gamedevforever.com 귀거리 2011.12.08 16:07 신고  댓글주소  수정/삭제  댓글쓰기

    아 성준님 소개로 왓는데 전 그래픽 출신이라...머리가 아프네요 ㅎㅎㅎㅎㅎ

    • Favicon of http://gamedevforever.com 김포프 2011.12.08 16:10 신고  댓글주소  수정/삭제

      저도 그래픽 출신이에요....그래픽(프로그래머) 출신 ^^... 실은 담주에 제 개인 블로그에 올릴려고 써놓은 글인데... 아무래도 여기 썰렁히 비어있는게 좀 그래서.. 그냥 올렸어요 제맘대로..

      다양한 난이도, 분야, 주제의 글들이 올라왔으면 좋겠어요.. 기대하겠습니다 ^^

  4. Favicon of http://dishdev.me/ Dish 2011.12.08 16:19 신고  댓글주소  수정/삭제  댓글쓰기

    우오 멀티플랫폼 내공이 있어야 쓸 수 있는 포스팅!

  5. Favicon of http://gamedevforever.com cagetu 2011.12.08 17:48 신고  댓글주소  수정/삭제  댓글쓰기

    좋아요! 만들어줘요... ㅎㅎ

  6. Silverchime 2011.12.08 20:50 신고  댓글주소  수정/삭제  댓글쓰기

    전 쉬운걸로 해야겠네요 ^^; 이론이나... 잘봤습니다!

  7. cretom 2011.12.08 20:55 신고  댓글주소  수정/삭제  댓글쓰기

    멋진글 잘 읽었습니다~
    콘솔쪽 내공이 대단하신듯! ^^;

  8. Favicon of http://gamedevforever.com ozlael 2011.12.09 02:20 신고  댓글주소  수정/삭제  댓글쓰기

    앜! 콘솔 어려워!

  9. Favicon of http://Junios.net Junios 2011.12.09 09:54 신고  댓글주소  수정/삭제  댓글쓰기

    간만에 보는 콘솔은 언제나 -_- 딱딱 정해져 있어서 맞추는데 일이 들어간다는 어려워 ㅠ.ㅠ

    그나마저나 아는게 좀 있음 글 써보고 싶은데. ㄷㄷ 일정 단위로 쓸께 없으면 ㄷㄷ

    암턴 잘 보고 갑니다.

    • Favicon of http://gamedevforever.com 김포프 2011.12.09 10:12 신고  댓글주소  수정/삭제

      "필자 가이드"에서 밝혀놨듯이 글 하나만 올리셔도 참여해주시면 저희야 너무 고맙습니다.

      날짜를 굳이 정해놓은 이유는 하루에 몰려서 올라오는 일이 없도록 하기 위해서니까요... 그리고 막상 쓰는 날이라고 정해놓으면 쓸 의욕이 생기고 쓸 내용이 생각난다고 하시는 분들도 몇분 계시더라구요 ^^

  10. Favicon of http://gamedevforever.com saebaryo 2011.12.09 10:08 신고  댓글주소  수정/삭제  댓글쓰기

    콘솔쪽 프로그래밍에 관심이 있었는데, 좋은 글 감사합니다. ^^
    양 기종 스펙에 대한 실제 사례를 적어주셔서 더 와닿는 것 같습니다~

  11. 66v 2011.12.30 01:01 신고  댓글주소  수정/삭제  댓글쓰기

    콘솔 개발 동지를 만나 기쁠 따름입니다. 엉엉.

    EDRAM 10Mb제한에 의한 720P 렌더링 불가는 처음 들었을때 어이가 없었던 기억이 나네요 ㅎㅎ
    Resolve()를 남발하는 파이프라인만 주의하면 PS3보다 월등히 좋은 GPU성능을 보여주지만, 최근엔 워낙 또 후처리 기술이 많이 등장해서 Resolve()가 보틀넥이 되어 돌아오는 부작용을 동반하니 역시 만능은 없는것 같습니다.

    반대로 계륵같던 SPU는 후처리의 적극적인 사용으로 PS3의 구세주가 되었지만, 멀티범용설계 엔진들은 SPU전용 처리는 우선 고려사항이 아닌지라, 엔진 갖다쓰는 저희들은 퍼스트파티 작품들을 부러운 눈으로 쳐다볼 뿐입니다...(대신 아티스트 분들이 '우리도 저런거 해줘여'라고 하면 엔진탓으로 변명하긴 좋습니다만)

    • Favicon of http://gamedevforever.com 김포프 2011.12.30 02:47 신고  댓글주소  수정/삭제

      소수민족(?)의 설움이라죠? ㅋ 저희도 후처리에서 resolve()때문에 고생을 많이 해서..(720p resolve 하나 하는데 대략 0.3ms 정도 걸렸던듯) 나중엔 결국 후처리 기법들을 한군데 모아서.. 쉐이더 하나에서 전부 처리했습니다. 그리고 uber post-processing이라고 불러버렸다지요 ㅎㅎ

      저희는 엔진 자체 제작했던지라 최적화는 조금 편했어요 ^^

    • 66v 2011.12.30 12:04 신고  댓글주소  수정/삭제

      언렬엔진에도 위버포스트프로세싱 이라고, 모션블러나 글레어 같이 주로 쓰이는 후처리를 모아서 일괄처리 하는 스텝이 있습니다. 똑같네요 ㅎㅎ

      개발환경같은 얘길 하기 시작하니 한도끝도 없어져서 뭔가 좀 쓰다가 다시 지웠습니다 ^^;

    • Favicon of http://gamedevforever.com 김포프 2011.12.30 18:41 신고  댓글주소  수정/삭제

      자~ 뭔가 쓰실게 많으신듯 하니.. 게임개발포에버에 참가해보시는건 어떨까요? ^_^

    • 66v 2011.12.31 09:26 신고  댓글주소  수정/삭제

      헐... 감사한 말씀입니다만, 제가 블로그나 게시판 활동을 꾸준히 잘 못해서 초반 몇번만 참여하다가 잠수 타버리는 패턴으로 폐만 끼치게 될 것 같습니다 ^^;; 아직 남들과 공유할만한 지식을 갖추지 못한게 더 큰 이유 겠지만요 -_-;;

      대신 뭔가 쓰거나 정리하게 되면 문서로 제출하는 방식으로 참여 하는건 어떨까 싶네요. 물론 저 뿐만 아닌 모든 분들이.

      정기적인 참여가 필요하다는 점은 부담감으로 작용하는 면이 있기 때문에 일단 원고를 상시 모집하여 검토 후 게시하는, GameProgrammingGems나 ShaderX의 온라인 버전같은 방식을 겸해보는것도 좋지 않을까 합니다.

      물론 그것도 역시 관리하는 분들의 수고가 많이 필요하기 때문에 그냥 하나의 방법론적인 제안일 뿐입니다. ^^;;

    • Favicon of http://gamedevforever.com 김포프 2011.12.31 13:22 신고  댓글주소  수정/삭제

      뭐 참여하신뒤 글 한두개 올리고 잠수타시면 되죠. 그게 폐를 끼치는거라곤 생각치 않는데요. ^_^ 차라리 저희에겐 그게 더 편해요~ (저희가 편집안해도 되니... 다들 바쁘신 분들이라 남글 편집까지 신경쓸 시간이 없을듯...)

    • 66v 2012.01.01 01:07 신고  댓글주소  수정/삭제

      오히려 관리 코스트만 늘어나게 되는 거군요 ^^;;
      아직은 제가 많이 준비되지 못한 상태라(실력, 경험, 글감, 여유시간 등 여러 면에서) 지금 당장은 어렵지만, 어느정도 준비 되었을때 참여해도 될지 재차 여쭙도록 하겠습니다~



티스토리 툴바