월간 보관물: 2014 9월

[WAYLAND] 더블 버퍼링 vs 트리플 버퍼링

오늘은 렌더링과 디스플레이 동기화와 관련하여 트리플 버퍼링(?)의 필요성에 대해 간단히 설명하고자 한다. 우선 아래 그림을 참고하면서 필요한 것들을 하나씩 알아보자.

triplebuffering

간단히 그림에서 사용하는 단어들의 의미를 짚어보자. (이전 글들에서 대부분 설명했던 것들이지만)

  • framebuffer[0-2].. 디스플레이에 출력될 화면 버퍼 (1920×1080 해상도와 4 byte 색상을 사용한다면 대략 8 mbyte 의 연속된 메모리를 의미)
  • scanout.. 디스플레이에 프레임버퍼를 전달 (60 hz 재생률을 사용한다면 초당 60 번 프레임버퍼를 전달)
  • vblank.. 다음 스캔아웃까지 대기하는 구간 (원래 의미는 구형 TV 에서 오른쪽 아래에 도착한 레이저빔이 왼쪽 위로 이동하는데까지 걸리는 시간)
  • rendering.. 프레임버퍼를 생성하는 과정 (rendering time 은 렌더링에 걸리는 시간 의미)

우선 기본적인 더블 버퍼링에 대해 알아보자. 대부분의 GUI 프로그램은 기본적으로 더블 버퍼링을 사용한다. 일반적으로 프론트(front) 버퍼는 마지막 화면 버퍼를 보관하고, 백(back) 버퍼는 다음 화면 버퍼를 만들기 위해 사용한다. 만약에 더블 버퍼링을 사용하지 않으면 어떻게 될까? 더블 버퍼링이 필요치 않은 경우도 존재하긴 하지만, 대부분의 경우에는 수정 중인 화면 버퍼가 디스플레이에 출력되는 불상사가 발생하게 된다. 이와 반대로, 더블 버퍼링을 사용 할 경우에는 항상 수정이 완료된 프론트 버퍼가 디스플레이에 출력된다고 보면 된다. 그리고 백 버퍼의 수정이 완료되면 프론트 버퍼와 백 버퍼가 교체되어 동일한 과정을 반복하게 된다.

사실 렌더링 시간이 vblank 보다 짧다면 위에서 설명한 더블 버퍼링만 가지고도 충분하다. 위 그림의 1번 경우처럼 아무 문제 없이 프론트/백 버퍼가 번갈아가면서 초당 60 번의 화면을 갱신하게 된다. 하지만, 레더링 시간이 vblank 보다 길어지면 어떻게 될까? 2번 경우처럼 백 버퍼를 수정하는 시간이 길어지면서 다음 스캔아웃에서도 이전 프론트 버퍼가 디스플레이에 출력된다. 즉, 초당 30 번 밖에 화면을 갱신하지 못 하게 되는 것이다. (부드러운 애니메이션 재생을 위해서는 최소 60 프레임은 지원하는게 좋다.)

이러한 경우에 사용할 수 있는게 바로 트리플 버퍼링이다. 위 그림의 3번을 보면 알겠지만, 일단 세 개의 프레임버퍼를 준비하자. 그럼 더블 버퍼링과 마찬가지로 하나는 프론트 버퍼가 되고, 나머지 두 개는 백 버퍼로 사용된다. 우선, 첫 번째 백 버퍼에 렌더링을 시작하자. 하지만 이 렌더링은 다음(첫 번째) 스캔아웃 때까지 완료되지 않기 때문에, 다음 스캔아웃 때는 이전 프론트 버퍼를 그대로 사용하고, 두 번째 백 버퍼에 다음 렌더링을 시작한다. 다음 렌더링 또한 다음(두 번째) 스캔아웃 때까지 완료되지 않겠지만 첫 번째 백 버퍼가 렌더링이 완료되었기 때문에 프론트 버퍼는 교체할 수 있다. 그리고 교체된 프론트 버퍼를 다시 백 버퍼로 활용하게 되면 이후부터는 초당 60 번의 화면 갱신이 가능해진다. 하지만 트리플 버퍼링을 사용하더라도 완벽한 것은 아니다. 왜냐하면 사용자가 어떤 입력을 넣었을 때 실제로 결과가 반영된 화면은 세 개의 vblank 를 지나서 나타날 것이기 때문이다. 이는 단순히 트리플 버퍼링으로 해결될 문제는 아니고, 디스플레이 동기화 방식과 렌더링을 시작하는 타이밍 등 다양한 사항을 고려해야만 최선의 결과를 찾을 수 있다.

위에서는 간단히 설명하기 위해 문제를 단순화시킨 것이고, 실제로는 렌더링 시간이 들쑥날쑥하기 때문에 이를 효과적으로 처리하기 위한 섬세한 알고리즘이 필요하다.

[스터디-공지] WAYLAND 기반 윈도우 매니저 동작 원리 이해 (2주차)

이번 주 스터디에서는 지난 주에 시간이 부족하여 진행하지 못했던 컴포지팅과 최적화와 관련된 내용을 진행하려고 합니다. 최적화라는게 딱히 정답이 있는게 아니고, 전체 소프트웨어 계층에서 할 수 있는건 다 하자는거기 때문에 디스플레이 동기화, GPU, 컴포지팅, 어플리케이션까지 다양한 계층과 관련된 최적화 이슈를 다룰 예정입니다. 아래는 이번 스터디에서 다루게 될 세부 내용들입니다.

  • 컴포지팅 동작 원리 및 최적화 (scene graph, 데미지/클리핑 관리, …)
  • OpenGL 렌더러 최적화 (buffer_age, unpack_subimage, swap_buffers_with_damage, …)
  • 하드웨어 플레인 최적화
  • 디스플레이 동기화 최적화 (double/triple buffering, …)
  • WAYLAND 프로토콜 최적화 (subsurface protocol, presentation protocol, …)

자세한 사항은 금요일에 올릴 예정인 세미나 자료를 참고하시기 바랍니다. 그리고 세부 모임 공지는 아래와 같습니다.

일시 : 2014년 9월 28일 (일요일) 오후 2시 ~ 4시
장소 : 성균관대학교 자연과학캠퍼스 제 1공학과 21515호 (1호선 성균관대역)
연락 : nemoux00@gmail.com (페이스북 그룹 : https://www.facebook.com/groups/uxcoding/)

그리고 세미나가 끝난 후 따로 약속이 없으신 분들은 가볍게 식사라도 같이 하면 좋을꺼같습니다^^

DisplayPort Comes To USB’s Type-C Connector

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

며칠 전에 VESA 에서 디스플레이 포트 1.3 표준을 공개했다는 글을 올렸는데요, 이번에는 VESA 에서 USB 3.1 의 Type-C 컨넥터를 이용하여 디스플레이 포트를 지원하는 표준(DisplayPort over USB)을 공개했습니다. 이전 글을 쓰면서도 컴퓨터 제조업체가 중심이 되어 만든 인터페이스라서 USB 랑 유사하다는 얘기를 했었는데요, 이젠 아예 호환을 시켜버리네요. 일단 공개된 장점으로는 작은 크기의 컨넥터로 4K 이상의 영상과 음성을 동시에 지원할 수 있고, 100 와트까지의 전력을 단일 케이블로 전송할 수 있다고 하네요. 그리고 당연히 USB 가 제공하는 멀티채널과 토폴로지까지 활용할 수 있을 것으로 기대됩니다.

USB 와 경쟁하는 썬더볼트가 엉뚱한데서 한 방 먹었군요. 앞으로 어떻게 진행될지 기대됩니다. 개인적으로는 주변기기뿐 아니라 디스플레이까지 USB 로 통일되면 편할꺼같긴 합니다.

시선추적 헤드마운트 디스플레이 ‘FOVE’

http://www.moknol.com/2014/09/fove.html

일본의 스타트업 회사에서 재미난 물건을 만들어냈네요. 간단히 얘기하면, 오큘러스 리프트에 시선추적 기능을 탑재한 제품입니다. 위 링크에 홍보(데모) 동영상이 포함되어있으니 한번 보시면 대충 뭘 하는 건지는 쉽게 알 수 있을 것 같습니다. 근데 한 가지 걱정이 되는건 립 모션 때와 마찬가지로 움직이는 동작(motion)을 인식하는건 당연히 가능하겠지만, 선택하는 동작(click)은 어떻게 인식하느냐입니다. 포인팅 장치의 기본 요구 사항이 바로 motion 과 click 인데요, 일단 motion 은 시선추적으로 편리하고 재밌게 해결할 수 있지만, click 은 어떻게 해결할 생각인지가 궁금하네요. 일단 간단히 생각해보면 두 가지 방식이 있을텐데요, 첫 번째는 눈의 위치로 motion 을 처리하고 손으로 click 을 처리하는 방식이고, 두 번째는 눈의 위치로 motion 을 처리하고 눈의 깜빡임으로 click 을 처리하는 방식입니다. 전자는 뭔가 좀 아쉬운 느낌이 들고, 후자는 눈을 깜빡이는 중에 눈의 위치가 흔들려서 정확도가 떨어지는 문제가 발생할꺼같습니다. 머 일단 정확한건 좀 더 자세한 내용이나 데모 동영상이 공개되면 알겠지요. 암튼 재밌는 물건임에는 틀림없는것 같습니다.

[스터디-공지] WAYLAND 기반 윈도우 매니저 동작 원리 이해 (1주차)

이번 주 스터디에서는 WAYLAND 기반 윈도우 매니저의 출력 과정에 대한 내용을 진행하려고 합니다. 윈도우 매니저의 가장 중요한 역할이면서 성능에 가장 많은 영향을 주는 것이 컴포지팅이기 때문에 실제로 다루어야 할 내용 또한 많은 것 같습니다. 아래는 이번 스터디에서 다루게 될 세부 내용들입니다.

  • 윈도우 매니저 출력 과정 이해 (클라이언트 & 서버 구조, …)
  • 공유 메모리 기반 컴포지팅 동작 과정 이해 (shm, pixman, …)
  • 하드웨어 가속 기반 컴포지팅 동작 과정 이해 (opengl/egl, drm/kms, …)
  • 컴포지팅 과정 이해 (scene graph, …)
  • 디스플레이 동기화 과정 이해 (더블 버퍼링, vertical sync, …)

이번 주에 할 내용을 간단히 얘기하면, 어플리케이션(윈도우 클라이언트)이 윈도우에 무언가를 그리고 윈도우 매니저(윈도우 서버)가 이를 반영하여 실제 화면(모니터)에 뿌리는 과정에 대한 내용이라고 보시면 됩니다. 다루어야 할 내용과 이해가 필요한 부분이 많기 때문에 최적화와 관련된 내용과 확장 기능은 3주차에 진행할 계획입니다.

세부 모임 공지는 아래와 같습니다.

일시 : 2014년 9월 20일 (토요일) 오후 2시 ~ 4시
장소 : 성균관대학교 자연과학캠퍼스 제 1공학관 21515호 (1호선 성균관대역)
연락 : nemoux00@gmail.com (페이스북 그룹 : https://www.facebook.com/groups/uxcoding/)

본 스터디는 UI/UX 관련 오픈 소스에 대한 인프라가 조금이라도 넓어졌으면 좋겠다는 마음으로 시작한 것이니 이제 공부를 시작하시는 분들도 편한 마음으로 오시면 좋겠습니다. 그리고 참석하실 분들은 미리 연락주시면 감사하겠습니다.

Matrox Releases New Multi-Head PCI-E Graphics Cards

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

캐나다의 산업용 그래픽 솔루션 개발 업체인 매트록스(Matrox)에서 멀티 디스플레이를 지원하는 PCI-E 그래픽 카드를 발표했네요. 일단 AMD GPU (OpenGL 4.4/OpenCL 1.2 지원) 와 mini DP (4K 지원) 를 지원하는 거외에 딱히 공개된 내용은 없지만, NVIDIA 의 Mosaic 이 쿼드로 GPU 를 병렬로 연결해서 멀티 디스플레이를 지원하는 것과는 달리 하나의 GPU 에 여러 디스플레이를 연결하는 방식이네요. 두 가지 접근 방식이 서로 다른 장단점이 있기 때문에 향후 어떤 양상을 보일지는 지켜봐야겠습니다. 좀 더 자세한 사항이 공개되면 정리해서 올리도록 하겠습니다.

[TECH] 멀티미디어 인터페이스 (Display Port)

본체에 모니터를 연결하는 멀티미디어 인터페이스에도 여러 가지 종류가 있습니다. 과거에 많이 사용되던 D-SUB 나 컴포지트 같은 아날로그 인터페이스도 있었고, DVI 같은 디지털 인터페이스도 있었습니다. 그리고 최근 많이 사용되고 있는 HDMI 는 디지털 영상과 음성까지 전달할 수 있고 케이블도 작아서 여러 기기에서 사용하기 편리하지만, 라이센스를 맺고 특허 사용료를 지불해야 하는 문제가 있다고 합니다. 이를 해결하기 위해 나온게 PC 업체들이 주축이 되서 만든 디스플레이 포트(Display Port)인데요, 오늘은 간단히 디스플레이 포트가 어떤 장점을 가지는지, 향후 어떻게 활용될 수 있을지에 대해 살펴보도록 하겠습니다.

우선, 디스플레이 포트는 HDMI 가 AV 업체들(소니, 파나소닉, …)이 주축이 되어서 만들어진 것에 비해 PC 업체들이 주축이 되어 만들어졌습니다. 그래서 그런지 USB 랑 상당히 유사해 보입니다. 디지털 영상 뿐 아니라 음성까지 하나의 케이블을 통해 멀티플렉싱할 수 있기 때문에 전송할 수 있는 영상이나 음성의 포맷에 제한이 없습니다. 본체와 멀티미디어 기기간의 프로토콜만 맞다면 다양한 영상/음성 포맷의 데이터를 주고 받을 수 있습니다. 또한 MST(Multi-Stream Transport)라는 이름으로 멀티 채널 기능을 제공합니다. 이는 여러 개의 영상/음성을 하나의 케이블을 통해 전송할 수 있다는 얘긴데요, 간단히 얘기하면 본체에서 하나의 케이블로 3개의 영상/음성을 보내면 데이지-체이닝(Daisy-Chaining) 이나 허브를 통해 3개의 모니터에 각각의 영상/음성을 전송할 수 있다는 얘깁니다. 그리고 전송 속도도 현재 주로 사용되고 있는 HDMI 1.4 의 10.2 Gbps 보다 높은 17.28 Gbps (DP 1.2 버전 기준) 를 제공합니다. 그래서 최근 필자가 구매한 4K 모니터 (3840×2160) 에서는 60 hz 를 사용하기 위해서는 반드시 디스플레이 포트를 사용해야 합니다. (4K 모니터에서 60 hz 를 구현하기 위해 필요한 대역폭이 약 15 Gbps 정도 됩니다.)

사실 필자가 디스플레이 포트에 주목하는 가장 큰 이유는 바로 멀티 채널 기능입니다. 간단한 예를 하나 들어보면, 현재 두 개의 모니터를 미러링하기 위해서는 (해상도가 같다면) 본체(GPU)에서 하나의 프레임버퍼를 두 개의 모니터로 스캔-아웃해주는 방식을 사용합니다. 하지만 디스플레이 포트를 잘 활용한다면 본체는 하나의 영상/음성 스트림만을 전송하고 데이지 체이닝으로 연결하거나 허브를 이용해서 동일한 스트림을 두 개의 모니터가 받아서 화면에 뿌려주면 됩니다. 본체에 부담도 덜어줄 수 있고 동기화도 쉬워지겠지요. 또한 더 나아가서 멀티 디스플레이를 지원할 때도 유리할 꺼라 생각합니다. 본체에서 각각의 화면에 뿌려질 데이터를 여러 채널로 나누어서 전송할 수도 있을 것이고, 본체에서는 하나의 큰 화면을 만들어서 뿌리고 허브에서 각각의 모니터에 맞게 화면을 쪼개서 뿌려줄 수도 있습니다. 아직은 대역폭이 그만큼 나오지 않고 지원하는 장비가 없기 때문에 이런 형태의 사용은 불가능하지만, 결국 이런 것들을 하기 위해 나온게 디스플레이 포트이기 때문에 머지않아 실현될 수 있을 것으로 기대됩니다.

마지막으로 이러한 기능을 제대로 활용하기 위해서는 소프트웨어 쪽도 많은 것들이 준비가 되어있어야 하는데요, 현재는 레드햇에서 MESA/DRM 에 디스플레이 포트를 지원하는 작업을 진행하고 있습니다. 하지만 이제 시작하는 단계라서 꽤 시간은 걸릴꺼같습니다.