NDC Replay

헤테로지니어스 컴퓨팅 : CPU 에서 GPU 로 옮겨기 위해서
이권일
엔씨소프트
	현재 NCSOFT 에서 Linear Eternal 개발팀에 소속되어 있습니다. 다수의 온라인 게임 개발에 참여 하였으며 3D 그래픽과 최적화 관련 개발을 주로 담당하였습니다.
	CPU 만을 이용하던 시대에서 CPU 와 GPU 를 같이 사용하는 시대로 변화하고 있습니다. 언제 어떠한 부분에 GPU를 써야 적합할지를 고민하면서 배웠던 내용과 최적화를 하며 성능을 끌어올렸던 샘플 코드를 바탕으로 GPU 내부 구조와 적절한 접근 방법에 대해서 얘기하고자 합니다.
[새 창에서 슬라이드 보기]
네, 안녕하세요. 일단 발표 하기에 앞서서요. 간단히 제 소개를 하겠습니다. 지금 엔씨소프트 리지지 이터널 MMORPG 게임 개발하는 개발팀에 있고요. 사실 오늘 발표하는 것은 해당 기획과 전혀 관련이 없습니다. 저는 관계가 있게 만들고 싶은데 아직 조금, 약간 진보적인 것을 하려고 노력하고 있기 때문에 통과가 안 되고 있습니다. 언젠가 들어가면 제가 다시 살짝 얘기 하겠습니다. 그리고 NDC 발표 자주 오고요. 주로 하는 것은 최적화나 3D 같은 것 관심이 많아서 발표를 하는데 사실 3D쪽 주제는 많이 못 했어요. 그래서 다음에는 3D쪽도 꼭 해보려고 생각을 하고 있습니다. 간단하게 지금 세 가지 설명을 할건데요. 헤테로지니어스 컴퓨팅이라는 것, 뭐 사실 별 거 아니에요. 이 쪽은 마케팅 용어에 가까운데, 일단 이것 하나 하고, 그리고 DirectX 11 Compute Shader 우리 DirectX 11 혹시 써 보신 분 계신가요? 써 보신 분들? 손 들어보세요. 생각보다 적다. 우리나라 DirectX9으로 굉장히 많은 사람들이 개발을 하고 있고, 거기 미련을 못 버린다고 저는 생각을 해요. 지금 이제 윈도우 XP도 버림 받았고, DirectX9 외의 것을 쓰려면 지원이나 이런 게 있어야 되는데 대부분은 다 바뀌었다고 생각을 해요. 바뀔 시기인데 새로 개발하는 것을 바꿨으면 하는 바람입니다. 시연을 위해 제가 예제를 두 개를 만들었는데, 주로 설명하는 것은 두 개의 내용이 될 것 같아요. 시작하겠습니다. 헤테로지니어스 컴퓨팅이라고, AMD에서 마케팅 용어로 끄집어낸 거에요. 사실은 APU라고, CPU랑 GPU를 한 군데에 몰아넣어서 GPU가 개별 카드로 들어가는 게 아니라 CPU에 들어가고, CPU에 들어가면서 어디서나 GPU 연산을 쓸 수 있도록, 굳이 그래픽 카드가 없더라도 쓸 수 있도록 하겠다, 그런 용어로 CPU, GPU 통합 컴퓨팅 환경으로 얘기를 한 거에요. 그런데 AMD가 이것을 내 놓으면서, 간단히 얘기하면 인텔도 거기에 열심히 따라갔어요. 그런데 지금 우리가 요즘에 요 몇 년 사이에 발명된 CPU들이 오른쪽하고 왼쪽 거에요. 이건 AMD 마케팅 PT 인데요. 실제로 우리가 쓰는 CPU의 밑에 꺼는 한 30% 정도가 GPU를 쓰고 있고요, AMD는 42% 정도를 쓰고 있어요. 이건 무슨 얘기냐 하면 우리가 프로그램을 짤 때 최근 만든 CPU, 2~3년이지만 조금만 있으면 2~3년 그만 지나가요. 그런데 우리가 게임을 출시할 때 5년 내에 나온 컴퓨터들이 전부 다 GPU를 안에 갖고 있고, 우리가 그것을 쓰지 않으면 CPU 기능의 3분의 2를 잘 못 쓴다는 뜻이에요. 그래서 저는 내장 그래픽 카드의 성능이 얼마나 잘 날 수 있을까? 그게 되게 궁금했어요. 그래서 그쪽 관련해서 GPU 프로그래밍 배울 겸 해서 내장 그래픽 카드를 타겟으로 프로그래밍을 좀 해 봤고요. 이게 대조군으로 전부 다 나올 거에요. 그렇지만 되게 가능성이 많다고 봐요. 그래서 많은 분들이 쓰고 옮겨갔으면 좋겠어요. 그런 의미에서 발표를 골랐습니다. 지금 얘기 했던 것 중에 더해서 스마트폰들이 요즘에 GPU들이 다 들어가는데 스마트폰도 오픈CL 지원되는 하드들이 굉장히 많이 나오고 있어요. 요즘에는 오픈CL 1.2에서 얘기해는 compute shader 5.0 기준에 준하는 하드웨어들이 이 2년 사이에 나왔고요. 제가 발표하는 내용을 보시면 Compute Trader, 그러니까 GP, GPU를 코딩을 하고 CPU랑 같이 작업을 했을 때 부하를 얼마나 줄일 수 있는지, 그리고 어떤 이점이 있는지를 보고서 저보고 모바일 MMO를 만들라고 하면, 저는 MMO 좋아합니다. MMORPG를 만들라면 적용할 부분이 많을 것 같아요. 그리고 사실 충격을 가장 많이 받았던 게 저는 CPU 최적화를 굉장히 많이 해서 CPU 프로그래밍 SSE 그런 쪽을 굉장히 오랜 기간 동안 찾아 왔어요, 공부할 거리도 찾고 했는데 Stackoverflow라고 미국 개발자, 질문하는 곳이 있어요. 가보면 주제별로 질문을 볼 수 있는데 제가 질문 몇 개를 구독을 했어요, CPU쪽. 질문이 하루에 하나, 둘 올라오고 대부분 올라오는 것들이 학생들 질문하는 거나, 아니면 기초적인 것들이 올라오거나 아니면 아주 어려운 게 올라오거나 그런데. 혹시나 해서 쿠다라고 nVIDIA GPU 프로그래밍 라이브러리 관련해서 같이 구독을 해 봤어요. 그런데 쿠다 쪽은 하루에 적으면 20개, 많으면 40개도 올라오는 거에요, 게시물이. 그래서 보면 아, 이게 더 이상은 아무도 CPU 최적화는 관심이 없구나. 이게 미국에서 그것에 대한 자료도 논문이나 페이퍼도 나오지 않고 다 GPU로 넘어갔어요. 여기서 제가 게시물 비율이 1:20정도 된다고 했는데, 퍼포먼스를 재현하면 실제로 속도가 1:20정도까지 나와요. 그래서 왜 옮겨가야 되는지는 이제는 저는 작년까지는 거부했었는데, 올해는 전향을 했습니다, GPU로. 언젠가 최적화 하시는 분들은 되게 고민을 많이 하실 거에요. CPU 한계하고 우리가 쓸 수 있는 가용 리소스가 있는데 저것을 정말 쓸 수 있을까? 제가 얘기하는 DirectX 9을 버려야 된다는 것과 똑 같은 거에요. 되게 쓸 수 있는 가용 리소스가 있는데 과거에 묶여가지고 그것을 못 버리고 가는 것인가, 아니면 이것을 가져다 쓰고 좀 더 나은 게임을 만들 것인가. 결정을 해야 한다고 봅니다. GPU 프로그래밍을 하는데 라이브러리가 크게 세 가지가 있어요. nVIDIA는 전용이에요. nVIDIA 전용 쿠다가 있는데, 쿠다는 제일 먼저 나왔고, 가장 많은 카드들이 있어요. 지금 쿠다를 지원하는 하드는 거의 10년치 정도가 쌓여있어요. 그리고 그 다음에 오픈CU라고 AMD랑 애플이 손을 잡고 열심히 출시를 시킨 오픈CL이 있는데 오픈 CL은 nVIDIA도 되게 지원을 잘 해줘요. 그래서 사실 오픈CL을 배우면 다 쓸 수 있어요. nVIDIA, AMD, Intel Core까지. 그런데 오픈CL 코딩을 해 보면 경우의 수가 너무 많아가지고 짜증이 나요, 숫자 같은 것들이. 그리고 마지막으로 가장 인기가 없는 게 Directcompute에요. 이것은 인텔 SSD만큼 인기가 없어요, 사실. Stackoverflow에 가면. 그런데 쓰기는 되게 편해요. 윈도우 드라이브만 잘 깔려 있고 DirectX11이 돌아가는 하드웨어랑 컴퓨터가 있으면, 윈도우 B스타 이상이죠. 있으면 누구나 쓸 수 있어요. 결국 비주얼H에서 이 다이렉트 컴퓨트 위에다가 레이어를 하나 더 씌워서 AMP라고 GP, GPU 헤트로지니어스 컴퓨팅을 하는 라이브러리도 내 놨어요. 하이브리드 컴퓨팅 하는 그런 물건들도 있는데 일단 기본적으로 다른 컴퓨터 위에서 돌아가요. MS 기반 DirectX 위에. 그래서 우리가 모바일로 간다면 오픈CL로 가야 되겠지만 지금 공부하는 입장에서 컴퓨팅을 배운다는 입장에서는 굉장히 좋은 라이브라고 생각이 돼요. 일단 가고, 그리고 비주얼 스튜디오 지원도 되게 잘 돼요. 비주얼 스튜디오에서 2012인가부터 이것을 지원을 했었는데 저도 몰랐어요, 이것을, 배울 때까지. 그런데 C 파일같이 파이러블 쉐이딩 랭귀지, 그러니까 DirectX는 쉐이더 언어인데 이것을 넣고 NEW를 하면 컴파일까지 해 줘요. 비주얼 스튜디오에서. 그래서 컴파일 된 오브젝트 파일을 떨궈줘요. 그러니까 오브젝트라기 보다는 컴파일 된 쉐이더 파일인데 쉐이더 파일을 떨궈 주고 그게 링크가 되는 건 아닌데 컴파일까지 해 주기 때문에 실행할 때 컴파일 하는 게 아니라 그냥 그 파일을 읽어가지고 쉐이더에 던져주면 그냥 로드가 돼요. 그리고 컴파일 옵션도 비주얼 스튜디오에서 관리가 돼요. 그래서 저는 그냥 이것으로 요즘에 다 쓰고 있어요. 쉐이더, 컴파일 하고, 테스트 되고, 빌드 하다가 에러 나면 브레이크도 걸려요, 자동으로. 그러니까 에러 나면 빌드 실패했다고 에러 메시지가 떠요. 디버깅은 안되지만, 아직. 그리고 비주얼 스튜디오가 점점 DirectX 와이언 기반의 디버깅을 이어 나가고 있어요. 지금 비주얼 스튜디오 2013 업데이트가 나오면서 업데이트 2에서도 더 올라가고, 3에서는 더 올라갈 것 같아요. 다이렉트 컴퓨트도 디버깅 관련해서 좀 더 올라가지 않을까 싶어요. 일단 제 개인적으로는 비주얼 스튜디오를 쓰고, 윈도우를 쓰는 분들이라면 사용하기 좋다. 얘가 그냥 이것은 읽으라고 봤다기 보다는 코드 량이 얼마나 적은지 모여드리려고 가장 간단한 예제를 올려 봤어요. 이게 실제로는 첫 번째 단락은 DirectX 초기화하는 거에요. 그냥 우리가 DirectX를 쓰기 위해서, 다이렉트 컴퓨팅만 쓰기 위해서는 어떻게 해야 될까? 다이렉트 3D를 빼고 컴퓨트만 쓰기 위해서 DirectX 컴퓨트 쪽 초기화 하는 것을 네 줄 정도 들어가고요. 그 다음에 제가 얘기했던 것. 여기 LoadShader라는 함수가 있는데 이것은 F OPEN에서 파일을 벡터로 리턴 해주는 거에요, 그냥. 그래서 오픈 하는 것, 그 다음에 Create Shader, 그리고 계산에 필요한 버퍼 만드는 것, 세 번째 단락이죠. 세 번째하고 네 번째는 쉐이더에 들어갈 리소스를 하는 거에요. 이것은 API를 나중에 공부하시면 필요한 이유는 저는 약간 애매하긴 한데, 두 개가 왜 있어야 되는지, 어쨌거나 두 개로, 페어로 만들어 써야 돼요. 그리고 디스패치라고 마지막에 실행하는 것. 여기까지 해서 다이렉트 컴퓨트와는 기본적인 실행하는 데 필요한, 데이터를 보내고, 쉐이더를 로드하고, 데이터를 보내고, 실행까지. 익숙해지는 데는 좀 걸리지만 실제 뭔가를 짤 때 코드를 짤 양이 많아지면 짜증이 나요, 힘들고. 그런데 이런 것을 예제 하나 만들어 놓고 거기서 조금씩 변형되어 가면서 쓰면 생각보다 다양하게 실험도 해 볼 수 있고, 저는 프로젝트만 DX11로 넘어가면 지원이 되는지 체크해가지고 하이브리드 하게 쓸 수 있다고 생각을 해요. 하이브리드 하게 쓸 수 있다는 건 제가 두 번째 예제에서 보여 드릴 텐데, CPU에서 계산하는 것 하고 GPU에서 계산하는 것 결과물을 똑같이 맞추어 놓으면 제가 만약에 어떤 데는 CPU를 쓸 수 있고 어떤 데는 GPU를 쓸 수 있어요. 데이터가 똑 같은, 어차피 계산 결과는 버퍼에 들어있는 배열이거나 텍스처에 들어있는 2D 배열이거나 그렇기 때문에 똑같이 쓸 수 있어요. 그래서 부하에 따라서 로드 발란싱을 한다든지, 자신이 있으면, 아니면 시스템의 벤치마크를 처음에 가볍게 돌린 다음에 하나를 골라서 사용해도 괜찮다고 저는 생각을 해요. 그리고 넘어가기에 앞서서 이것 하나 지적을 할 게요. Compute Shader 버전이 있어요. 4점대하고 5점대. 4점때는 간단히 말하면 DirectX 10까지 지원하는 하드웨어 중에 쓸 수 있는 애들, 그리고 5점 대는 좀 제대로 된 것들, 그런데 4점대 갖고는 공부하지 마세요. 개인적으로 4점대는 아닙니다. 4점대가지고 하시는 분들 그냥 그래픽 카드 하나 사세요. 아니면 제가 지금 데모도 이 서피스거든요. MS에서 서피스로 데모를 보여드릴 거에요. 서피스에 있는 내장 그래픽 카드로도 충분히 효과를 볼 수 있어요. 서피스로도 충분히 GPU 프로그램이 가능해요. 그래서 내장 그래픽으로 작업을 하셔도 돼요. 요즘 최소한 IB 브릿지 이상, 2년 내에 컴퓨터 구입 하신 분들 더 오래됐으면 바꿔 달라고 해주세요. 그냥 PT 적어놨습니다, 참고하시라고요. 이것보다 높은 것 쓰시면 됩니다. 그 GPU 프로그래밍, 일단 하이브리드, 그러니까 헤테로지니어스라고 적었지만 일단 GPU 프로그램을 배워야죠. 그래서 GPU 프로그램 기본적인 것 두 가지에요. 어떻게 보면 되게 복잡한데 기억해야 될 것은 딱 두 가지에요. 멀티쓰레딩이라고, GPU에는 다 아시겠지만 프로세서가 굉장히 많이 들어있어요. 요즘에 코어에 많이 들어가는 것은 2천개 들어간다, 칩 하나에. 적게 들어가면 1500개 들어간다, 그런 얘기들 해요. 고급 GPU들. 그리고 최근에 MBDI에서 태그락K1이라고 모바일 GPU를 이용한 타블렛 나와요, 이번에. 거기 들어가는 GPU의 케플러코어가 192개가 들어갔어요. 192개가 실제로 계산을 하는 역할을 하는 코어들 얘기고요. 192개를 다 쓰기 위해서는 실제로 쓰레드를 그것보다 한 6배, 12배 가서 밀어줘야 돼요. 그래서 한 192의 6배 하면 얼마에요? 많이. 그래서 한 천 개씩 쓰레드를 만들어서 작업을 해요. 여기서는 쓰레드라고 얘기를 하는데 실제로는 분산 버퍼링을 위한 작은 작업 단위에요. 우리가 CPU에서 말하는 쓰레드하고는 좀 다르게. 그리고 이것은 좀 더 자세히 설명을 하고요. Shared Memory는 멀티쓰레딩을 하는데 각 쓰레드 간에 구분이 되어있어요. 서로 다른 쓰레드가 작업하는 것을 볼 수가 없는 상태에요. 그래서 그런 작업할 수 있는 것을 볼 수 없는 것을 해결하기 위해서 중간에 작은, 우리 C언어로 생각하면 스택 같은 메모리가 있고요. 로컬 변수 같은 거에요. 그리고 그것을 이용해서 다양한, 퍼포먼스 향상을 위해서 다양한 행위를 할 수 있어요. 그래서 일단 쓰레드부터. GPU 멀티쓰레딩 코드에요. 왼쪽은 C코드이고요. 우리가 일반적으로 로쿨을 돌면 이렇게 나오잖아요? 이건 너무 GPU 예제스러운데, 일단 예제니까요. 그리고 오른쪽은, 얘는 왜 어긋났냐? 아이고. 어쨌거나 오른쪽은 GPU 예제에요. 우리가 왼쪽에서 로쿨을 카운트만큼 도는데 GPU는 카운트 개수를 알려주고 카운트 개수만큼 쓰레드를 만들라고 하면 각 쓰레드가 A+B를 C에다 넣고서 병렬해요. 로쿨을 돌지 않아요. 그래서 CPU가 이렇게 드르륵 작업을 해서 뭔가 프로세스를 처리한다, 잡을. 그러면 GPU는 한꺼번에 빵 하고서 32개, 64개씩 쓰레드를 형성을 해요. 그래서 실제로 코어 안 해서 아까 192개 들어있다고 했죠? 새로 나온 모바일 GPU에 192개 들어있다고 했잖아요. 192개를 32개 단위로 나누어서 32개 단위가 하나의 블록이에요. 계산 블록이고, 계산 블록 단위로 그 연산들이 들어가고, 192개면 6개, 실제로 서른 두 개짜리의 묶음 쓰레드가 6개가 들어가요. 그래서 그것을 여기 GPU에서는 Single Instruction Multi Thread라고 이름 붙였어요. 저는 SIMD랑 다를 게 없다고 생각하지만 약간 다른 게 있어요, 써보면. 그래서 제가 말한 32개 64개라고 한 이유는 실제로 32개 명령어들이, 32개 쓰레드들이 같은 명령어만 실행을 하게 구조가 되어있어요. 그래서 걔네들을 워프나 웨이브프론트, 업체마다 용어가 좀 다른데, 그렇게 애들이 묶여 있고, 묶여 있는 애들이 한꺼번에 실행하기 때문에 우리가 멀티쓰레딩 프로그램을 조금 신경을 써야 돼요. 그리고 분기 발생했을 때 문제가 생기는데 제가 다음 슬라이드에서 보여드릴게요. 이게 서른 두 개 단위로 묶여있는 쓰레드들이에요. 여기서 위에서부터 코드가 실행이 되면 if 문이 와요. If 쓰레드 번호가 16보다 낮을 때, 그래서 0번부터 15번이 실행이 될 때는 실제로 GPU 안에서는 이 32개 쓰레드들이 왼쪽의 16개는 실행이 되는데 오른쪽 16개는 실행이 대기를 타요. 그냥 NOP, NO OPERATION 해가지고 그 동안 그냥 기다려요. 왼쪽 게 끝날 때까지. 그리고 다시 와서 ELSE에 와서, ELSE에서는 한번 더 실행을 하겠죠, 다 자기 조건만 체크한 다음에. 그렇다 보니까 이번에는 그 나머지 것들이 실행이 돼요. 그래서 CPU에서는 왼쪽 오른쪽이 나뉘어서 한쪽에 비싼 것 넣고, 한쪽에 싼 것 넣으면 한쪽만 탄다, 둘 다 비싸도 절반 비용만 드는데 GPU에서는 IF문 같은 것을 잘못 쓰면 모든 비용을 다 뒤집어쓰게 되어있어요. 이런 것들 신경을 써서 코딩을 해야 돼요. 이거 32개 단위, 64개 단위. 그리고 Shared Memory로 넘어갈게요. Shared Memory는 임시 버퍼인데 GPU와 메모리와 그 사이에 있는 캐시 같은 녀석이에요. 그런데 GPU는, 이게 처음 나온 이유는 여러 가지가 있는데 첫 번째는 쓰레드 간의 데이터 공유에요. 쓰레드가 한꺼번에 32개씩 돌아가기 때문에 쓰레드 간에 32개 단위로 서로 통신을 할 수가 없어요. 그래서 이 공유 메모리라는, Shared Memory라는 녀석이 자기가 계산한 결과를 넣어 놓고 인덱스로 넣어놓고 다른 애의 인덱스를 참조하면 다른 애가 계산한 결과물을 받아올 수 있어요. 그래서 쓰레드간에 계산을 하고 그것들 주고받을 때 쓸 수 있고, 아니면 캐시 용도로 쓰기도 해요. GPU에 메모리가 들어 있으면 요즘 굉장히 밴디시가 많이 나가면 300GB/SEC 이런 얘기가 나와요. 밴디시가 되게 높거든요. 그런데 밴디시가 굉장히 높다고 해서 실제로 빠른 게 아니에요. 랜덤하게 걔네를 접근해보면, 랜덤하게 데이터를 가져가기 위해서 메모리는 실제로 우리가 밴디시 적은 거 말고 접근 시간이라는 게 있어요, 레이턴시라고, 주소를 한 번 바꿀 때마다 굉장히 큰 패널티가 주어지는데, 그 패널티가 랜덤하게 들어가면 실제 메모리 속도는 500분의 1까지 떨어져요. 제가 측정을 해 본 바로는, CPU에서는 300에서 400으로 들어가고요, GPU 쪽은 측정 안 해봤지만 일반적으로 알려진 게 한 500정도 각오를 하라고 되어있어요. 그래서 랜덤 하게 접근하는 것을 쓰레드 32개가 500번을 한다, 그런데 32개가 운이 없어서 다 다른 주소에 있고 다 캐시에의 도움도 못 받는다, 그러면 메모리 접근 하나로 32곱하기 500, 얼마일까요? 만 정도, 만 클락 정도가 박살 나는 거에요 그냥. 그래서 굉장히 많은 비용이 들기 때문에 그런 것들을 피하기 위해서 Shared Memory에 순차적으로 데이터를 가져오거나 일정 메모리를 복사해서 쓰는 용어들이 있어요. 이것도 이 두 가지, 앞의 쓰레드하고 이 Shared Memory 두 가지가 가장 쓰기가 힘든 부분들 중의 하나에요. 이것도 다 페이지 다 설명을 해버렸으니 넘어가겠습니다. GPU 코딩은 끝났습니다. 직접 문서 배열 찾아보면 쉬운 것들이 있을 거에요. 모르시는 게 있으면 저한테 물어보시면 됩니다. 저도 잘 모르지만 제가 배운 것을 몇 가지 링크는 드릴 수 있습니다. 그래서 이제 GPU 프로그램을 간단하게 설명했으니까, 뭐를 GPU에 올려야 될까? 사실 저는 예제를 만들면서 이것저것 많이 만들어봤어요. 그런데 심지어 만들면서 50배 정도 느려진 게 있어요. A스타 서치 알고리즘이라고 우리 실장님이 지나가면서 너 GPU 코딩 한다면서 요즘에? A 스타좀 만들어봐, 라고 하시는 분이시거든요. 휙 던졌어요, 그래서 아, 그쯤이야, 이러면서 만들었는데 알고리즘 안 바꾸고는 기본 알고리즘으로는 이게 속도 상향이 전혀 안되더라고요. 구조상 A스타는 자기가 전에 밟았던 셀, 전에 밟았던 스텝의 값을 가져와서 다음 값한테도 전달을 해 줘야 해요. 계속 프로퍼게이션이 일어나는데, GPU가 쓰레드가 아무리 많아도 프로퍼게이션이 나는 애들을 전부 다 한꺼번에 덩어리로 계산할 수가 없어요. 왜냐 하면 저는 512 비트맵을 가지고 했었거든요. 그래서 쓰레드를 아무리 많이 만들어도 그것을 다 처리하기에는 좀 부담이 되더라고요. 다 처리해도 어쨌거나 전에 받은 값을 또 받아서 옆에 전달해야 되기 때문에 앞의 쓰레드가 끝날 때까지 다음 쓰레드가 작동을 못하게 되어있어요, 여기는. 엔디비아 같은 데에서 그런 케이스르르 잘 풀기 위해서 맵을 쪼개서 계산한다든지 하는 약간 편법스러운 A스타에서 약간 벗어난 거에요. 그러니까 무슨 A스타, 이런 식으로 이름을 바꾼 경우가 있는데 기본적으로 A스타는 저는 못해봤어요, 일주일 동안 주무르다가 포기했어요. 실장님, 못하겠습니다. 거봐, 쓸데없잖아. 언젠가는 해서 서버에다가 올리겠습니다. 그거 외에 폰트 렌더링, 한 두 배쯤 빨라지는 게 있었는데 이번에 뺐습니다. 그게 너무 없어 보입니다. 여기는 기본적인 예제 하나 하고, 제가 3D 관련 하나 가져왔어요. CPU에서 GPU로 옮길 때 중요한 것, 루프를 많이 돌고 있다. 순서를 바꾸거나 랜덤으로 실행을 해도 잘 돌아간다, 메모리 사용량이 적다. 이 세 가지만 일단 눈에 불을 켜고 찾으면 됩니다. 이런 경우가 게임에서는 왕왕 있고요. 그리고 물리 엔진도 이런 특징이 있기 때문에 GPU를 많이 올리고 있죠. 자, 이제 예제로 넘어가겠습니다. 첫 번째 것은 기본적인 거에요. GPU 코딩 하면 제일 먼저 나오는 그냥 이미지 프로세싱인데, 이것은 속도보다는, 속도는 물론 빨라져요, 많이 빨라지는데 저는 이것을 하면서 코딩이 얼마나 쉬워지는지를 좀 지적을 하고 싶었어요. 제가 Bicubic Test를 만든 것은 사실은 꿀뷰에서 이미지 확대를 하면 옵션이 있어요. 리얼리스트, 리니어, 그 다음에 바이큐빅, 근데 꿀뷰에 있는 바이큐빅이 틀렸어요. 틀린 건 아니고, 바이큐빅이라는 표현은 픽셀을 네 개를 읽어서 보관하겠다는 뜻인데, 네 개를 읽어서 보관하는 방법이 여러 가지가 있어요. 그런데 그 중에서 포토샵이나 paint.net 같은 데서 쓰는 것들이 Uniform Cubic B-Spline Curve를 쓰더라고요. 그런데 꿀뷰에서 쓰는 바이큐빅은 어디서 인터넷에서 바이큐빅 인터브레이션 치면 나오는 제일 처음 똑 같은 거 쓴 것 같더라고요. 만들어보고 깊은 영향을 드려야지, 생각을 하고 만들었는데 만들어놓고 안 드리고 그냥 있어요. 그냥 SSE 테스트 용으로 제가 짰어요. 그래서 SSE 발표할 때 쓰려고 했는데 안 떴는데, 숫자가 나올 거에요. 그리고 두 번째 거는 이번 발표를 결정하게 된, 제가 GPU를 공부하면서 아, 이것은 발표를 해야겠다, 그러고 예이고요. Tiny라고, DIRECT X의 예제를 보면 머리 삐쭉삐쭉한 여자애가 있어요. 그 여자애가 걸어가는 애니메이션이 있고, 그거 예제를 바탕으로 했어요. 사실은 저희 게임 엔진에 있는 데이터를 끌고 왔었는데 실장님이 NO했어요. 절대 못 갖고 나간다. 그래서 Tiny로 바꿨고요. 이것은 Uniform Cubic B-Spline에 대한 간단한 수식이고요. 이것은 그냥 읽어보시고요. 여기서 핵심은 다음 페이지에 있어요. 보여드릴게요. 우리가 정 가운데에 있는 픽셀을 읽어오고 싶어요. 이것을 Interpolation에서 확대를 해서 보관으로 읽고 싶은 거에요. 그럴 때에는 기본적인 알고리즘은 자기 앞에 두 개, 뒤에 두 개 픽셀이 필요해요. 그래서 먼저 X 축으로 보관을 해요. 이렇게 네 개를 읽어서 보관을 해요, X를. 그리고 쭉쭉 해서 보관을 해요. 그래서 X 축에 대한 보관이 끝나면 Y 축에 대한 보관을 한 번 더 해요. 오른쪽에 쓰여 있는 대로 Y가 0, 1, 2, 3 해서 픽셀을 16개를 읽어서 보관을 한 결과를 다시 똑같이 복원을 해서 쓰는 게 Uniform Cubic B-Spline이에요. 자, 봅시다. 이것은 옵티마이징 전혀 안 한 거고요. 확대를 하면 확대했을 때 셀이 예쁘게 보관이 된다, 그냥 그런 거에요. 이것은 C로 짜이는 기본 코드에요. 코딩하면 이 정도 돼요. 기본적으로. 그래서 이것을 제가 GPU로 옮겼어요. 짠. GPU로 옮겼는데 코드 양이 딱 이거에요. 물론 Direct X 초기화 하고 하는 코드가 있는데 이것은 보기 나쁘니까 제가 정리를 해 봤습니다. 기본적인 Interpolation 하는 코드에요. Interpolation하는 코드인데 여기서 두 개가 다른 것을 비교를 해 놨어요. 왼쪽은 CPU 코드이고 오른 쪽은 GPU 코드에요. 왼쪽에서 가운데 W값하고 px py라고 계산된 값은 카피 앤 페이스트를 그냥 했어요. 다시 맨 위에까지 카피 앤 페이스트를 한 다음에 중요한 부분을 고쳤죠. 그리고 C	코드 맨 밑에 있는 차이점은 픽셀 넘어가는 메모리를 침범하기 때문에 메모리를 침범 안 하게 if 문으로 이렇게 막아 줬어요. 오른 쪽은 GPU가 알아서 해 줘서 그냥 안 넣었어요. Ok. 그리고 오른쪽 밑에 있는 것은 실제로 CPU에서 계산할 때 CPU 루프 안에 있는 계산인데 쓰레드로 이것을 분사한다고 하면 루프 안에 있는 계산의 각자를 보내줄 수가 없어요. 그래서 각 쓰레드가 하게 CPU 루프에 있는 계산을 이쪽으로 넘겨줬어요. 여기는 비슷한 게 없기 때문에 놔뒀습니다. 그래서 왼쪽은 CPU 루프에요. 이 밑에 있는 구조체는 참고하라고 그냥 넣어놓은 거고요. 이게 어떻게 돌아가나 보여주려고. 루프에서 여기 보면 V하고 DV하고 DU, G값 그런 게 있는데 오른 쪽에는 그런 게 없어요. 아까 그 쉐이더 맨 밑에 있는 것들로 넘어갔어요. 이 루프 안쪽에서 제가 이것도 나름 최적화 하겠다고 했기 때문에 여러 번 계산 안 해도 되고 Y값 같은 경우는 한번만 계산해서 그냥 넘기고 그렇게 해놨는데 그게 각 쓰레드에서 돌게 되어있어요. 그래서 코딩은 이것으로 끝났어요. 포팅은. 초기화하고 메모리 그런 코딩이 좀 있는데 기본적인 알고리즘은 이 정도로 끝나요. 아, 이거. 제가 해놨는데 까먹었네요. 여기 아까 루프에 있던 것들, 이 V하고 DV 요기 밑으로 내려갔고요, 이렇게. U 관련해서도 이 밑으로 내려갔습니다. 쓰레드 안에 하이레벨 쉐이드를 의지하는 쪽으로 내려갔습니다. 그래서 충격적인 것 먼저 보여드릴게요. 이것은 지금 제가 너무 빨라서 루프를 10회를 돌았어요. GPU쪽을. 숫자를 0을 하나 빼주세요. 그래서 벤치마크 하려고 측정을 하는데 속도가 너무 빨라서 0을 하나, 그러니까 10번 루프를 돌게 바꿔놓은 거에요. 그래서 실제로 얼마였지? 21MSEC 정도 걸리는 거에요. 그래서 10번 돌아가는 겁니다. 죄송합니다. 소스 코드 다 드리겠습니다. 실제로 이미지 디폴더 보면 픽셀 단위로 약간 1비트 정도로 차이 나는 게 있어요. 왜냐 하면 두 개 FPU가 살짝 다른 경우가 있기 때문에 문제가 생길 수 있지 않을까 생각하는데 그것은 그래픽카드 밴더에 따라 달라요. 엔비디아 같은 경우는 자기네 프릭션을 정확하게 기록을 하고 있어요. 자기네가 정확히 몇 비트까지 정확도를 유지할 수 있다. 그리고 더블을 쓸 경우 얼마까지 유지할 수 있다, 그것을 공개를 하고 있고요. 계산 결과가 어떤 경우에 어떻게 나오고 어떤 경우에 어떻게 나온다, 그런 것까지 자세하게 기술을 하고 있고요. 인텔은 그저 그렇더라고요, 아직. 그런데 우리 쓰는 것들이 그렇게 정밀한 수학 계산까지는 아니니까 1미리비트 정도는 괜찮을 것 같아요. 그래서 실제로 아까 100미리 정도 걸렸죠, 110미리. 그런데 110 미리 걸리는 게 2미리 까지 줄었어요. 한 50배까지 빨라졌어요. 그러나, 저는 CPU 최적화를 사랑하는 사람입니다. 열심히 찾았습니다. 알고리즘 적으로 최적화 할 것을 찾고요. 그 다음에 SSE를 써서 최적화하는 것을 찾았어요. 그리고 그것을 똑같이 적용을 해봤어요. 아이고, 왔다 갔다 해서 죄송합니다. SSE 버전 한 번 보여드릴게요. 이것도 10번 돌렸어요. 제가, 너무. 이것은 최적화한 버전인데요. 이것은 10번 돌렸기 때문에 지금 37미리가 걸리는 거에요. 실제로 한 3배 정도 빨라졌어요, 아까 그 100미리 짜리보다. 그리고 SSE를 하면 8.8미리까지 떨어졌어요. 그래서 SSE까지 써가지고 알고리즘적으로 추적하라고, 그 다음에 CPU에 있는 SIMD를 끌어왔으니까 한 12배~15배 정도 빨라졌어요. 15배는 안 될 겁니다. 12배 정도. 그런데 GPU같은 경우는 훨씬 빠르죠. 죄송합니다. 이게 최적화된 버전입니다. 아까 보여 드린 게. 제가 다른 버전을 갖고 왔네요. 이게 최적화 된 거고요, 최적화 안 했을 때는 2.8미리 정도 걸리는데 버전을 잘못 갖고 왔네요. 짠. 그래서 제가 PT에 숫자를 적어놨으니, 이것은 간단하게 보여 드릴게요. 최적화하기 위해서 제가 알고리즘을 어떻게 정리했는지, 아까 네 개씩 픽셀을 X 방향으로 읽는다고 했는데 모든 X방향으로 먼저 다 계산을 해요. 임시 버퍼를 다 집어 넣어요, 그거를. 네 줄 어치를. 그래서 가로로 네 개를 하고, 그 다음에 왼쪽에서 오른쪽으로 쭉 훑으면서, 이렇게 훑으면서 계산 되어있는 버퍼를 써요. 그 다음에 중요한 것은 그 다음 라인으로 넘어갈 때 이 하나만 딱 버리고 저는 그냥 SHIFT를 했어요. 아니, SHIFT도 안 하고 포인터로 이 배열을 갖다 썼어요, 그래서. 한 대를 빼고, 밑에 하나만 추가를 해요. 그래서 X축으로 한 번만 Interpolation을 하고, 그 다음에 다시 가서 선을 왼쪽에서 오른 쪽으로 쭉 그어요. 그래서 아까 Interpolation을 X방향으로 네 번 하고, Y 방향으로 한 번 해야 되는데 실제로 1:1 비율일 때 Interpolation을 X방향 한 번, Y 방향 한번만 하면 되고, 두 개 중간 같은 경우에는 두 번씩 쓸 수 있기 때문에 X방향 0.5번, Y방향 1번, 그런 비용이 들어요. 그래서 이것은 최적화에서 SSE로 최적화를 최대한 했을 때의 속도보다 GPU로 대충 짰을 때, 카피해서 넣어서 짰을 때가 3.7배 빨라요. 이것도 인텔 내장 GPU에서. 조건이 별로 없어요. 그냥 내장 GPU에서 코드, 아까 몇 줄 안됐어요. 이렇게 해서 실제로 바뀐 것은 이렇게 스무 줄, 그 다음에 버퍼 채우는 거, 버퍼 채우는 것은 좀 있습니다. 좀 규모가 있지만 하나 만드는 것은 괜찮습니다. 그리고 최적화 코드를 보여드릴게요. SSE의 최적화를 하려고 짠 코드를 만들어서 세 페이지로 했어요. 그리고 다 in tree 식으로 짰기 때문에 in tree 식도 여기다가 매크로까지 써가지고 보기는 편해요, 실제로. 진짜 in tree 식이 되면 더 지저분해져요 근데. In tree 식을 갖다가 우리 오퍼레이터에 매핑 되는 것들은 매핑을 하고, 안 되는 것들은 그냥 썼는데 이것은 제가 이런 코드를 주면 사람들이 못 읽겠다고 그냥 그러더라고요. 이게 모르겠다, 니가 해라. 항상 그래요. 그런데 GPU 코드는 항상 이 정도로 나와요. 아까 썼던 함수들이 몇 개가 있거든요? W라든지, 아니면은 PX 같은 것들. 그래서 픽셀 가져오는 거, 그런 것들을 그냥 써요. 그런데 이것으로 그냥 끝나요. AWT도 훨씬 좋고 알고리즘 물론 3D 개념이 있는 분들이 읽어야지 알고리즘만 알면 해석하기 훨씬 좋아요. SSE 좋아하지만 사실 디버깅하라면 이쪽을 훨씬 더 저는 권할 수 있을 것 같아요. 벤치마크 제가 돌렸던 거고요. 제일 좋은 게 680인데 그래픽을 찍어보니까 안 나오더라고요. 그래서 배수로 그냥 계산을 해 봤어요. 몇 배나 빨라지나? 그리고 1배 확대, 2배 확대 해서 하나 재미있는 게 여기 GTS 440이 있어요. 제가 가장 낮은 그래픽 카드 군이라고 놨어요. 그래서 이거보다 낮은 게 있으면 좋겠는데 회사에서는 제일 낮은 거라고 이것을 사줬어요. 제일 낮은 거보다 인텔 내장이 더 빠른 경우가 나왔어요. 이것은 두 가지로 보실 수 있는데 정말 인텔 GPU가 좋을 수도 있고, 인텔 GPU는 PCI 박스를 안 쓰고 자기 CPU 내에 있어요. 그래서 아직은 데이터를 주고 받을 때 복사를 해야 되지만 그래도 가까워요. 밖에 있는 애들보다. 그리고 AMD가 지금 큰 소리로 자랑하고 있는 게 우리는 안에 끌고 들어왔기 때문에 가장 빠른 결과를 쓸 수 있다, 그리고 CPU와 GPU가 주고받는 것을 좀 더 자주 할 수 있다, 그런 얘기를 하는데 저는 이게 그 것을 가장 잘 보여주는 예제라고 보여져요. 생각보다 A가 잘 나왔습니다. 인텔 훌륭합니다. 일단 Tiny Viewer 예제를 먼저 보여 드릴게요, 제가. 먼저 보는 게 좋을 것 같아요. 뭐, 천 마리의 애니메이션을 시켰어요. 천 마리 애니메이션 시켰고, 4천 마리. 4천 마리가 아니죠, 4천 명이죠. 4천 명을 렌더링을 시켰어요. 그런데 지금 듀얼 스크린이라서 조금 버벅이는데 50미리 정도 쓰고 있어요. Direct 11 인스턴싱을 써서 했고요. 애니메이션은 각자 다른 시간 축을 갖고 있어요. 다 조금씩 시간을 일부러 어그러뜨려 다르게 했고, 제가 애니메이션 파일을 구했으면 좋겠는데, 회사에 있는 리소스는 풍부한데 하나도 못 들고 나와서 얘 거 로드해서 그냥 썼는데 애니메이션을 여러 개를 써도 퍼포먼스는 차이가 별로 없어요. 왜냐 하면 다 랜덤하게 접근하기 때문에 캐시의 도움을 거의 못 받아요, GPU는 사실. 그래서 애니메이션이 좀 많이 들어가도, 다양하게 들어가도 얘네들이 다 실행을 할 수 있어요. 그리고 코드 상으로, 이것은 본 업데이트 하는 코드에요. 예제가. 본 애니메이션 업데이트하는 컴프쉐이드 코드이기 때문에 본 하이라키가 달라도 실행이 되고 X본 개수를 64개로 한 다음에 뭐 128개로 잡고 그 본 개수 안에서만 포맷에 맞춰 데이터를 넣어주면 다른 애니메이션도 다 업데이트를 할 수 있어요. 물론 로컬리티 문제는 조금 있어요. 로컬리티가 높을수록 좋은 건 사실이에요. 그런데 생각만큼 퍼포먼스가 많이 떨어지지는 않더라고요. 사실은 올리면 계속 올라갑니다. 인텔 내장은 좀 비상해서. 이렇게 줄이기도 하고. 타블랫은 아니지만 서피스 프로에서 지금 실행하고 있는 겁니다. GPU 따로 없고요. vertex shader에서 이렇게 본 일관성을 유지하는 예제는 많이 있었어요. 그런데 제가 원한 건 그런 게 아니라 실제 우리가 쓰는 데이터를 써보고 싶다, 키 프레임 데이터. 키 프레임 데이터는 데이터 간격이 랜덤해요. 어떤 것은 첫 프레임만 들어있고, 첫 프레임하고 끝 프레임만 들어있고, 어떤 것은 매 프레임마다 들어있는 경우도 있고, 매 프레임 있다가 중간에 없는 것도 있고. 그런 것들을 써보고 싶었고요. 그 다음에 가능한 우리가 쓰는 데이터하고 똑 같은 형태로 작업을 해 보고 싶다. 이 예제는 CPU랑 GPU랑 코드를 두 벌을 만들고요, 두 개를 번갈아 가면서 진행을 해 볼 수 있어요. 두 개가 동일한 본 매트릭스 버퍼의 도움을 쓰고요. 본 매트릭스를, 실재로는 본 매트릭스가 아니라 코터니언하고 포지션인데, 본 매트릭스를 vertex shader에 똑같이 넣어요. 똑 같은 vertex shader이기 때문에 원하면 중간중간에 스위칭 하면서도 전혀 문제가 없어요. 이것은 우리 소스 코드로 대충 제가 적어봤어요. CPU에서 하는 일은 키프레임 데이터를 자기가 업데이트 할 본을 찾은 다음에 걔네들을 업데이트 한 작업을 업데이트를 돌아요. 그래서 애니메이션이 되게 전체 본이 60개라면 제가 쓴 데이터는 본이 64개인데 애니메이션은 41개더라고요. 41개를 루프를 넣으면서 업데이트를 해요. 로크 업데이트를 하고 그 다음에 본 업데이트인데 이것은 로컬 본을 월드 본으로 바꾸는 작업이에요. 그래서 패런트하고 월드하고 곱해가지고 월드를 자신한테 복사해 넣는 작업, 그리고 마지막에는 그것을 렌더링하기 위해서 스킨하고 맵핑하고. 렌더링에 따라 다른데 어떤 것은 월드 매트릭스에 다 넘기는 경우도 있는데, 대부분 제가 쓰는 것들은 스킨 매트릭스 목록이랑 본 목록이랑 크기가 좀 달라요. 스킨이 더 작더라고요. 그럼 스키닝에 쓰는 참조하는 목록하고 스위칭이 안 되는 애들이 있어요. 월드 매트릭스에는. 그러니까 월드 본 하이라키에는. 그래서 걔네들을 다 잘라내고 최적화해서 쓰는 경우가 많더라고요. 그리고 DirectX9 쓰시는 분들은 그거 안하면 어차피 안해도 부족한데 그것까지 넣어버리면 폭주하기 때문에. 그래서 아까 봤듯이 루프 도는 것을 GPU에 그냥 매핑을 해요. 이렇게, 이렇게, 이렇게. 그런데 슬프게도 제가 두 번째로 얘기했던 게 월드 매트릭스 하기 위해서 부모랑 자신을 곱해서 넣어야 되는데 그 작업이 앞에 했던 실행 결과가 필요해요, 항상. 그래서 간단히 얘기를 하면 첫 번째 본이고요. 밑으로 내려가면서 본이 올라가는데 이렇게 밑으로 하나씩 훑어가면서 위의 본들하고 이렇게 곱셈을 해서 월드 매트릭스를 해요. 위의 값들을 참조를 해서 받아간단 말이에요. 그래서 쉐이더에다 넣으면 이렇게 들어가 버려요. 순서대로 넣으면요. 그래서 본이 64개인데 제가 처음에 만들었을 때 이 64개 루프를 돌리니까 이득이 전혀 없더라고요. 더 느리더라고요, CPU보다. 그래서 좀 고민을 하루 정도 했어요, 이것 때문에. 어떻게 하는 게 제일 좋을까를. 곱하는 것을 했는데 늘었다. 그래서 얘네를 폈어요, 평평하게. 얘네를 테이블을 만들어가지고 얘가 몇 번째 단계에 곱해질 수 있는가를 추출을 해가지고 걔네들을 쓰레드에 묶어 넣었어요. 테이블을 추가로 만들었죠, GPU 용으로. 그래서 실제로 본이 64개에요. 하이라키를 다 곱해야 되기 때문에 64개를 무조건 곱하게 되어있는데, 제가 IF문 하이라키 분석해서 이렇게 테이블을 만들어서 했더니 17개로 줄어들더라고요. 그런데 17개 중에 맨 마지막 노드는 솔직히 안 써요, 더미들이 다 붙어있기 때문에 안 쓰는데 그냥 계산을 해 줬어요. 그런데 최적화를 하겠다면 맨 마지막 거 몇 개를 이렇게 스키닝에 쓰지 않는 애들은 잘라 버려도 상관없을 것 같아요. 그러면 속도가 더 빨라지겠죠. 그래서 모양은 이렇게 되었어요. 왼쪽에 있는 게 우리가 처음 계산한거. 여기 보면 파란 색으로 있는 게 실제로 우리가 키 프레임 애니메이션 업데이트 하는 코드에요. 키 프레임 애니메이션 업데이트 하기 위해서 41개, 그런데 쓰레드가 32 단위로 쪼개지기 때문에 64 빼기 41하면 33개가 놀게 돼요. 제가 회색으로 칠해놨고요. 밑에는 아까 제가 17단계라고 했는데 최대 미스가 7칸이고요. 밑으로 17칸이 내려가요, 근데. 얘네들을 대충 열일곱 칸 그리기가 너무 복잡해서 이렇게 줄여서 해 놨고요. 그 다음에 맨 밑에 스킨 업데이트 하는 것까지 구분을 해 놨어요. 길이를 정확히 쟀습니다. 그런데 GPU 프로그램 할 때 쓰는 게 Group Sync라는 게 있는데, Group Sync를 써가지고 왼쪽으로 다 몰아요. 왼쪽에 몰고 대신 일반적인 프로그램 할 때는 쓰레드가 자기가 몇 번째 캐릭터를 담당한다는 것을 알고 있어요., 그런데 그것을 알고 쓴 게 아니라 동적으로 계산하면서 쓰는 거에요. 그래서 내 쓰레드, 이거 작업할 때 쓰레드를 예전에는 192개였었는데 좀 줄였어요, 최적화 하느라고. 그런데 실제로 쓰레드를 500개쯤, 512개쯤 쓴 다음에 자기 쓰레드 개수를 지금 작업할 애니메이션 트랙 수나 그런 것으로 나눠요. 그래서 왼쪽으로 다 몰아요. 이것은 좀 더 자세한 것은 일단 왼쪽으로 몰아요. 그럼 무슨 생기냐 하면 오른쪽에 통째로 노는 쓰레드들이 생겨요, 이렇게. 전혀 안보이네요. 여기 오른쪽 빨간 네모로 되어있는 애들이 놀고 있는 쓰레드들이에요. 그래서 작업이 하나도 없이 노는 쓰레드들은 실제로 GPU안에서 시간을 쓰지 않고, 들어가지도 않아요. 자기가 앞의 루프, 같이 가는 애들이 끝날 때까지 그냥 자는 쓰레드고, 그 시간 동안 다른 일하는 쓰레드들이 그 자리를 쓸 수 있어요. 그래서 왼쪽에 그냥 처음에 막 짰을 때 하고, 오른쪽에 그것을 최적화를 해 줄 수 있을 때 쓰레드라 하나, 둘, 셋, 실제로는 반 이상이 쓰레드가 줄었어요. 실제 실행 시간은 거의 2배 이상 차이가 나요. 이렇게 최적화를 했을 때. 그래서 처음에 본 매트릭스 월드에 곱하는 거랑 이거 최적화를 쓰면 속도가 확 올라가더라고요. 마지막, 이것은 CPU, GPU 다 해당이 되는 건데요. 매트릭스를 다 계싼을 시키니까 매트릭스 예산이 메모리 밴드위스를 많이 먹어요. 왜냐 하면 프론트 14를 쓰기 때문에 64 바이트에요, 64바이트를 막 4096 곱하기 64개를 업데이트를 하다 보니까 이게 부하가 걸리니까 포지션하고 로테이션으로 바꿨어요. CPU 앞에서 포트포인트 계산은 늘지만 실제로 데이터 양은 줄었어요. 이것은 양 쪽이 다 빨라졌어요, CPU, GPU. 그렇지만 이쪽으로 바꿨어요. 이것은 취향대로이고. AoS 와 SoA 이것은 어레이어블 스트럭쳐하고 스트럭쳐블 어레이어. 다큐먼트를 보면 스트럭쳐블 어레이어를 많이 쓰라고 해요. 스트럭쳐블 어레이어가 어떤 거냐 하면 우리가 X, Y, Z를 스트럭쳐로 묶는 게 아니라 X의 배열, 프로트 X의 배열, 프록트 Y의 배열, 프록트 Z의 배열. 이렇게 배열로 한 컴포트만 있는 배열을 스트럭쳐의 멤버만큼 갖고 있는 거에요. 그런데 제가 이것을 써서 속도가 나는 GPU가 있고 안 나는 GPU가 있어요. 이게 안 나는 애들은 속도 패널티가 너무 커요, 이게. 그래서 내장에서는 이것을 안 쓰는 게 좋더라고요. 왜냐 하면 제가 스트림을 좀 많이 써요. 스트림도 7개는 기본으로 써야 돼요. 왜냐하면 포지션 3개, 코터니언 4개, 그리고 읽어온 애들도 애니메이션 계속 읽어오고 하니까 실제로 스트럭쳐블 어레이를 쓰려면 메모리 읽고 쓰는 스트림을 한 열 몇 개를 제가 관리할 수 있어야 돼요. 그런데 GPU가 열 몇 개를 관리할 수 있으면 속도가 나는데 못 쓰면 모든 스트림이 매번 맨날 업데이트하듯이 속도를 잃어버리게 돼요. 그래서 저 같은 경우는 이 예제는 그냥 어레이어블 스트럭쳐로 갔어요. 내장을 하신다면 그것도 좀 고민을 해야 될 것 같아요. 숫자 너무 많습니다. 그래프로 보겠습니다. 이것은 이제 좀 극적인 효과를 보여드리려고 Tiny View에서 인덱스 개수를 하나로 줄이고서 숫자를 뽑아본 거에요. 여기 보면 맨 밑에 파란색 그래프는 이제 렌더링 비용. 렌더링 비용은 다 뺐어요, 제가, 일부러. 그리고 GPU 업데이트를 했을 때 그래프가 보라색이에요. 그리고 이 빨간색은 CPU에서 애니메이션 계산을 안 시키고 본 매트릭스를 복사해 넣는 작업만 했어요. 우리가 렌더링할때 본 매트릭스를 복사해서 넣어줘야 되잖아요. 복사해 넣는 작업이 얼마나 비용이 드나 그것을 보고 싶었어요. 그리고 마지막에 초록색은 애니메이션을 다 틀어준 거에요. 그래서 속도 차이가 굉장히 많이 나요. 유니세크 단위고요, 이게. 그래서 1024개, 2048, 4096, 8192 그런 식으로 숫자가 올라가는 거에요, 이게. 그래서 계산 비용이 실제로 16000개, 맨 오른쪽 비용이 1600개인데요. 본 애니메이션을 보관한 키 프레임을 애니메이션을 하나씩 틀었을 때 한 14미리 정도 걸려요, GPU에서. CPU에서 그것을 하면 50미리가 넘어가요. 그러면 20프레임 이하로 벌써 떨어져 버렸죠. 그리고 CPU에서 하면 CPU 사용량이 많습니다. 잠깐 CPU 사용량에 대해서 보여드릴게요. 얘는 아직 돌고 있었네요? 내장 그래픽 카드, 렌더링이 약해서. 짠. 이건 GPU렌더링을 하고 있는 상태에요. GPU 렌더링을 하고 있을 때는 CPU 사용량이 거의 없어요. 그런데 이것을 CPU로 바꿀 경우에 제가 두 번째 코어로 다 모았어요. 잘 나오죠? 애니메이션을 저 두 번째 코어로 다 몰았는데 애니메이션 계산을 하기 위해서 렌더링을 좀 약하게 했어요. 애니메이션 계산을 하기 위해서 CPU가 거의 풀로 사용이 돼요. 그리고 렌더링을 걸면 GPU가 렌더링 하는 게 더 느릴 경우에는 CPU가 약간 숨을 틀 수 있어요. 그렇지만 애니메이션이 좀 많아지면, 그러니까 흔하게 5미리세크, 10미리세크까지 업데이트 하는 데에 쓰이는 경우가 있어요. 물론 코드가 좀 더 복잡하지만 저는 대부분 GPU에 넘어갈 수 있다고 생각을 해요. 그래서 일부러 두 번째 코어에 다 몰았습니다. 뭐 멀티쓰레드 같은 거 쓰셔도 돼요. 어쨌거나 CPU 쓰는 것은 사실이에요. 그리고 저는 아주 많은 캐릭터가 나오는 게임을 만들 경우에 어떻게 해야 될지를 항상 생각하고 있기 때문에 한 천대천 정도 싸운다고 했을 때 애니메이션을 어떻게 할 것인가. 우리가 과연 그런 MMORPG 게임을 만들 수 있을까? 물론 천대천 싸우는 게임도 있기는 하지만, 벌써. 쾌적환 환경으로 할 수 있을까? 참 불편하네요. 죄송합니다. GPU 사용량이 이렇게 되고요. 거의 동일합니다. 뭐 약간씩 오류가 있을 때가 있더라고요. 좀 기분이 안 좋은데. 오차, 약간씩 오차가 있을 때가 있어요. 제가 보기에는 MBDI들은 없는 것 같은데, 참. 자, PT로 돌아가겠습니다. 그래서 GTS 440, 680하고 비교를 해 봤어요. 그래서 여기 밑에 바닥에 깔려있는데 GTS 680인데 이 맨 밑에 세 개는 GPU만 썼을 경우, 아니면 렌더링 애니메이션 안 틀었을 경우이고, 위에 튄 것들은 CPU가 튄 것. 그래서 GTS 440은 좀 아쉽게 렌더링 파워가 약해요. 그래서 CPU들이 애니메이션 업데이트 하는 동안 렌더링이 안 끝나면 CPU가 놀 수가 있어요. 그래서 다음에 그림에 해 봤어요. 이게 일반적인 GPU가 성능이 좋을 때가 위의 것이에요. 애니메이션을 하면 CPU에서 애니메이션을 막 업데이트를 해요. 그것을 GPU로 카피해요. 그럼 카피를 한 것을 GPU가 렌더링을 해요. 그리고 렌더링 하고 시간이 남으면 CPU가 끝나기를 기다려요. 이게 일반적으로 성능이 안 좋은, 그러니까 그래픽은 가볍고 성능이 CPU 성능이 떨어질 때 이런 경우가 나요. 그런데 CPU 성능이 좋으면 CPU한테 약간 부담이 계속 많이 가는 거에요. CPU가 계속 울렁울렁거리고, CPU를 많이 써야 돼요. 그리고 만약에 GPU가 좀 떨어지면 어차피 프레임이 안 나기 때문에 그래픽을 낮춰야 돼요. 그것은 그래픽 쪽은 제가 어떻게 해 줄 수 있는 건 아니에요. 그래픽을 낮춰야 돼요. 그런데 그래픽을 낮췄을 때 CPU는 고정적인 시간을 먹기 때문에 최대한 낮춰줄 수 있는 게 좋아요. 제가 밑에 한 거는 GPU를 이번에 짠 거에요. 제가 GPU로 해서 CPU 사용량을 쟀을 때 2%정도 먹어요. 애니메이션 하면. 왜냐 하면 여기서는 전체 시간하고 애니메이션, 지금 쓰고 있는 트랙만 업데이트 해줘요. 그리고 할 게 없어요, CPU가. 그 다음에 들어오면 콜만 한번 해주고 CPU는 하는 게 없기 때문에. CPU는 한 2% 정도 쓰고 자고 있어요, 해당 CPU가. 그런데 GPU는 위에 일할 때보다 더 빡세게 일을 해요, 일반적으로. 쉴 새 없이 일을 해요. 그렇지만 대기를 타지 않아요. 그리고 하나 더 장점이 여기 빨간 색으로 카피라고 있잖아요. 이게 CPU 메모리에서 그래픽하드 메모리, 또는 내장 그래픽카드 같은 경우는 유저 공간에서 그래픽 카드 공간에 메모리를 복사하는 비용이에요. 그런데 인텔은 이게 내장 그래픽 카드 경우는 이게 어마어마하게 비싸요. 생각보다 많이 비싸요. 왜 그런가 생각을 해봤더니 우리가 내장 그래픽 카드 같은 경우는 메인 메모리 밴드윗을 다 같이 쓰잖아요. 그런데 공간을 옮겨야 되기 때문에 메인메모리 안에서 카피를 해야 돼요. 그 시간이 생각보다 많이 비싸더라고요. 그리고 한번 복사하는 게 아닌 것 같아요. 두 번쯤 복사를 하는 것 같아요. 유저 공간에서 카피를 하고, 다시 GPU가 그 커넬 공간에서 카피를 작업을 해 가는 것 같아요. 그래서 실제로 인텔 CPU같은 경우는 그림이 이렇게 안 나오고 카피가 너무 커가지고 GPU 렌더링 하는 게 항상 빨라요. 무슨 일이 있어도 빨라요. CPU 사용량도 높고. 결론입니다. 이게 GPU 코딩을 하는데 우리가 알아야 되는 것. 아, 방금 얘기하다가 빠뜨렸는데 지금 헤테로지니어스 발표를 한다고 해놓고 GPU 얘기만 계속 했는데 지금 이 다음 단계에 나오는 GPU들은 메모리 복사를 필요로 하지 않는 단계로 넘어가고 있어요. 공유 메모리를 쓰고 있으면 포인터를 직접 옮길 수 있어요. 이번에 쿠다는 약간 꼼수를 썼지만 nVIDIA 것도 컴퓨트 펌패티비를 5.0 이하에서는 포인터로 넘기면 그 포인터를 쿠다에서 그냥 받아 쓸 수 있어요. 그리고 AMD도 다음에 나오는 GPU에서 똑 같은 포인터를, 유저 공간의 포인터를 공유할 수 있도록 하고 있어요. 카피 비용도 아예 없어지겠죠. 그런데 그래픽 쪽은 아마 안 없어질 거에요. 그래픽 쪽은 공간이 다르기 때문에 안 되죠. 그런데 컴팻 쉐이더 같은 데에서는 카피한 작업이 없어지는 거에요. 그리고 두 번째 거 중요해요. 클럭은 CPU의 4분의 1에서 5분의 1, 그리고 실제 IPC를 보면 5분의 1에서 8분의 1정도 된다고 저는 짐작을 해요. 그래서 많이 느려지면 50분의 1까지 느려진다. 이것은 넘어가겠습니다. 읽어보시고요. 자, 끝났습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
