월간 보관물: 2014 3월

3D 게임을 위한 웹 플랫폼 관련 (WebGL + Emscripten + ASM.JS)

얼마 전에 리눅스를 게임 플랫폼으로 성공적으로 안착시키기 위해 어떠한 연구들이 진행되고 있는지 소개하는 글을 올렸습니다. 그리고 오늘은 더 나아가서 웹 플랫폼을 게임 플랫폼으로 활용하기 위한 연구들이 어떻게 진행되고 있는지를 소개드리도록 하겠습니다. 예전부터 WebGL 에 관심은 있었지만 웹 자체에 대한 편견으로 고성능 3D 게임을 돌리는 용도로는 당연히 부적합할 것이라고 생각했었는데, 최근 돌아가는 상황을 보니 상당히 놀랍습니다.

http://www.phoronix.com/scan.php?page=news_item&px=MTYyODM
http://www.phoronix.com/scan.php?page=news_item&px=MTYzNDc

일단 간단히 요약하면 C/C++ 로 구현되어있는 게임/엔진 소스를 Emscripten 으로 컴파일해서 자바스크립트와 WebGL 소스를 만들어내고, 더 나아가서 ASM.JS 기술을 이용해서 최적화 한다는 것입니다. 현재 파이어폭스에서 ASM.JS 까지 모두 적용하면 네이티브의 1.5 배 정도의 성능이 나온다는 것만해도 굉장히 놀라운데, 이 수치 또한 아직 많은 노력을 들인 것이 아니기 때문에 앞으로 개선의 여지가 더 있다고 하네요. 그럼 기술적인 내용들을 간단히 소개드리도록 하겠습니다.

우선 Emscripten 은 LLVM 의 벡엔드로 중간언어인 IR 을 자바스크립트 코드로 변환해주는 프로젝트입니다. 이론적으로는 LLVM 이 지원하는 프론트엔드를 모두 자바스크립트로 변환해줄 수 있겠지만, 실제로 현재 어디까지 지원하는지는 확인해보진 않았습니다. 하지만 유니티5 엔진과 언리얼 엔진4를 변환할 수 있다고 하니, 왠만한 C/C++ 로 구현된 것들은 거의 다 되지않을까라는 생각이 듭니다. 그리고 이 결과물은 특정 브라우저에 종속적인 확장 기능이 아닌 표준 자바스크립트 코드만을 사용하기 때문에 모든 브라우저에서 사용할 수 있다고 합니다.

이렇게 생성된 자바스크립트 코드는 현재는 파이어폭스만이 지원하는 ASM.JS 라는 기술에 의해 최적화되는데 이 기술은 새로운 자바스크립트 엔진은 아니고 기존의 자바스크립트 엔진에 일종의 플러그인 형태로 들어가는 기술입니다. 이 기술은 간단히 얘기하면 특정 자바스크립트 함수를 AOT(Ahead-Of-Time) 해주는 기술이라고 볼 수 있는데, 이게 큰 의미를 가지는 이유는 Emscripten 으로 생성된 자바스크립트 코드는 정적 타입 언어인 LLVM 의 IR 을 이용해서 생성한 코드이기 때문에 정적 타입 언어의 특성을 가지게 됩니다. 그래서 기존의 동적 타입 언어를 지원하는 JIT(Just-In-Time) 형태의 자바스크립트 엔진보다 SSA (Single Assignment Form) 같이 일반적인 컴파일러가 사용하는 최적화 기술을 적용하는 것이 유리하기 때문에 많은 성능적인 장점을 가지게 되는 것입니다. 사실 잘 생각해보면 특별히 새로운 기술은 아닙니다. 왜냐하면 ASM.JS 는 결국 Emscripten 에 의해 생성된 자바스크립트 코드를 기존에 웹에서 사용하던 자바스크립트 코드로 보지 않고, LLVM 같은 컴파일러가 사용하는 중간언어인 IR 처럼 사용하겠다는 것이기 때문입니다. 하지만 발상의 전환으로 ASM.JS 를 지원하지 않는 브라우저에서는 자바스크립트 형태로 사용해서 느리지만 동작이 가능하고, ASM.JS 를 지원하는 브라우저에서는 최적화해서 성능을 높여주는 것이 가능해진 것입니다.

파이어폭스가 구글한테 계속 밀리더니 결국 한껀 했습니다. 게임이 아닌 다른 응용에서는 결과가 다를수도 있을꺼라는 생각이 들긴 하지만, 어찌됐든 구글이 밀고 있는 NACL 에 제대로 한방을 먹였네요. 앞으로 어떻게 될지는 예상하기 힘들지만 현재로선 NACL 에 비해 확장성과 성능 모두 완승이네요.

Working Towards Lower OpenGL Driver Overhead

이번 GDC 에는 개인적으로 관심이 많은 OpenGL 최적화와 리눅스 관련 발표들이 많습니다. 아래 첨부한 링크는 NVIDIA, AMD 그리고 Intel 의 GPU/OpenGL 을 연구/개발하는 대표 인력들이 최근 진행 중인 OpenGL 최적화 관련 이슈들을 같이 발표한 내용입니다.

OpenGL 최적화에서 많은 부분을 차지하는 것이 예전부터 많이 연구되어오던 API 호출을 얼마나 효과적으로 줄일 것이냐이기 때문에 전혀 새로운 내용은 거의 없지만, 관심있으신 분들은 읽어보시면 도움이 될 것 같습니다. 현존 CPU/GPU 관련 최강 회사들이 모두 뭉쳐서 발표하는 자리는 흔치 않을테니까요^^

http://www.phoronix.com/scan.php?page=news_item&px=MTYzODY

언리얼 엔진 & 크라이텍 엔진 가격 인하?!

올해 GDC 에는 재밌고 유익한 발표가 정말 많습니다. 특히 인디 게임 개발자들에게 굉장히 좋은 소식들이 들려오고 있는데요, 그건 바로 최고의 게임 엔진인 언리얼 엔진과 크라이텍 엔진의 새로운 가격 정책입니다.

http://www.phoronix.com/scan.php?page=news_item&px=MTYzNjY

http://www.phoronix.com/scan.php?page=news_item&px=MTYzNzU

언리얼과 크라이텍 측이 인디 게임 개발자들에게 매달 $19.0 와 9.90USD 의 비용으로 전체 소스까지 제공하겠다는 내용입니다. 기존의 언리얼 엔진 라이센스 비용을 아는 사람이라면 정말 어처구니 없을 정도의 가격이라는 생각이 당연히 들텐데요, 아마 언리얼이나 크라이텍이 유니티를 견제하기 위해 어쩔 수 없는 선택이였다고 봅니다. 유니티는 개인이나 소규모의 게임 개발 시장을 장악한 뒤 역으로 대규모 게임 개발 시장을 침투하고 있는데요, 스마트폰때문에 소규모의 게임 개발 시장도 커지고 유니티의 영향력도 점점 커지고 있기 때문에 언제까지나 기술력만 믿고 버티기는 힘들었을꺼같습니다.

어찌됐던 게임 개발자들에게는 굉장히 좋은 소식이네요. 앞으로 더욱 좋은 인디 게임들이 많이 나왔으면 좋겠습니다!!!

리눅스 게임 플랫폼 관련

최근 몇 년 사이 Valve 가 엔비디아와 같이 협력하며 리눅스를 적극 지원하고, 데비안 기반의 게임 배포 플랫폼인 SteamOS 를 개발하는 등의 노력으로 리눅스를 차세대 게임 플랫폼 환경으로 성장시키려는 목표가 점차 가시화되어가고 있습니다. 오늘은 이를 위한 다양한 노력들이 어떻게 진행되고 있는지 알아볼 수 있는 최근 뉴스들을 간단히 소개드리도록 하겠습니다.

아래 기사는 Valve 에서 진행하고 있는 오픈소스 프로젝트로 Direct3D 를 OpenGL 로 편리하게 전환할 수 있도록 도와주는 프로젝트입니다. 아직까지는 초기 버전이기 때문에 제한적이지만, 기존에 각자 알아서 해오던 작업들이 하나로 합쳐질 수 있는 가능성을 열어준 프로젝트이기 때문에 상당히 기대가 되는 프로젝트입니다.

http://www.phoronix.com/scan.php?page=news_item&px=MTYyNjM

아래 기사는 엔비디아의 최신 리눅스 그래픽 드라이버 지원 소식입니다. 최근 엔비디아의 행보를 보면 놀라움의 연속입니다. 개인적인 생각으로는 차세대 콘솔 게임 시장에서 AMD 에 완전히 밀리고 나서 Valve 와 손을 잡고 리눅스 기반의 데스크탑 게임 시장을 장악하기 위한 노력인것같긴한데 어찌됐던 사용자나 개발자 입장에서는 굉장히 좋은 상황인건 변함이 없으니까요.

http://www.phoronix.com/scan.php?page=news_item&px=MTYyNjY

아래 기사는 대표적인 게임 엔진인 CryEngine 이 이번달에 열리는 GDC 에서 리눅스 네이티브 환경에서 전체 기능을 모두 지원하는 첫 번째 버전을 공개한다는 내용입니다. 현재 가장 많이 쓰이고 있는 게임 엔진은 Unreal Engine, CryEngine 그리고 Unity 3D 인데, Unity 3D 는 이미 리눅스를 지원하고 있고, CryEngine 도 이번에 공개하고, Unreal Engine 측은 아직 공식적인 지원은 없지만 관련 커뮤니티에서 리눅스를 지원하자는 얘기는 몇 년 전부터 심심찮게 나오고 있습니다. 리눅스가 게임 플랫폼으로 활용되기 위해 필수적으로 필요한 그래픽 제조회사와 게임엔진 개발회사의 지원이 눈에 띄게 활발해지고 있으니 앞으로가 굉장히 기대됩니다.

http://www.phoronix.com/scan.php?page=news_item&px=MTYyNjQ

아래 기사는 대표적인 2D 기반의 게임 엔진인 SDL 의 최신 버전에서 mir 와 wayland 를 지원한다는 내용입니다. EGL 도 완전히 지원한다고 하니 하드웨어 가속도 전혀 문제가 없을테고, 여러모로 꽤 기대가 되는 기사입니다.

http://www.phoronix.com/scan.php?page=news_item&px=MTYyNjU

마지막으로 리눅스에서 실시간으로 게임 동영상을 캡쳐해서 스트리밍할 수 있는 오픈 소스 프로젝트에 대한 기사입니다. 조만간 1080p 까지 지원한다고 하니 기대가 됩니다.

http://www.phoronix.com/scan.php?page=news_item&px=MTYyNjg

안드로이드의 성공이 데스크탑과 향후 나올 새로운 컴퓨팅 환경에 많은 영향을 주고 있는 것 같습니다. 개인적으로 기대하는 부분은 향후 가정에서 리눅스 기반의 단일 플랫폼으로 게임이나 IoT 를 위한 컨트롤 센터, 스마트 TV 등을 모두 지원하는 것입니다. 물론 MS 나 애플이 손놓고 있진 않겠지만 안드로이드를 기반으로 스마트폰 시장에서 성공했던 것처럼 오픈소스와 리눅스의 장점을 잘 살려서 진행한다면 시장에서 큰 부분을 차지하는 건 어렵지 않을 것 같습니다.

[WAYLAND] 윈도우 크기 변경 동작 과정 (vs 위치 변경)

윈도우의 위치 변경과 크기 변경은 사용 시나리오가 유사하지만 개발자 관점에서는 상당히 다른 특징을 가진 기능 중의 하나이다. 그 차이점은 바로 클라이언트와의 협업이 필요한지 아닌지인데, 우선 간단히 말하면 위치 변경은 클라이언트와 상관없이 동작하는 기능이고, 크기 변경은 클라이언트와 관련이 깊은 기능이다. 예를 들어, 윈도우의 크기에 따라 화면의 배치나 모양을 변경하는 터미널같은 클라이언트는 윈도우의 크기가 변경될 때 마다 화면을 갱신하는 작업이 필요하다. 그래서 오늘은 윈도우의 크기 변경이 현재의 wayland/weston 에서 어떻게 동작하는지를 살펴보고자 한다.

현재 weston 에서는 윈도우의 크기가 변경되는 경우, 예를 들어, 마우스로 윈도우의 테두리를 그랩해서 드래그하는 경우나, 최대 혹은 전체 화면으로의 변경을 요청하는 경우, 실제 윈도우의 크기를 변경하는 지점은 다음 버퍼(wl_buffer) 가 서페이스(wl_surface) 에 반영(attach) 되는 시점이다. 이유는 클라이언트가 요청된 크기로 새로 그린 버퍼가 서페이스에 반영되기 전에 윈도우의 크기가 변경되면 이전 크기의 버퍼가 화면에 보여질 수 있기 때문에 화면이 작게 요동치는 현상이 발생하게 된다. 이 과정을 그림으로 표현하면 다음과 같다.

resizing

우선 클라이언트가 윈도우의 테두리를 클릭하여 weston 에게 크기 변경 요청을 하면, weston 은 해당 윈도우를 resize grab 하게 된다. (현재 weston 은 CSD (Client-Side Decoration) 을 사용하므로 크기 변경 요청은 클라이언트가 weston 에게 한다.) 그리고 resize grab 의 motion 핸들러에서는 마우스의 위치에 따라 해당 윈도우의 크기를 변경하는데, 이 때 직접 서페이스의 크기를 변경하지 않고 클라이언트에게 xdg_surface 인터페이스의 configure 이벤트를 전달한다. configure 이벤트를 전달받은 클라이언트는 윈도우의 크기가 변경되었다는 사실을 인지하고, 공유 메모리나 EGL 을 이용하여 새로운 크기의 버퍼를 할당받고 서페이스(wl_surface) 에 attach 하게 된다. 그리고 weston 의 surface_attach 에서 마침내 서페이스의 크기를 변경하게 된다.

그리고 또 한 가지 알아야 할 것은, 만약에 윈도우의 위(top) 혹은 왼쪽(left) 테두리를 클릭하여 크기 변경을 한다면 윈도우의 위치가 동시에 변경되어야 한다. (혹시 이해가 안 되면, 현재 사용 중인 브라우저의 왼쪽 테두리를 클릭하여 크기를 변경해보라.) 이 경우에는 윈도우의 위치와 크기가 동시에 변경되어야 하는데 이 때도 앞에서 설명한 내용과 동일한 시나리오로 윈도우의 크기는 surface_attach 에서 변경되고, 추가적으로 윈도우의 위치는 surface_commit 에서 변경된다. (좀 더 설명하면, 윈도우의 오른쪽이나 아래쪽을 기준축으로 사용하여 요청된 크기에 맞게끔 위치를 변경한다는 것이다.)

여기까지가 현재의 wayland/weston 에서 윈도우의 크기를 변경하는 과정이다. 처음에 설명했던 것처럼 윈도우의 위치를 변경하는 과정은 클라이언트의 개입이 필요없기 때문에 이보다는 훨씬 간단하다. 우리가 늘 사용하는 윈도우 환경이지만, 실제로 개발하기 위해서는 세심한 관찰이 필요한 것 같다.