태그 보관물: amd

[WAYLAND] OPENGL 소프트웨어스택의 미래 (XDC 2014)

오늘은 얼마 전에 있었던 XDC 2014 에서 발표됐던 내용을 바탕으로 향후 OPENGL 소프트웨어스택이 어떤 방향으로 발전해나갈지를 간단히 정리해보려고 합니다. 그에 앞서 OPENGL 소프트웨어스택이 정확히 무엇을 의미하는지에 대해 간단히 살펴보도록 하겠습니다.

opengl-sw

위의 그림은 오픈소스 기반의 OPENGL 소프트웨어스택(MESA/DRM)의 구조를 간단히 표현한 것입니다. 계층적으로 보면 MESA/DRM 라이브러리와 드라이버가 있습니다. 우선 DRM 라이브러리는 미리 정의된 IOCTL 인터페이스를 이용해 DRM 드라이버를 단순 호출해주는 역할만을 하므로 길게 설명하지 않고, MESA 라이브러리와 DRM 드라이버에 대해 설명하도록 하겠습니다. (앞으로 DRM 이라고하면 커널 드라이버를 의미한다고 생각하시면 됩니다.)

OPENGL 소프트웨어스택이 하는 역할은 크게 보면 두 가지입니다. 첫 번째는 윈도우 시스템(X11, WAYLAND, …)을 지원하는 것이고, 두 번째는 하드웨어 가속을 지원하는 것입니다. 그렇다면 이를 위해 MESA 라이브러리와 DRM 드라이버는 각각 무슨 일을 할까요? 간단한 예를 들어 설명하면, 하드웨어 가속을 이용하여 OPENGL 렌더링을 하기 위해서는 GPU 에 렌더링을 위한 명령어 스트림을 전달해야 합니다. 그러기 위해서는 GPU 에서 접근할 수 있는 메모리를 할당받아서 필요한 명령어 스트림을 채워야겠죠. 이 때, 실제로 메모리를 할당해주는 역할을 DRM 드라이버가 하고, 명령어 스트림을 채워주는 역할은 MESA 가 하는 것입니다. 즉, 메모리 할당/해제와 같이 커널의 권한이 필요한 것은 DRM 드라이버가 하고, 나머지는 모두 MESA 가 한다고 보시면 됩니다. (사실 역할을 나누기 좀 애매한 부분도 있긴 하지만, 대략 이 정도로 이해하시면 무난할 것 같습니다.) 그래서 우리가 일반적으로 많이 듣는 윈도우 시스템을 지원하는 GLX, EGL 등과 OPENGL 버전 3 이나 4, ES 같은 것들은 실제로는 MESA 와 직접적으로 연관이 있습니다.

그럼 이제 윈도우 환경에서 OPENGL 을 어떻게 사용하는지 살펴보도록 하겠습니다. 우선, 클라이언트와 서버가 OPENGL 을 사용하는 방식에 대해 간단히 살펴보면, 클라이언트는 자기가 원하는 결과물을 렌더링해서 서버로 전달하는 일을 하고, 서버는 모든 클라이언트가 렌더링한 결과물을 받아서 실제 화면에 표시될 결과물을 렌더링한 후 디스플레이에 출력하는 일까지 합니다. 서버와 클라이언트는 렌더링하는 방식도 조금 다르고, 서버는 디스플레이 관리까지 해야하니 사용하는 인터페이스도 차이가 조금 있습니다. 다음은 클라이언트와 서버에서 사용하는 인터페이스들에 대한 설명입니다.

  • GL-API..클라이언트와 서버 모두가 사용하는, 렌더링을 하기 위해 사용하는 기본적인 드로잉 인터페이스입니다. (glVertex3f, …)
  • EGL-API(wl-client)..클라이언에서 사용하는 윈도우 시스템 관련 인터페이스로, 렌더링을 위한 버퍼를 생성하고, 렌더링 후에 서버에게 전달하는 일 등을 처리해줍니다.
  • EGL-API(wl-server)..서버에서 사용하는 윈도우 시스템 관련 인터페이스로, 클라이언트가 렌더링한 결과물을 받아서 사용할 수 있도록 준비하는 일 등을 처리해줍니다.
  • EGL-API(gbm)..서버에서 실제로 화면에 출력될 결과물을 렌더링하기 위해 사용하는 인터페이스입니다.
  • KMS-API..서버에서 렌더링한 최종 결과물을 실제 화면에 뿌리기 위해 사용하는 인터페이스입니다. (pageflip, …)

일단 클라이언트와 서버에서 사용되는 인터페이스들을 나누어보면 이 정도가 되겠습니다. 그럼 이제 본격적으로 XDC 2014 에서 발표된 OPENGL 소프트웨어스택과 관련된 발표들을 살펴보도록 하겠습니다. 이 발표들의 기본 목적은 딱 한 가지입니다. 현재 WAYLAND 를 기반으로 한 윈도우 매니저들이 MESA/DRM 에 기반한 EGL/KMS 인터페이스만을 지원하고 있기 때문에 상용 드라이버의 거취가 애매해지고 있습니다. 즉, 위에서 얘기했던 EGL-API 와 KMS-API 를 현재 상용 드라이버는 지원하지 않고 있기 때문에 앞으로 WAYLAND 기반 윈도우 매니저에서는 상용 드라이버를 사용할 수 없다는 것입니다. 그래서 이를 어떻게 해결해 나갈지에 대한 AMD 와 NVIDIA 측이 발표한 내용입니다.

http://www.x.org/wiki/Events/XDC2014/XDC2014DeucherAMD/amdgpu_xdc_2014_v3.pdf
첫 번째로 AMD 에서 발표한 내용을 살펴보도록 하겠습니다. AMD 는 상당히 적극적인 오픈소스 지원/통합 계획을 소개했습니다. 아직 공개되진 않았지만 AMDGPU 라는 기존의 오픈소스 드라이버에 기반한 새로운 오픈소스 드라이버를 제공할 계획이라고 합니다. 이를 통해 기존의 오픈소스 드라이버에서 지원하지 못했던 최신 그래픽 카드를 지원할 계획이라고 하니, 상당히 기대되는 부분입니다. 그리고 향후에는 상용 드라이버보다 오픈소스 드라이버에 더 집중하겠다는 얘기도 하고 있습니다. 일단 더 지켜봐야겠지만, AMD 는 오픈소스 드라이버에 대한 적극적인 지원을 통해 호환성 문제를 해결할 계획인 것 같습니다.

http://www.x.org/wiki/Events/XDC2014/XDC2014RitgerEGLNonMesa/nvidia-and-compositors.pdf
두 번째로 NVIDIA 에서 발표한 내용입니다. 일단 NVIDIA 는 AMD 와는 반대로, 상용 드라이버에서 필요한 인터페이스를 지원할 계획이라고 합니다. 그리고 더 나아가서 EGL 에서 WAYLAND, GBM, KMS 와 관련된 부분들을 표준 인터페이스로 다시 정의해서 개발하자는 얘기를 하고 있습니다. 오픈소스 쪽에서 어떻게 반응할지, 구체적으로 일이 어떻게 진행될지는 지켜봐야겠지만, 개인적으로는 나쁘진 않은 것 같습니다. 그리고 조만간 제안하는 인터페이스를 이용해서 수정한 WESTON 패치를 공개한다고 하니, 그 결과물을 보고나서 좀 더 생각을 해봐야겠습니다.

http://www.x.org/wiki/Events/XDC2014/XDC2014RitgerGLABI/presentation-xdc2014.pdf
마지막으로 NVIDIA 에서 진행하고 있는 좀 더 포괄적인 OPENGL 소프트웨어스택 통합에 대한 발표입니다. 얼마 전에 XDC 2014 행사 소개하는 글을 올리면서 개인적으로 관심이 가는 프로젝트라고 언급했었는데요, 아쉽지만 큰 진척이 있거나 크게 기대할만한 결과물이 나올꺼같진 않아보입니다. 이 프로젝트의 목적을 간단히 소개하면 위에서 언급했던 GL-API 를 제공하는 라이브러리를 하나로 통합하고, EGL-API 도 제조사와 독립적인 부분을 따로 떼서 하나의 라이브러리 형태로 공유하자는 것입니다. 그래서 하나의 시스템에서 여러 드라이버를 동시에 사용하거나, 그 이상의 일들을 해보자는 것입니다. 일단은 이 프로젝트가 계속 진행이 될지, 어떻게 진행이 될지 더 지켜봐야겠습니다.

결론적으로 DRM 드라이버 인터페이스와 EGL/KMS 가 업계 표준으로 인정받은 상황이고, 상용 드라이버 측의 지원도 문제없이 진행될꺼같습니다. 그리고 개인적으로는 ARM 쪽에서도 이런 흐름에 잘 편승했으면 하는 바램을 가져봅니다.

Advertisements

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 를 장악하기 위한 노력들이 끊임없이 이어지고 있네요. 앞으로 어떤 분야에서 어떤 회사가 먼저 치고 나갈지 기대가 됩니다.