월간 보관물: 2014 1월

AMD GPU 의 미래, “Mantle” 프레임워크?!

AMD 가 차세대 콘솔 시장(PS4, XBox One)을 장악하고 나서 여새를 몰아 PC 게임 시장까지 장악하려는 움직임을 보이고 있습니다. 바로 콘솔 게임 개발에 사용되는 프로그래밍 기술과 최적화 기술을 PC 에 쉽게 적용할 수 있도록 도와주는 “Mantle” 프레임워크를 공개하여 기존 콘솔 게임 개발자들을 사로잡겠다는건데요, 아직은 초기단계라서 미래를 장담하긴 힘들지만, 최근 분위기를 보면 다들 상당히 기대를 하고 있는 모양입니다. (배틀필드4에 Mantle 을 적용하여 얻은 성능 개선이 꽤 크네요. 이게 일반 게임 개발에도 그대로 적용될 수 있다면 상당히 매력적일꺼같습니다.)

일반적으로 여러 그래픽 장치들의 호환성이 중요한 PC 시장에서는 호환성이 보장되는 DirectX 나 OpenGL 을 사용하는데요, 콘솔 게임 시장은 호환성이 중요치 않기 때문에 GPU 를 거의 직접 제어하다시피해서 게임을 개발하고 있습니다. 그래서 실제 하드웨어 성능은 PC 가 더 좋지만, 고성능을 요구하는 게임이 콘솔에서 더 잘 동작하는 것입니다. 결국 Mantle API 는 기존의 DirectX 나 OpenGL 과 같이 호환성을 유지하면서 고성능을 요구하는 콘솔 게임을 PC 로 손쉽게 이전할 수 있는 API 라고 할 수 있습니다. (AMD 측 주장으로는 NVIDIA 그래픽 장치와도 쉽게 호환될 수 있을꺼라고 하네요.) 하지만 호환성과 성능을 모두 잡는다는게 말처럼 쉬운 일이 아니기 때문에 AMD 가 어디까지 해낼 수 있을지는 지켜봐야겠습니다.

모바일과 웹 분야에서도 플랫폼 전쟁이 오래 전부터 이어져오고 있는데요, 플랫폼 자체 개발 기술은 이제 어느 정도 상향 평준화된거같습니다. (이런 상황은 사실 여러 회사들의 개발자들의 수준이 상향 평준화되었다기 보다는, 오픈소스의 수준이 높아졌기 때문이라고 보는게 더 맞는 말인듯 하네요.) 결국 플랫폼의 성공 여부는 일반 개발자들을 얼마나 많이 끌어들여서 컨텐츠를 확보할 수 있느냐인데, 거기에 가장 중요한 요소 중에 하나가 개발 언어와 API 인거같습니다. 그래서 구글이 Dart 를, MS 가 C# 을 성공시키려고 많은 투자를 하고 있는 것이고, AMD 가 Mantle 의 성공을 바라는 것이겠지요. 하지만 하나의 SW 를 성공시키는 것과 달리, 새로운 개발 언어나 API 를 성공시킨다는 것은 엄청나게 힘든 일입니다. 왜냐하면 개발자들이 새로운 개발 언어와 API 를 익힌다는 건 많은 시간과 노력을 투자해야하는 일인데, 그걸 당연히 함부로 하지는 않겠죠. C 나 C++ 같이 역사와 전통이 있는 언어가 아니라, 특정 회사에서 새로 개발한 언어라면 개발자들이 그 회사에 가지고 있는 신뢰가 큰 작용을 하는 것은 당연한 일일테니까요. (삼성이 아무리 많은 돈을 투자해도 당장은 자체 플랫폼을 가지기 힘든 가장 큰 이유 중에 하나인거같습니다.)

암튼 IT 전반적으로 플랫폼을 장악하려는 움직임과 이에 따른 개발 언어와 API 를 장악하기 위한 노력들이 끊임없이 이어지고 있네요. 앞으로 어떤 분야에서 어떤 회사가 먼저 치고 나갈지 기대가 됩니다.

[CODE] GNU C 정규표현식 라이브러리 (regex library)

C 언어에서 정규표현식을 사용할 일이 있어 찾아봤더니, 역시 있네요 ㅎㅎ

사용법은 너무 간단하니 샘플 코드를 참고하세요~

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

#include <regex.h>

int main(int argc, char *argv[])
{
  regex_t state;
  const char *texts[] = {
    "state : q0",
    "state: q0",
    "state:q0s",
    "#state :q0",
    "state q0",
    "# state :q0"
  };
  const char *pattern = "^[ \\t]*(state)[ \\t]*:.*$";
  int i;

  if (regcomp(&state, pattern, REG_EXTENDED))
    return -1;

  for (i = 0; i < sizeof(texts) / sizeof(texts[0]); i++) {
    int status = regexec(&state, texts[i], 0, NULL, 0);

    fprintf(stderr, "%s: %s\n", texts[i], status == 0 ? "match" : "no match");
  }

  return 0;
}

[CLUTTER] constraint 사용시 주의사항

clutter 는 OPENGL (cogl) 기반의 기본적인 컴포지팅 기능을 제공할 뿐아니라 잘 정의된 인터페이스를 이용하여 애니메이션과 같은 다양한 기능들을 지원한다. 하지만 모든 소프트웨어가 그렇듯이 clutter 또한 지금도 발전해나가는 과정에 있고, 많은 문제점들을 가지고 있다. 이에 효과적으로 대처하기 위해서는 어쩔 수 없이 clutter 내부 소스를 보면서 꾸준히 이해도를 높여가는 방법밖에는 없다. 필자 또한 clutter 를 사용하면서 수많은 문제를 겪고 있는 과정 중에 있고, 오늘부터 그 경험들을 하나씩 공유하고자 한다.

clutter 가 레이아웃 관련해서 제공하는 유용한 기능 중에 constraint 이 있다. 예를 들어, ‘A’ actor 의 가로 넓이를 ‘B’ actor 의 가로 넓이와 자동으로 일치시키고 싶다면 아래와 같이 간단히 정의할 수 있다.


clutter_actor_add_constraint(actor_a, clutter_bind_constraint_new(actor_b, CLUTTER_BIND_WIDTH, 0.0f));

잘 쓰면 굉장히 편리한 기능이고 특별히 사용하기에도 어려울 것이 없는 기능이다. 하지만 다음과 같은 시나리오에서는 조금 주의해서 사용할 필요가 있다.

constraint

위의 그림은 필자가 개발 중인 윈도우 매니저의 일부이다. actor (stage) 는 최상위의 ClutterStage 이고, actor (background) 는 배경화면을 보여주는 actor 이고, actor (mouse pointer) 는 마우스 포인터를 보여주는 actor 이다. 그리고 배경화면은 기본적으로 전체화면에 꽉 차게 설정할 필요가 있으므로 bind constraint 를 이용하여 actor (stage) 의 크기와 actor (background) 를 자동으로 동기화시켰다. 이런 상태에서 개발을 진행하던 중 특이한 문제를 하나 발견하게 되었다. 마우스 포인터가 움직일 때마다 actor (background) 의 allocation 이 재할당되는 것이다. 마우스 포인터 액터와 배경화면 액터는 전혀 상관이 없음에도 불구하고, 마우스 포인터를 움직일 때마다 배경화면의 액터가 영향을 받는게 이상해서 한참을 고민하다가 원인을 찾았는데, 그 원인이 바로 constraint 이였다.

마우스 포인터의 위치가 변경되면 위치 속성(position property) 이 변경되고, 이 속성은 레이아웃에 영향을 주기 때문에 자신의 레이아웃과 부모의 레이아웃을 변경한다. 여기까지는 당연한 과정이다. 하지만 필자가 예상치 못했던건 너무나 쉽게 사용했던 constraint 때문이다. bind constraint 의 사용은 결국 actor (background) 의 위치와 크기가 actor (stage) 의 위치와 크기에 영향을 받는다는 뜻이다. 즉, actor (stage) 의 레이아웃이 변경되면 actor (background) 의 레이아웃도 자동으로 변경되므로, 결국 아래 그림처럼 마우스 포인터를 움직일 때마다 배경화면의 레이아웃이 변경되는 것이다. 마우스 포인터라는 특이한 동작을 하는 액터만 없었다면 아무 문제 없는 경우이지만, 시도때도 없이 위치가 변경되는 마우스 포인터로 인해 이런 상황이 발생하게 된것이다.

relayout

결국 필자는 bind constraint 를 제거하고 actor (stage) 의 allocation changed 이벤트 핸들러에서 actor (background) 의 크기를 변경하는 형태로 코드를 수정한 후 정상적인 동작을 확인하였다. 일반적인 기능이더라도 사용하는 방식에 따라 언제든지 문제가 될 수 있다는 사실을 반드시 명심하시기 바랍니다.

Valve 의 게임이 데비안 개발자들에게는 모두 공짜?!

Valve 의 과거, 현재, 미래의 모든 게임이 데비안 개발자들에게는 모두 공짜라는 기사가 떴습니다!

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

대략적인 스토리는 이렇습니다. 세계적인 오픈소스 컨설팅 회사인 Collabora 가 Valve 의 클라이언트측 운영체제인, 데비안 기반의 SteamOS 프로젝트를 진행하는 중에 Valve 측에서 오픈소스 개발자들에게 뭔가 도움을 주고 싶다는 제안을 하였고, 그 첫번째 결과물이 데비안 개발자들에게 Valve 의 모든 게임을 무료로 제공해주자는 것입니다. 상당히 색다른 오픈소스 참여 활성화 정책이네요. 데비안 keyring 을 가지고 있는 개발자는 간단한 인증과정을 통해 바로 혜택을 받을 수 있다고 합니다. 이외에도 다른 기여 방법도 생각 중이라고 하니 기대가 됩니다~

Epic Games’ Tim Sweeney Explains Lack Of ‘SVOGI’ In Unreal Engine 4

작년에 언리얼엔진4가 SVOGI(Sparse Voxel Octree Global Illumination) 를 포기할꺼라는 루머는 들었었는데, 관련 기사가 있었군요.

http://www.dsogaming.com/news/epic-games-tim-sweeney-explains-lack-of-svogi-in-unreal-engine-4/

SVOGI 는 전역 조명 기술 중의 하나로, 영화 CG 에서 주로 사용되는 몬테카를로 확률 기반의 패스트레이싱과 포톤매핑보다 처리 속도가 훨씬 빠르고, 확률 기반 기법들의 고질적인 문제인 노이즈가 발생하지 않는 기술입니다. 그래서 언리얼엔진이나 크라이엔진, 유니티 등에서 발빠르게 구현해서 데모를 해오고 있었는데요, 언리얼엔진4에서 SVOGI 가 결국은 성능 문제로 빠졌네요. 아마 동적 지오메트리 지원부터 시작해서 실제 상용화하기에는 아직 무리가 있다고 판단한 모양입니다. 아무래도 아직은 언리얼엔진은 동적 전역 조명 기술과는 인연이 없나봅니다.

그리고 언리얼엔진과 크라이엔진이 항상 자주 비교되는데요, 언리얼엔진은 원래 게임을 개발하던 회사에서 개발한 엔진이고 크라이엔진은 엔비디아의 데모를 제작해주던 외주 업체에서 개발한 엔진입니다. 그래서 그런지 언리얼엔진은 안정적이면서 성능이 우수하고 개발환경이 굉장히 좋다는 평가를 받고 있습니다. 이와 반대로 크라이엔진은 예전부터 동적 전역 조명 기술에 대한 지원을 아낌없이 하고 있지만 성능이나 개발환경이 부실하다는 얘기가 많구요. 실제 크라이엔진에서 나오는 데모 동영상을 보면 입이 다물어지지 않는 것들이 많습니다. (항상 느끼는거지만 기술력과 SDK 를 만드는건 좀 별개인거같습니다.)

어찌됐던 엔비디아 타이탄 2개를 SLI로 연결해서 사용하는 환경에서 패스트레이싱을 실시간 게임에 적용할 수 있는 가능성을 보여준 데모도 공개된만큼 향후 3~5년 뒤에 두 거대 게임 엔진 회사들이 어떠한 새로운 기술들을 선보일지 기대가 됩니다.

A simple example Wayland compositor using Clutter

현재 가장 간단한 wayland 컴포지터는 clayland 입니다. 가장 간단한 클라이언트만 실행할 수 있을 정도로 기본적인 프로토콜만을 지원하고 실제 컴포지팅은 clutter 를 이용하고 있습니다. 처음 공부 시작하실 때 아주 가벼운 마음으로 한번 보시는것도 좋을꺼같습니다.

https://github.com/clutter-project/clayland

SWC: A Wayland Compositor Framework

오늘 아침에 wayland-devel 메일링 리스트에 메일이 올라왔었는데, 역시나 바로 phoronix 에 기사가 떴군요.

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

swc 라는 새로운 wayland 기반 컴포지터 라이브러리가 공개되었습니다. 기본적으로 타일링 윈도우 매니저를 지원하고 있고, EGL 은 아직 지원하고 있지 않지만 다른 필수적인 기능들은 웬만큼 이미 지원하고 있습니다. 데모 동영상을 보면 xwayland 를 이용해서 chrome browser 도 동작하는군요. 일단 오전에 소스는 잠깐 열어봤는데 weston 보다는 깔끔하게 정리가 잘 되어있네요. weston 은 레퍼런스 컴포지터이기 때문에 기본적으로 모든 기능을 최대한 빨리 구현하는게 주요 목적입니다. 그래서 소스가 약간 지저분하고 정리가 덜 된 부분이 많은데요, 이런 이유로 weston 을 분석하는게 불편했던 분들은 swc 를 먼저 보는 것도 많은 도움이 될것같습니다.