월간 보관물: 2014 7월

차세대 3차원 그래픽 가속 표준 전쟁?!

Khronos Group 이 다음 달(8월)에 있는 SIGGRAPH’14 에서 Next-Gen OpenGL 을 공개한다고 합니다. 예전에 AMD 의 Mantle 과 OpenGL 최적화 관련 기사를 소개한 적이 있는데요, 이제 본격적인 전쟁이 시작인가 봅니다. 결국 기존의 OpenGL vs DirectX 에 AMD’s Mantle 과 Apple’s Metal 까지 가세해서 당분간 혼란이 가중될꺼같습니다.

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

이러한 혼란의 원인은 바로 모바일과 리눅스/맥OS의 성장으로 (MS 와 데스크탑으로부터 탈출) 인한 개발 환경의 과도기로 볼 수 있습니다. 그래서 여러 거대기업들의 새로운 언어와 API를 장악하기 위한 노력이 끊이지 않고 있는데요, 개발자들만 고생하게 생겼네요 크…

여기에 머지 않아 레이트레이싱을 위한 하드웨어 가속 표준화까지 본격적으로 시작되면 3차원 그래픽 쪽은 그야말로 멘붕이네요…coming soon…

Advertisements

[TECH] NVIDIA ‘G-SYNC’ GPU-디스플레이 동기화 기술 소개

NVIDIA 에서 G-SYNC 라는 새로운 GPU-디스플레이 동기화 기술을 공개했습니다. 상당히 흥미로운 기술이고 실제 게임 개발자들에게도 큰 환영을 받고 있는 것 같습니다. 아래 동영상을 보면 존 카멕을 비롯한 3명의 유명 게임 개발자들이 G-SYNC 에 대해 호평을 하고 있는 것을 볼 수 있습니다. (다른 그래픽 관련 소프트웨어를 개발하는 사람들에게도 분명 희소속이긴 하지만, 렌더링 시간과 사용자 반응성에 가장 민감한 실시간 3D 게임 쪽에서 가장 효과가 극명할 것 같습니다.)

http://www.geforce.com/hardware/technology/g-sync/videos

오늘은 G-SYNC 에 대한 기술적인 부분들을 간단히 소개드리도록 하겠습니다. 우선 G-SYNC 가 있을 때와 없을 때의 가장 큰 차이를 한 마디로 표현하면 GPU 가 디스플레이의 고정된 화면 갱신 비율을 그대로 따를 것이냐(G-SYNC 가 없을 때), 아니면 GPU 가 디스플레이의 화면 갱신 시기를 알려줄 것이냐(G-SYNC 가 있을 때)입니다. 2013년도에 NVIDIA 가 G-SYNC 를 발표하면서 공개한 자료를 보면서 좀 더 자세히 설명드리도록 하겠습니다.

gsync0위의 그림은 이상적인 GPU 와 디스플레이의 관계를 보여주고 있습니다. 디스플레이 패널(panel)은 고정된 주기로 GPU 가 준비해놓은 프레임버퍼를 스캔(scan)하고, GPU 는 다음 주기까지 다음 프레임버퍼를 준비하는데 문제가 없다면 가장 이상적입니다. (일반적으로 이러한 방식을 V-SYNC, Vertical Sync 라고 합니다.) 하지만 아래 그림처럼 GPU 가 다음 프레임버퍼를 준비하는 것이 조금이라도 늦어지면 다음 화면 갱신 주기를 기다려야하는 문제(lag)가 발생하게 됩니다. (이런 이유로 렌더링 시간을 예측하기 힘든 3D 게임 분야에서 관련 문제가 자주 발생한다는 것입니다.)

gsync1이러한 화면 갱신 지연 문제를 해결하는 가장 간단한 방법은 바로 V-SYNC 를 무시하는 것입니다. 즉, GPU 는 다음 VBLANK(Vertical Blank, 화면 갱신이 끝나고 다음 화면 갱신까지 기다리는 시간) 를 기다리지 않고 강제로 프레임버퍼를 바꿔버리는 겁니다. 아래 그림처럼 일단 화면 갱신이 지연되는 문제는 해결이 되긴 합니다.

gsync2하지만 이 방법은 화면 잘림(tearing) 이라는 새로운 문제를 만들어냅니다. 아래 그림을 보면 알 수 있듯이, 디스플레이가 스캔을 하고 있는 도중에 프레임버퍼가 변경이 되면 화면의 중간까지는 이전 프레임이고 중간 이후부터는 다음 프레임이 나타나는 괴현상이 발생하게 됩니다.

gsync3

gsync4이러한 복잡한 상황들을 한번에 해결하기 위해 나온 기술이 바로 G-SYNC 라고 보시면 됩니다. 즉, NVIDIA 는 현재의 디스플레이가 주도하는 고정된 화면 갱신으로는 이 문제를 깔끔하게 해결할 수는 없다고 보고, 역으로 GPU 가 디스플레이의 화면 갱신을 제어하겠다는 것입니다. 동작 과정은 아래 그림처럼 굉장히 단순합니다.

gsync5GPU 가 프레임버퍼를 렌더링한 후, 디스플레이에게 화면 갱신 명령어를 전달하게 되면 디스플레이는 현재 프레임버퍼를 스캔해서 실제 화면을 갱신하게 됩니다. 프레임버퍼를 생성하는 주체인 GPU 가 실제 화면 갱신을 제어하기 때문에 오히려 동작 과정도 단순해지고, 문제가 생길 여지가 사라진걸 알 수 있습니다. (단순히 영상을 보는 용도의 TV 에서 사용되던 기술이 사용자 반응성이 중요한 컴퓨터에까지 적용되어 발생했던 문제를 현실적으로 해결한 접근이라고 볼 수 있을 것 같습니다.)

이 문제는 리눅스에서 DRM 을 이용해서 그래픽 관련 소프트웨어(윈도우 매니저, …) 를 개발할 때도 발생합니다. 현재의 DRM 에서는 PAGE_FLIP 이라는 API 를 제공하는데, 이 API 의 역할이 요청한 프레임버퍼를 다음 VBLANK 에서 갱신해달라는 것입니다. 이걸 사용하기 싫으면 직접 VBLANK 이벤트를 받아서 처리할 수도 있고, 이를 무시하고 바로 화면을 갱신할 수도 있습니다.

현재 리눅스에서는 NVIDIA 에서 제공하는 최신 드라이버에서는 G-SYNC 를 사용할 수 있을 꺼라고 합니다. 하지만, 여러 가지 이유로 오픈소스 드라이버를 사용할 수 밖에 없는 입장이라서 얼른 NOUVEAU/DRM 에서 G-SYNC 를 지원해줬으면 하는 바램이 있습니다.

[사전모집] 오픈소스 기반 UI/UX 소프트웨어 스터디

오픈소스 기반 UI/UX 소프트웨어 스터디 그룹원을 사전 모집합니다.

0. 목표: 블로그에서 다양하게 다루고 있는 오픈소스들을 실제 코드레벨에서 이해 및 개발

1. 모집 내용
– 시작일 : 7월 중순 ~ 8월 초 (예상)
– 스터디일정 : 4-6주 정도의 개별 코스로 진행
– 모집인원 : 5~10명
– 대상 : 관심있는 개발자 누구나
– 시간 : 협의
– 장소 : 성균관대학교 자연과학캠퍼스 (성균관대역)
– 주제 : 아래 세부주제 참고
– 사전등록 : nemoux00@gmail.com 으로 메일 주세요. (이름, 나이, 소속, 관심분야, 가능시간)

2. 세부 주제(예상)
저희가 일단 대략적인 내용을 잡아보았습니다.
아래의 내용을 참고하고, 일정(4-6주 분량)을 감안하고, 그룹원들의 의견을 반영하여 진행 할 것입니다.
신청자들의 의견을 반영하여 몇개의 코스로 개별적으로 진행해도 좋을 것 같습니다.

1) 필수 오픈소스 활용 능력 개발 : pixman, cairo, pango, udev, evdev, drm/egl, …
2) Wayland/Weston 분석
– 컴포지팅 과정 이해 (pixman/drm renderer, fb/drm/wayland backend, …)
– 입력 장치 관리, 가상 키보드/한글 입력기 동작 과정 이해, …
– 확장 프로토콜 이해 (presentation, subsurface, …)
3) UI/UX 렌더링 최적화 기술 분석
– scene graph 최적화 동작 과정 (retained mode)
– 더블 버퍼링, 디스플레이 동기화 (pagefilp, vblank), 하드웨어 플레인, …
– OpenGL 확장 기능 (buffer_age, unpack_subimage, swap_buffers_with_damage, …)
4) 자신만의 윈도우 매니저 개발
– 컴포지터/쉘 개발 or Weston 쉘 플러그인 개발

신청자들의 의사를 반영하여 조만간 재공지를 하겠습니다.

본 스터디는 다른 의도없이 관련기술들을 함께 공부하는 것이 목적입니다.
열정있는 분들의 많은 신청 바랍니다. 🙂