yuchi's Development Home
글 수 201
이번에 CUDA충돌처리 모듈을 만들면서 깨닫게 된 몇 가지들.
예전 프로젝트(프로젝트 엡실론)에서 멀티스레드와 SSE어셈을 떡을 쳐서 서버기반에서도 사용가능한 충돌처리 코드를 만들었었다. 세 번의 유져 테스트에도 무사히 작동했고 꽤 잘 만들었다고 생각했다. 근데 그 코드에는 중대한 결함이 있었다.
1. 기본적으로 계산 코드가 너무나 비효율적이었다..불필요하게 복잡하고 느리다. 난 수학에 자신이 없었고 그래서 다른 사람에게 코드 작성을 맡겼고 나중에 C수학함수 코드를 받아서 어셈으로 최적화하고 충돌처리 자료구조를 만들어넣었다.
2. 충돌삼각형 검출에서는 BSP트리를 사용하지 말았어야했다. 3차원 그리드가 훨씬 빠르다. 탐색 자체도 문제지만 갱신이 너무 느렸다. 이건 전적으로 나의 판단미스.
결과적으로 4000명을 처리하는데 6코어 제온을 2개나 박았다. 조립머신이라도 CPU값만 300만원 정도 들었다.
이번 코드에서는 SSE어셈을 사용하지 않았다. 물론 여유가 된다면 CPU코드는 SSE로 바꿀 생각이지만...그리고 이전엔 타원체간 충돌처리를 하지 않았다. 이번엔 타원체간 충돌처리를 한다. 그런데도 이전에 비해서 100배는 빠르다. 그 원인은 다음과 같다.
1. 계산 코드가 간결하다. 수식과 코드 흐름 자체가 훨씬 간결하다.
2. BSP트리 대신 3차원 그리드를 사용한다.
결과적으로 i7 4core머신이면 플레이어간 충돌처리를 해도 4000명 유져를 처리하는데도 별 문제는 없다. 약간 간당간당한 감은 있지만.
애초에 이번에 충돌처리 코드를 다시 만들게 된 계기가 그 당시에 퍼포먼스가 만족스럽지 않아서 CUDA의 힘을 빌리고자 함이었다.
물론 이번 코드에서는 CUDA를 적용했고 최악의 상황에서 CUDA는 10배 정도의 퍼포먼스 향상을 가져다 주었다.
그런데 불행인지 다행인지 내 마지막 프로젝트에서 사용한 정도의 충돌처리(에다가 동적인 타원체 충돌처리까지 더해도...) 라면 CUDA가 전혀 필요없이 CPU파워만으로도 충분하다는 사실을 이번에 알게된 것이다.
기쁘기보단 억울하고 허탈한 마음이 든달까. 괴로운 CUDA디버깅의 추억은 다 부질없었단 말인가.
일단 이번에 작성한 코드는 DLL로 포장해두고 지속적으로 업그레이드 해갈 생각이다. 이후에 어딘가 회사에 들어갔을때 저작권 분쟁에 휩쓸리지 않도록 GPL이나 LGPL로 소스는 먼저 공개하려고 한다.
여담인데 아마 프로젝트가 중단되지 않았더라면 충돌처리 코드를 다시 작성할 일이 없었을테고 과거의 삽질을 몰랐겠지. 기술적으로는 프로젝트가 날라가고 회사를 그만두고 백수가 된 것이 더 나았을까?
그래도 프로젝트가 날라가지 않는 쪽이 더 좋았다고 생각한다.
쩝.
댓글 '4'
별거 아닙니다. 인접한 삼각형이나 동적인 오브젝트를 찾기 위해서 X,Y,Z 각 축에 대해서 얼마간의 크기로 잘라서 각 칸에다가 삼각형과 오브젝트의 링크 정보를 넣어두는 겁니다.
2차원 그리드는 타일방식하고 사실 같고요. 3차원은 y축으로도 쌓아올렸다는 점이 다릅니다.
충돌처리를 하려면 주변의 오브젝트와 삼각형을 긁어와야하는데 무작정 모든 삼각형과 오브젝트를 긁어올 순 없으니까요.
임의의 오브젝트에 속도벡터를 더하면 대충 캡슐형태가 나오는데 3차원그리드에서 이 캡슐에 걸쳐지는 cell들을 바로 계산해낼 수 있죠. 그 cell들에 미리 링크되어있는 삼각형과 오브젝트들을 긁어오는겁니다.
개념적으로 비슷한 자료구조는 쿼드트리, 옥트리가 있습니다.
그런데 맵툴에서 쓸 일이 있나요? 무슨 용도로 쓰시려는건가요?
3차원 그리드에 대한 힌트를 주시면 않될까요 지금 맵 툴을 만드는데 한번 응용해 보고 싶습니다
개념 정도만 알려주시면 정말 감사하겠습니다 감사합니다