yuchi's development

이전에 Project D Online과 Voxel Horizon 모두 UWP앱으로도 유지보수를 하고 있었다. 당연히 ARM빌드도 같이 지원했고 Windows Phone에서 작동 가능했다.

몇년전부터 MS가 Windows Phone을 땅에다 파묻어버렸기 때문에 더 이상은 ARM빌드를 유지할 이유도 없었고 유지하고 싶어도 테스트할 수가 없었다. Windows API버전은 올라가는데 폰은 업데이트가 안되니까.
최근 Windows on ARM의 레퍼런스 디바이스 Surface Pro X가 출시됐다.
기계를 제어한다는 느낌을 좋아하는 나로선 꽤나 흥분했다. 물론 난 이 물건이 Surface RT의 재림이 될거라 확신한다. 하지만 나에게 중요한건 ARM CPU로 풀버전 Windows 10을 돌릴 수 있고 DirectX 12까지도 돌릴 수 있다는 점이다.
내 게임 프로젝트를 Windows on ARM으로 돌려보고 싶다. 성능을 비교해보고 싶다.
몇 년안에 라면 냄비 받침으로 전락할 가능성이 농후한데 그에 비해 가격은 너무 비싸서 조금 망설였지만 MS가 내 실험을 위해 기기를 지원해줄 가능성은 0 이다. 빌려주는 일도 없을것이다. 어쩌겠어. 내 돈주고 사야지.

그래서 샀다. Surface Pro X.

어제 물건 받아와서 밤부터 작업을 했다. Voxel Horizon의 엔진 DLL프로젝튿들마다 AMR64 아키텍처 구성을 추가했다. SSE/AVX쓴 코드들, x86/x64어셈블리로 작성한 코드들은 호환성을 유지하면서 C로 다시 짰다. 나중에 NEON에 익숙해지면 SIMD코드들은 NEON으로 포팅할 생각이다.
ARM64타겟으로 빌드만 다시 하려해도 이게 생각보다 간단히 안되는 경우가 있어서 시간을 꽤 소비했다. 어제 새벽과 오늘 한나절을 다 투자해서 Voxel Horizon프로젝트의 엔진 DLL파일들은 모두 ARM64타겟으로 빌드 완료했다.
게임 클라이언트(exe)프로젝트에서 arm64 DLL파일을 로드해서 실행해야한다. 이건 코드 고칠건 거의 없다. 이제 실제로 돌려보며 디버깅 들어가야하는데 솔직히 두렵다.

그래서 워밍업을 해두기로 했다.얼마전에 학생들 가르치려고 만들었던 DDraw샘플이 있다.

이걸 ARM64로 포팅했다.
리모트 디버거로 연결해서 ARM64바이너리를 실행하고 디버깅한다.
데스크탑의 작업폴더를 공유시켰다. Surface Pro X에서 이 공유폴더를 네트워크 드라이브로 잡아 로컬드라이브처럼 사용한다. 이렇게 해서 코드 고칠때마다 변경된 바이너리를 리모트 머신(Surface Pro X)으로 카피하는 수고는 하지 않아도 된다.

debug모드에선 문제가 없었는데 release모드에서 크래시한다. 이상해서 한참을 살펴봤는데 코드에는 문제가 없다. DDraw dll어딘가에서 exception을 날리는데 release모드일때만 그렇고 Blt할때 발생한다. 리모트 디버거를 통해서 실행하지 않고 Surface Pro X에서 직접 실행해보면 아무 문제가 없다. 신기하네….리모트 디버거 연결이 시스템에 영향을 주는것 같다.
케이블로 Windows Phone을 연결해서 UWP 프로젝트로 개발할땐 리모트 디버거 따로 설치할 필요없이 그냥 VS기능으로 원격 디버깅이 됐다. 그땐 이런 문제가 없었다. 일단 내 버그는 아닌걸로 결론지었다. 그래도 찜찜하니 나중에 실제 디바이스에서 arm64용 windbg로 돌려서 확인을 해야할것 같다.(이후에 Surface Pro X쪽에서 ARM64용 windbg띄워서 돌려봤는데 역시 코드에 문제가 없고 익셉션도 발생하지 않는다.)

dpi는 일단 무시하고 논리 해상도만 가지고 창 사이즈 비슷하게 맞춰서 성능 비교를 해봤다.
얼추 데스크탑의 70% 수준은 성능이 나온다. DDraw는 GPU를 사용하지 않는다. 순수 CPU성능이다. 현재 싱글 스레드로만 돌아가며 복잡한 산술연산도 없고 simd도 아예 사용하지 않는다. 그냥 읽고 쓰는 기본 성능이다. 이 정도면 생각보단 나쁘지 않다.

이제 시작이다. Voxel Horizon 데스크탑 버전이 Surface Pro X에서 돌기 시작하면 2편을 올릴 예정이다.