Software Engineer Nick : yuchi , dgtman, megayuchi twitter: @dgtman blog : https://megayuchi.wordpress.com , http://blog.naver.com/shovelmaster , http://yuchi.net
코룸 온라인 개발하던 시절에… 베타테스트 직전에 운영팀에서 pc방을 돌면서 게임을 테스트했다. 그리고 버그 리포트라는게 전달이 됐는데 그중에 RIVA TNT에서 크래시한다는 내용이 있었다. 당시 RIVA TNT에서 압축 테스처를 지원하지 않기 때문에 생긴 문제였다. 아마 2003년 즈음이었을텐데 그때 많이 쓰던 그래픽 카드는 GeForce 2/4 MX, 고급군으로는 GeForce 3/4 TI 였다. 코룸온라인은 최소사양이 RIVA TNT였다. 나한텐 안물어보고 정했던것 … More 기능 지원 안되는 디바이스 지원에 대한 잡설
1. 코딩/디버깅환경이 거지같은 Compute Shader를 작성하기 전에 성능을 가늠해볼수 있다. 보수적으로 잡았을때 Compute Shader가 CUDA의 50% – 80%정도 나온다고 예측해보면 CUDA코드가 CPU코드보가 3-4배 빠르면 충분히 GPU코드를 추가 작성할 가치가 있다. 2. Compute Shader를 추가작성하기로 결심했더라도 CPU코드 -> Compute Shader로 바로 가기는 어렵다. 디버깅 환경이 거지같으니 코드 짜놓고도 이게 맞는건지 틀린건지 확인하기 어렵다. CPU -> Compute … More Voxel Horizon프로젝트에 CUDA를 적용하고 있는 이유
KD-Tree를 순회할땐 stack이 필요하다. stack을 구현한다는게 CPU코드에선 아무 문제도 아니지만 CUDA에선 고민이 좀 필요하다. CUDA에서 자유롭게 쓸 수 있는 메모리는 Global Memory이다. 그런데 겁나 느리다. 시스템 메모리보단 엄청 빠르지만 GPU보단 한참 느리다. stack을 global memory에 올려놓으면 아무래도 억세스할때마나 stall이 걸린다. CUDA에서 사용할 수 있는 고속 메모리는 shared memory가 있다. 여기다 stack을 올려놓으면 물론 빠르다. 그런데 … More CUDA에서의 stack 구현
엊그제 포스팅했던 CUDA를 이용한 라이트맵 베이킹의 성능향상에 대한 얘기다. 좀더 GPU를 빡시게 사용하려고 cuda Stream + 멀티스레드 까지 적용했는데 생각보단 성능이 많이 오르지 않는다. 프로파일링 해보니 Occupancy가 이론상 50% 달성할 수 있는데 실제로는 29.3%만 달성한 것으로 나온다. Occupancy가 영 만족스럽지 못하다. 그래서 이런저런 튜닝을 좀 했다. 오랫만에 Occupancy Calculator를 실행해서 SM 5.2와 6.1기준으로 숫자를 넣어 … More CUDA를 이용한 복셀 월드의 라이트맵 계산 – 성능개선
복셀 월드의 라이트맵 계산을 CUDA로 하도록 만들었다. 2010년에 이미 CUDA로 라이트맵을 구웠기 때문에 별로 대단한 작업은 아니다. 다만 이번엔 CUDA 6부터 추가된 Unified Memory 체계를 사용했다는 점이 다르다. 우선 기본적으로 라이트맵 계산을 하는 원리를 보자. 복셀 오브젝트마다 공간상의 점과 텍스처 좌표를 연결시킬 patch배열을 가지고 있다. 각 patch들로부터 라이트까지 ray를 쏴서 거리과 각도에 따라 라이트값을 구한다. … More CUDA를 이용한 복셀 월드의 라이트맵 계산
예전에 NDC에서 발표했던 자료. 참고로… 라이트맵은 15년전에 만든 엔진에도 들어가 있었고 코룸온라인/묵향 온라인에 적용해서 서비스했었다. blur도 들어가지 않은 raw라이트맵이었다. 그래도 그 시절엔 꽤 괜찮아보였다. 후에 이소프넷 망하고 묵향쪽이 분사하면서 라이트맵 베이킹도 안하게 됐다. 나도 다른 회사 갔고 그 회사엔 더 이상 코드 유지보수할 사람도 툴 사용법을 제대로 아는 사람도 없어서 그냥 깔끔하게 포기했던걸로 안다. 당시에 … More CUDA + Lightmap 관련 잡설
초기에는 하나의 맵, 하나의 월드만으로 구성할 생각이었다. 지금 상태에서 9km x 9km이상을 처리할 수 있도록 엔진을 고칠 자신도 없고 그럴 에너지도 남아있지 않다. 그래서 그냥 쉽게 가기로 했다. 기존처럼 포탈 타고 맵체인지 하면 된다. 클라이언트와 서버에서 추가적인 작업을 좀 해주긴 했지만 크게 어렵지는 않게 맵간 이동은 구현했다. 뭐 이전에도 늘상 하던 전형적인 mmorpg 맵 이동처리니까. … More Game Dev – Voxel Horizon – 맵간 이동
이전 포스팅 참고. https://megayuchi.com/2018/03/29/surface-book%ec%97%90%ec%84%9c-%eb%82%98%ed%83%80%eb%82%98%eb%8a%94-60fps-%ec%a0%9c%ed%95%9c-%ed%98%84%ec%83%81/ 이 빌어먹을 현상이 dGPU + 내장 GPU 구성을 가지는 다른 노트북에선 이 현상이 발생하지 않는다. 적어도 내가 테스트한 바로는 오직 서피스북에서만 발생했다. 하여간 엊그제 트위터 타임라인에 DX12개발자 계정이 BLT대신 FLIP방식을 사용하라는 문서를 공유했다. 혹시나 해서 읽어보다가 DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING옵션을 처음 알게 됐다. 오늘 SwapChain만들때 DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING값을 넣어보니 서피스북에서 60프레임 락이 드디어 풀리는걸 확인했다. 이 … More Surface Book에서 60프레임 락 해결방법
한참 복셀을 편집중인데 어떤놈이 와서 내가 쌓은 복셀조각을 파괴하거나 내가 복셀을 배치하려는 영역에다 지가 복셀을 쌓거나 하면 곤란하다. 그래서 그 방지대책을 세웠다. 1. owner가 설정되지 않은 복셀 오브젝트(4m x 4m x 4m)영역에 대해 한개의 복셀이라도 추가하면 행위자의 계정 serial이 owner serial로 등록된다. 2. owner serial이 등록된 오브젝트 영역에 대해서 다른 플레이어들은 일체의 편집행위를 할수 없다. … More Voxel Horizon – 소유영역 처리
Windows 10 1709(rs3)부터 서피스북1/2에서 DirectX 어플리케이션(게임등)을 실행할때 60FPS를 넘기지 못한다. 이전에 유튜브에 올렸던 참고 영상. Windows 10 1709가 릴리즈 되고나서 페이스북과 트위터에서 몇번인가 언급했었다. [현상 및 직접적인 원인] 이 성능 저하의 문제는 GPU의 성능 자체와는 상관이 없다. 순전히 swap chain의 처리방법에서 발생한다. 정확히는 최종적으로 Windows Destkop Windows Manager(이하 DWM)이 어플리케이션의 렌더타겟 버퍼를 데스크탑 윈도우에 조합(composition)할때 … More Surface book에서 나타나는 60fps 제한 현상.
yuchi's development 
댓글을 달려면 로그인해야 합니다.