Frame Buffer 이야기 (9) - 마지막

출처: KELP 이규명님의 강좌 http://kelp.or.kr/korweblog/stories.php?story=02/11/09/8557035&topic=29

== 시작하기에 앞서
이 글에 있는 모든 내용은 글쓴이가 가지고 있는 ATI mach 64(2MB) 그래픽 카드가 달려있고 RedHat 8.0이 설치된 PC(또는 Permedia2(8MB) 그래픽 카드가 달려 있는 RedHat 7.3이 설치된 PC)에서 제대로 동작하지만 이 글에 있는 모든 내용이 정확하다고 말씀 드릴 수 없습니다. 이 글에 있는 내용을 따라 했을 때 혹 생길 지 모르는 모든 문제에 대해서 글쓴이는 책임을 지지 않습니다. 글의 내용 중에 잘못된 내용이 있거나 질문할 것이 있으면 위쪽의 “holelee”를 누르고 메일을 보내기 바랍니다.


== 시작
이번 글이 frame buffer 이야기의 마지막 글이 될 겁니다. 이제까지 linux frame buffer를 이용하여 화면에 그림을 그리는 것에 대한 내용을 모두 마쳤다고 볼 수 있습니다. 현실적인 제약으로 인해 모든 frame buffer에 대해서 테스트를 해보거나 할 수는 없었지만 그래도 어느 정도 프로그래밍을 위한 기초적인 정보는 모두 살펴봤다고 볼 수 있습니다. 이번 글에서는 “frame buffer 프로그래밍으로 무엇을 할 수 있나?”에 대해서 알아본 후에 frame buffer가 실제로 사용되고 있는 프로그램들에 대해서 짤막하게 소개하도록 하겠습니다. 그 다음 linux frame buffer의 한계에 대해서 생각해 보는 시간을 갖도록 하겠습니다. 준비가 되었다면 시작하도록 하죠.


== frame buffer 응용
이제 까지 frame buffer를 이용하여 화면에 나타날 pixel을 찍거나 이미 화면에 있는 pixel을 읽을 수 있다는 것을 알아보았습니다. 그럼 이런 방법론을 이용하여 실제로 응용할 수 있는 분야는 어떤 것이 있을까요? 당연히 2차원 컴퓨터 그래픽을 전부를 할 수 있습니다. 2차원 컴퓨터 그래픽을 사용하고 있는 분야는 상당히 많이 있죠. 하지만 실제 embedded system에서 사용할 만한 가능성이 있는 것들만 추려보면 다음과 같습니다.
(1) 그래픽 파일 viewer나 동영상 player
(2) GUI(Graphic User Interface)
더 생각이 나지 않는 군요.(더 좋은 응용 분야를 알고 있는 사람은 리플을 달아주기 바랍니다.)
(1) 번이야 쉽게 이해가 되죠? 예를 들어 요즘 지하철 열차 내에 설치되어 있는 LCD를 이용한 광고 장치(?, OS로는 MS Windows를 사용하는 것으로 보입니다. 따라서 열차 내의 어딘가에는 PC가 있을 것으로 보입니다. 오로지 출력만 여러 LCD로 연결했을 가능성이 큽니다.)와 같이 일방적으로 사람들에게 화상 정보를 보내는 장치는 frame buffer를 이용해서 프로그래밍하면 될 겁니다.(지하철 역사에는 PDP와 프로젝션이 설치되고 있는 추세더군요.)
GUI의 경우도 역시 2차원 컴퓨터 그래픽을 이용하는 분야이므로 frame buffer를 이용할 수 있습니다. 물론 GUI는 어디까지나 사용자의 입력도 받아야 하므로 사용자의 입력을 받을 수 있는 장치가 필수죠. 대부분 마우스나 터치스크린과 같은 pointing device와 같이 이용합니다. (1)이 GUI위에 올라갈 수도 있죠.


== linux frame buffer의 장점
linux 시스템에서 frame buffer를 이용할 때 장점은 딱 한가지 있습니다. 포팅의 용의성입니다. 예를 들어 frame buffer에 결과를 출력하는 동영상 player를 만들었다고 하면 그 player는 오로지 linux kernel(frame buffer driver포함)에만 의존적(dependent)입니다. 또한 비교적 frame buffer 프로그래밍 interface가 잘 되어 있고(문서는 어디 있는지 찾기 어렵지만), 그것이 하드웨어(그래픽 카드)에 의존적이지 않습니다. 결국 의존성(dependency)이 작으므로 한번 작성된 프로그램을 여러 embedded target으로 포팅하기 쉽게 됩니다.


== linux frame buffer를 이용하고 있는 프로그램들
linux에서 frame buffer를 이용하고 있는 프로그램들의 범주 역시 위에서 살펴본 “응용”과 별반 다르지 않습니다. 실제로는 더욱 많이 이용되고 있겠지만 사람들의 입에 자주 오르내리는 몇가지 프로그램만 소개하도록 하겠습니다.

= 동영상 player
(*) Xine(http://xine.sourceforge.net/)
(*) MPlayer(http://www.mplayerhq.hu/)
Linux에서 가장 유명한 두 개의 동영상 player입니다. 두 프로그램 모두 많은 동영상 코덱(codec)을 지원하고 많은 video output driver와 audio output driver를 지원합니다. 지원하는 video output driver 중에 linux frame buffer가 있습니다.

= GUI
(*) X server(http://www.xfree86.org)
X 를 빼 놓고는 linux의 GUI를 이야기할 수 없죠. XFree86은 사실상 PC를 주된 target으로 합니다. 사이트에서 살펴보면 PC에서 사용되는 많은 그래픽 카드를 나열해 놓고 지원한다고 말하고 있습니다. 특정 그래픽 카드에 맞게 최적화된 드라이버를 계속 만들어 내고 있습니다. 그 드라이버가 하드웨어를 직접 제어해서 화면을 구성합니다.
XFree86에서 지원하는 드라이버 중에 linux frame buffer도 존재합니다. 보통 linux frame buffer를 이용하도록 컴파일된 X server를 TinyX라고 부릅니다.

(*) Qt/Embedded(http://www.trolltech.com/products/embedded/)
KDE에 주로 이용되고 있는 toolkit인 Qt는 trolltech에서 만들었습니다. 그 toolkit을 embedded system으로 포팅한 것을 Qt/Embedded라고 한다고 합니다. PC에서는 Qt toolkit이 화면에 무엇인가를 나타내려고 할 때 X를 사용했겠지만, X가 올라가 있지 않는 embedded system에서는 frame buffer를 이용할 수 밖에 없습니다.(위에서 설명한 의존성이 가장 작은 interface이기 때문이죠.)
참고로 Qt/Embedded는 license를 받아야 하는 상용 프로그램으로 알고 있습니다.

(*) microwindows(http://www.microwindows.org/)
Opensource GUI에서 유명한 녀석이죠. 역시 linux frame buffer를 지원합니다.


== linux frame buffer의 한계
frame buffer를 이용하여 그래픽을 출력하는 프로그램이 과연 성능이 좋을까요? 성능이 좋다면 XFree86에서 계속 그래픽 카드에 포팅하고 있지도 않고 PC에서 동작하는 X도 frame buffer를 이용할 겁니다. 그런데 여전히 새로 나오는 그래픽 카드에 포팅은 진행하고 있고, PC linux에서는 frame buffer가 없이도 X는 잘 동작합니다. 결국 frame buffer는 성능이 좋은 그래픽 interface는 아니라는 말입니다.
현재 시장에 나오고 있는 그래픽 카드는 3D 가속기능을 가지고 있습니다. Frame buffer야 3차원과는 거리가 있으니까 무시해도 됩니다. 그런데 MS Windows 3.1이나 MS Windows95가 시장에서 힘을 쓰고 있던 시절에는 그래픽 카드들이 모두 “Windows Acceleration”이란 광고를 하고 있었습니다. 이 “Windows Acceleration”이라는 기능이 2차원 그래픽 가속기능인데 현재 시장에 있는 그래픽 카드는 모두 이런 기능을 가지고 있습니다. 이 기능을 간단히 이야기하면 bitblt(bit-blit이라고 발음되고 bit block transfer의 약자임)이라고 하여 그래픽 카드가 스스로 bitmap을 화면(그래픽 메모리)의 이곳 저곳으로 여러 가지 연산과정과 함께 옮길 수 있는 기능입니다. 또한 그래픽 카드가 PCI나 AGP의 bus mastering(일종의 DMA)을 이용하여 시스템 메모리에 있는 bitmap을 화면(그래픽 메모리)으로 전송할 수도 있습니다. 그리고 rectangular를 특정 색깔로 채우거나 하는 것도 그래픽 카드가 스스로 수행하죠. 이러한 2차원 그래픽 가속능력은 GUI의 속도를 개선하는데 필요한 핵심 기능 중에 하나입니다.
Frame buffer를 이용한 프로그램은 모두 CPU가 직접 해 줄 수밖에 없습니다. Bmp viewer 예제에서 보았듯이 pixel 하나 하나를 CPU가 직접 그래픽 메모리로 옮겨야 합니다. 또한 그래픽 메모리의 일정 부분을 다른 곳으로 옮길 때도 CPU가 해줄 수밖에 없습니다. 문제는 테스트에서 사용된 ATI mach64나 Permedia2와 같은 그래픽 카드도 그러한 가속기능을 가지고 있는데도 Frame buffer interface로는 그러한 가속 기능을 이용할 수 없다는 점입니다. 즉 하드웨어의 문제가 아니라 interface의 문제인 것이죠. 물론 StrongARM에 있는 LCD controller는 bitblt가 같은 것을 수행하지 못합니다. 그렇다고 embedded linux에서 사용되는 그래픽 하드웨어가 모두 2차원 가속 기능을 가지지 않는다고 단정지을 수는 없습니다. Embedded linux에 국한 시켜봐도 frame buffer interface가 완전하다고 말할 수는 없습니다.
(linux frame buffer driver 내부에서 console(console on FB)을 scroll할 때 그래픽 카드의 가속 기능을 이용하는 경우가 있기는 합니다. 하지만 유저 프로그램이 그런 기능을 직접 이용하는 방법은 제가 아는 한 없습니다.)
완전한 interface라면 그래픽 하드웨어가 가지고 있는 모든 가속기능을 이용할 수 있도록 해야 합니다. StrongARM의 LCD controller와 같이 그런 기능이 없으면 그것을 CPU가 직접 소프트웨어로 처리하고, 있으면 최대한 하드웨어를 이용할 수 있는 interface가 필요합니다.
(*) DirectFB(http://www.directfb.org)
아마도 이름은 MS의 DirectX에서 따온 것으로 보입니다. 위에서 설명한 완벽한 interface를 제공하기 위해 열심히 뛰고 있는 사람들입니다. Linux frame buffer와 그래픽 하드웨어용 루틴을 합쳐서 동일한 interface를 제공하도록 라이브러리화한 것으로 보입니다. 이 DirectFB위 GTK+ toolkit을 포팅한 것도 찾아볼 수 있습니다.(참고로 GTK+는 free입니다.)


== 글을 모두 마치며
이제까지 linux frame buffer에 관련된 많은 내용을 알아봤습니다. Frame buffer는 PC에서도 사용할 수 있기는 하지만 전체적으로 embedded target을 위한 interface라고 볼 수 있습니다. Linux Framebuffer HOWTO와 같은 문서를 보면 PC에서는 결국 부팅할 때 “펭귄”을 보려고 삽질을 한다고 나옵니다. 아무래도 PC는 X를 사용하기 때문에 별로 의미가 있는 그래픽 interface라고 하기는 어렵습니다. Embedded target에서 frame buffer 프로그램을 작성할 때 도움이 되고 사람들이 frame buffer 프로그래밍이 별 것 아니구나 하는 생각이 들었으면 좋겠다는 조그만 바람으로 시작한 글이었는데, 결과가 어떨지는 잘 모르겠습니다.
그리고 전체적으로 급히 작성을 해서 글의 완성도가 여러모로 떨어지고, 약간은 장난기가 섞여 있는 것으로 보입니다. 그냥 이해하고 봐주셨으면 좋겠습니다. 아무튼 여기까지 읽어 주신 분들에게 감사 드립니다.
다음 기회에는 좀더 좋은 주제로 글을 잘 적겠습니다.

혹, 다루었으면 하는 좋은 주제가 있으면 리플이나 메일로 알려주시기 바랍니다. 물론 제가 아는 것이 별로 없으므로, 모든 주제에 대해서 글을 적을 수 있다고 할 수는 없습니다. 그리고 하드웨어에 의존적인 부분에 대해서는 테스트를 할 수 없으니 그런 주제도 피해야 하구요. 또한 제 관심사에 벗어난 일(예를 들어 GUI 프로그래밍)이라면 당연히 안되겠죠. 푸후…이렇게 하고 나니 글을 적을 만한 주제가 없겠네요. 다시 질답란에서만 활동하며 글을 적을 만한 주제를 찾아야겠습니다.