http://dx.doi.org/10.5392/jkca.2013.13.08.044 3 차원그래픽스기하파이프라인기반의래스터파이프라인구현 Raster Pipeline Implementation based on 3D Graphics Geometry Pipelines 백낙훈경북대학교 IT 대학컴퓨터학부 Nakhoon Baek(oceancru@gmail.com) 요약래스터연산은트루컬러이미지 ( 픽스맵 ) 나, 단색이미지 ( 비트맵 ) 을표현하기위해서광범위하게사용된다. 이기능은이미지프로세싱기능이나, 폰트출력시에강하게요구된다. 반면에, OpenGL ES 하드웨어등을포함하는, 현재의모바일그래픽스플랫폼들에서는이기능을직접제공하지는않는다. 모바일그래픽스플랫폼들에서이러한래스터연산을완벽히제공하기위해서, 본논문에서는그래픽스이미지들을 3차원점들의집합으로해석하고, 풀-소프트웨어구현방식으로, 이들 3차원점들을전형적인 3차원기하파이프라인으로처리하게했다. 구현결과는충분한실행속도를보였고, 정확도를증명하기위한공식검증테스트 (conformance test) 들을모두통과하였다. 중심어 : 래스터연산 기하파이프라인 소프트웨어구현 Abstract Raster operations are widely used to display full-color graphics images (or pixmaps) and single-color images (or bitmaps). These features are strongly needed for image processing applications and font output. However, current mobile graphics platforms, including OpenGL ES hardware implementations, do not directly support these features. To fully support those raster operations on the mobile graphics platforms, we interpreted the graphics images as a set of 3D points, and processed those 3D points through the typical 3D geometry pipelines, in a full-software implementation. Our implementation shows sufficient execution speeds, and passed the official conformance tests to show its correctness. keyword : Raster Operation Geometry Pipeline Software Implementation I. 서론컴퓨터그래픽스분야에서는 [ 그림 1] 에서와같이, 래스터 (raster) 형태로저장된이미지 (image) 를화면에그대로보여주는, 래스터출력기능이반드시요구된다. 래스터이미지는일반적으로픽셀 (pixel) 값들의 2차원 사각형배열로표현된다. 이러한이미지들을화면에그대로표현하는방식은웹브라우저 (web browser) 나워드프로세서 (word processor) 등의일반적인프로그램들에서도제공되는기능이다. 따라서, 래스터출력기능들은대부분의그래픽스플랫폼들에서전통적으로제공되어왔다 [1-3]. * 본연구는문화체육관광부및한국콘텐츠진흥원의 2013년도문화콘텐츠산업기술지원사업의연구결과로수행되었음. 접수일자 : 2013년 05월 16일심사완료일 : 2013년 07월 23일수정일자 : 2013년 07월 15일교신저자 : 백낙훈, e-mail : oceancru@gmail.com
3 차원그래픽스기하파이프라인기반의래스터파이프라인구현 45 자주사용하는래스터이미지들은정보의내부저장방식에따라, 크게픽스맵 (pixmap) 과비트맵 (bitmap) 으로구분한다. 픽스맵은보통 [ 그림 1](a) 에서와같이, 픽셀마다 RGBA(red, green, blue, alpha) 또는 RGB(red, green blue) 형태의트루컬러 (true color) 색상값을저장한다. 화면에는저장된이미지가그대로재생되는방식으로사용된다. (a) 픽스맵 (b) 배경이투명하게처리된비트맵 (c) 전경색이적용된비트맵그림 1. 픽스맵과비트맵의예 비트맵의경우는픽셀별로 0 또는 1의 1비트값만을저정한다. 비트맵을출력할때는 [ 그림 1](b) 에서와같이, 그대로흑백이미지 (black-white image) 로재생할수도있지만, 별도의전경색 (foreground color) 을설정하여, 비트값이 1인부분은전경색으로나오게하고, 비트값이 0인부분은출력하지않아서투명하게처리하는방식을주로사용한다. 이러한투명처리가가능한비트맵출력방식은 [ 그림 1](c) 에서와같이, 폰트 (font) 출력에유용하다. 래스터이미지를처리하는래스터파이프라인 (raster pipeline) 은워크스테이션이나 PC에서사용하는전통적 인그래픽스하드웨어에서는반드시필요한기능으로분류되지만, 스마트폰, 태블릿 PC 등을대상으로하는모바일그래픽스 (mobile graphics) 분야에서는조금다른관점을가지고있다. 모바일그래픽스분야는스마트폰과태블릿 PC 시장의급격한확대로, 그영향력이커지고있고, 현재는완전한 3D 그래픽스출력기능을가지고있다 [4]. 현재의모바일그래픽스용그래픽스표준들로는 OpenGL ES 표준들이주로사용되고있다. 이들은표준의제정당시부터상대적으로열악한저수준하드웨어에서의사용을상정하였다. 그결과로, 이들표준에서는불필요하거나, 상대적으로사용빈도가떨어지는기능들을제거하여, 생산비를낮추고, 제한된자원을효율적으로사용하도록하였다. 이선택과정에서, 래스터파이프라인은의도적으로제거되었다 [5]. 당시에는다른고급 3차원그래픽스기술의발전으로, 래스터기능들에대한요구가점차줄어들것으로예상하였으나, 비트맵폰트의출력이나, 이미지프로세싱연산들에서는지금도여전히래스터연산들이요구되고있다. 모바일그래픽스분야에서는현재 OpenGL 계열의라이브러리들이대세를이루고있다. OpenGL 계열은현재워크스테이션, PC, 임베디드시스템등의거의모든컴퓨터플랫폼들에서가장널리사용되는그래픽스라이브러리이다. 원래의 OpenGL 은워크스테이션과 PC 용으로개발되었고, 하드웨어상에별도의래스터파이프라인을설치하도록하여, 다양한래스터연산을제공했다 [6]. 반면에, 모바일그래픽스분야를위해별도로제정된 OpenGL ES (embedded system) 버전 1.0, 1.1, 2.0, 3.0 등에서는일체의하드웨어래스터파이프라인이나, 이를사용하기위한 API 함수들을제거하였다. 이에따라, 픽스맵이나비트맵이미지를직접적으로출력할수없는상황이다 [5][7][8]. OpenGL ES 계열의초기설계당시에는 3D 그래픽스처리의핵심이되는기하파이프라인 (geometry pipeline) 에서제공하는텍스처매핑 (texture mapping) 기법으로픽스맵이나비트맵을간접적으로처리할수있다고판단하였다 [5]. 반면에, 기존의다양한 OpenGL
46 한국콘텐츠학회논문지 '13 Vol. 13 No. 8 응용프로그램들에서는픽스맵을이용한트루컬러이미지출력이나, 비트맵을이용한문자출력등이예상외로빈번하게사용되고있다. 또한, 텍스처매핑기법을사용하려면, 화면에단순한 2차원이미지를출력하려고해도, 3차원기하파이프라인에서의처리를위해, 3차원물체를구성하고, 카메라와조명을새로설정하고, 텍스처를입력하는단계를모두거쳐야한다는점은상당히번거로운작업이된다. 가장먼저나타난기술적인문제는기존프로그램들의문자출력이대부분비트맵방식으로구현되었다는것이다. 예를들어, 많은플랫폼에서사용하는 GLUT (OpenGL Utility Toolkit) 라이브러리에서는, 초기 OpenGL 의영향으로, glutbitmapcharacter(...) 함수를사용하여비트맵방식의문자를출력하는것이일반적이다 [9]. 문제는모바일그래픽스분야의표준인 OpenGL ES 에서는더이상이러한비트맵에대한처리를지원하지않는다는것이다. 이것은기존프로그램들의포팅 (porting) 시에심각한문제가될수있다. 본논문에서는래스터파이프라인이별도로제공되지않는모바일그래픽스표준들에서, 픽스맵과비트맵의출력을비롯한래스터파이프라인의기능들을제공하는방법을제시한다. 기존의문헌에서는텍스처매핑기법으로처리가가능하다고간단히언급되어있었지만 [10], 저자들이아는한, 실제적구현방법이나, 상세한처리내용들이출판된적은없었다. 특히, 우리는텍스처매핑으로래스터파이프라인을대체할수있을것이라는기존의기대들에반하여, 실제구현시에의외로문제가생길수있는상황들을발견하였다. 우리는픽스맵과비트맵을대응되는점집합 (point set) 으로보고, 3차원기하파이프라인을통하여정확한최종출력을얻는방법을제시한다 [11]. 2장에서는래스터연산의세부사항들과이에연관된기술적문제점들을보인다. 3장에서는본논문에서제시하는구현전략에따른알고리즘들을제시한다. 구현결과와이에대한분석은 4장에서다루고, 마지막으로 5장에서결론과향후과제를보인다. II. 문제분석및구현전략래스터파이프라인은이미지 (image) 나폰트 (font) 정보를담고있는 2차원색상배열 (color array) 을주어진그대로화면에출력하는기능을담당한다. 간단한 2차원구현들에서는 2차원화면상의좌표를주면, 대응되는 2차원이미지가주어진크기그대로화면에출력되는방식을취하기도한다 [12]. 반면, 3D 그래픽스라이브러리들에서는주된처리대상이되는 3차원기하물체 (geometry object) 와의융합적인사용을위해, 처리방법이보강되어있다 [6]. 여기서는 OpenGL 계열을기준으로각각을설명하되, 설명의편의상, 픽스맵출력방식을먼저설명하고, 비트맵출력방식을보이겠다. (a) 픽스맵의출력 (b) 좌표변환과정그림 2. 픽스맵이미지의처리 픽스맵의출력은출력위치를설정한후에, 출력할픽스맵을보내는방식이된다. 이를위한 raster 함수는다음과같다 : RasterPos(float x, y, z) : 래스터출력이나와야할위치인 current raster position을 3차원좌표로설정한다. [ 그림 2](a) 에서와같이, 이 3차원좌표는통상현재설정된 3차원기하파이프라인의설정을그대로사용
3 차원그래픽스기하파이프라인기반의래스터파이프라인구현 47 하여, 대응되는 3차원기하좌표를기준으로출력위치를설정할수있게한다. DrawPixels(int width, height, enum format, type, void* data) : 픽스맵 1개를 data 영역에저장된, width height 크기를가지는 2차원색상배열로정의하고, 이픽스맵을 current raster position 에출력한다. 색상정보의저장형태는 format 과 type에서설정하는데, 주로 RGB (red, green, blue) 또는 RGBA (red, green, blue, alpha) 형태를사용한다. 픽스맵의처리에있어서는좌표의설정과정에서기술적인문제가발생한다. RasterPos(...) 함수는물체좌표계 (object coordinate system) 에서좌표를설정하지만, 픽스맵의출력시에는윈도우좌표계 (window coordinate system) 에서의 2차원좌표를필요로한다. 본논문의구현에서는최종위치를계산해내기위해서, OpenGL의좌표변환과정을그대로에뮬레이션했다. 즉, [ 그림 2](b) 에서와같이, modelview matrix, projection matrix, perspective division, viewport transformation 등의연산을각단계별로차례로적용하여, 최종적인윈도우좌표를구하였다. 비트맵의출력을위해서는전경색 (foreground color) 을설정해야하고, 0/1로구성된비트맵정보를보낼필요가있다. 다음함수들이그러한기능을수행한다. Color(float r, g, b, a) : 비트맵은색상이출력되어야할부분을비트 1로표현하는데, 이때, 실제사용될색상을지정하는함수이다. 2가지모드의설정이가능한데, 단순한경우는해당색상을그대로사용하지만, 그래픽스시스템의렌더링부분이 L&M(light and material, 광원과물성 ) 계산을사용하도록설정되어있는경우라면, 해당색상을가지는점 (point) 이 3차원상에서 current raster position에주어졌을때, 실제 3차원렌더링파이프라인에서계산해낸최종픽셀색상을사용하도록한다. 이색상은 current raster color 로저장된다. Bitmap(int width, height, float xorg, yorg, float xinc, yinc, void* data) : 비트맵은 width height 크기를가지되, 각색상정보가 0 또는 1로설정된 2차원배열형태로 data 영역에저장된다. 이기능은문자 (character font) 출력에자주사용되는데, 이를위해, 실제출력되는배열을 (xorg, yorg) 픽셀만큼 shift 시켜서사용하고, 출력이끝나면, current raster position 을 (xinc, yinc) 픽셀만큼이동시켜서, 다음글자의출력에대비하도록한다. 또한, 색상정보가 1인부분은 current raster color로출력하되, 0인부분은전혀출력하지않아서, 투명하게처리되어야한다. (a) 비트맵의출력 (b) L&M 처리그림 3. 비트맵이미지의처리 비트맵출력에서발생하는또다른기술적문제는전경색 (foreground color) 의계산이다. L&M 기능이켜져있는경우에는 [ 그림 3] 에서와같이, 결국광원과재질에대한하드웨어계산과정을에뮬레이션해야한다. 본논문에서의구현은이전체과정을소프트웨어로에뮬레이션해서, 동일한결과를구하도록했다. 픽스맵과비트맵의연산을구현하는방법들중에서, 가장널리알려진것은텍스처매핑기능을사용해서
48 한국콘텐츠학회논문지 '13 Vol. 13 No. 8 간접적으로구현하는방식이다. 이방식은 [ 그림 4] 에서와같이, 출력하려는픽스맵이나, 비트맵을텍스처이미지로저장한후에, 출력을원하는위치에 2차원평면직사각형을출력시키면서, 텍스처매핑을적용하면, 저장된이미지가출력된다. 그림 4. 텍스처매핑방식의처리이러한방식은몇가지문제점을가지는데, 이들은다음에설명하는것과같이, 텍스처매핑기능의기술적한계때문에발생한다. 텍스처의크기에제한이있다 : 전형적인모바일그래픽스파이프라인에서는하드웨어의성능문제로, 텍스처의크기가반드시 2의승수가되도록제한을가한다. 일반적인직사각형형태를모두허용하려면, 스텐실매스킹 (stencil masking) 과같은, 좀더고급의그래픽스기법도함께적용해야한다. 텍스처매핑은많은계산량을필요로한다 : 대부분의모바일그래픽스시스템에서는텍스처매핑하드웨어가제한된성능만을가지는경우가많다. 따라서, 픽스맵, 비트맵의출력과같이, 상대적으로단순한작업에텍스처매핑기법을적용하면, 실제로필요한고급기능들에영향을미쳐, 전체성능의급격한저하를가져올수도있다. 비트맵에서는투명한출력이가능해야한다 : 비트맵의비트 0값은투명한픽셀에대응된다. 이것을텍스처매핑에서구현하려면, 대응되는부분의 alpha 값이 0이되는완전히새로운텍스처이미지를실시간으로생성해내거나, 스텐실매스킹과같은고급기능을사용해서처리해야한다. 이러한문제때문에, 텍스처매핑을이용하여간접적으로이미지를출력하는방식은알파-블렌딩 (alpha blending) 이나, 스텐실매스킹과같은좀더고급기법들이함께사용되어야한다. 이렇게되면, 프로그래머는다른특수효과에이들기법들을사용하지못하게되는, 치명적인제약을받게된다. 또한, 원활한처리를위해서, 픽스맵, 비트맵이미지들의크기를 2의승수값이되도록재조정해야한다는제약조건도있다. 이것들을해결하는방법으로, 본논문에서는픽스맵, 비트맵에서출력이필요한픽셀들에대해서만각픽셀에대응하는점 (point) 을출력하는방식을택하였다. 즉, [ 그림 5] 에서와같이, 주어진 2차원이미지를픽셀들의집합으로보고, 대응되는윈도우좌표상에, DrawArrays( ) 와같은 3차원그래픽스출력요소 (3D graphics primitive) 를사용해서, 점집합 (point set) 을출력하게했다. a set of points OpenGL ES 1.1 geometry pipeline Primitive Processing Vertex Buffers Objects Alpha Test Transform and Lighting Texture Environment Depth Stencil Primitive Assembly Color Sum Color Buffer Blend Rasterizer Fog Dither 그림 5. 점집합처리방법 bitmap image 이러한방식의처리에서는어떠한크기를가지는이미지들도처리가가능하고, 더이상알파-브렌딩이나스텐실매스킹등의다른처리기법들이추가로요구되지않는다. 또한, 반대로, 알파-브렌딩이나스텐실매스킹등의고급기법들이지원되지않는, 저수준의그래픽스하드웨어에서도본논문이제안하는방법을그대로사용할수있다. 3차원상의점을출력하는기능만필요하다.
3 차원그래픽스기하파이프라인기반의래스터파이프라인구현 49 본논문이제안하는방법이가지고있는잠재적인문제점은전송해야하는자료의양이늘어날수있다는것이다. 이미지는보통픽셀의색상값들만전송하면되지만, 본논문이제안하는방법에서는점의 3차원좌표와색상값들이모두필요하고, 그래픽카드로전송해야하는자료양이증가한다. 하지만, 비트맵의경우는투명한픽셀들의존재로인해, 실제늘어나는자료양은그렇게많지않다. 이절에서제시한처리과정에대한분석들에기초해서, 다음절에서는구체적인알고리즘들을제시하겠다. 단계2: 점들의집합을출력한다. 모든변환행렬을단위행렬로설정해서, 필요한윈도우좌표가그대로나오게한다. 픽셀좌표 (x, y, z) 를버텍스어레이 (vertex array) 에설정하고, RGBA 형태의색상값들을컬러어레이 (color array) 에설정한후, 출력프리미티브 (output primitive) 로이미지를출력한다. 단계3: 원래의기하파이프라인을복원한다. 저장해놓았던모든상태변수들을복원한다. 좌표변환, 텍스처매핑, 쉐이딩기능등을다시켠다. III. 알고리즘의제시및구현이절에서는래스터파이프라인의구현을위한알고리즘들이설명된다. 설명의편의를위해, 픽스맵처리과정을먼저보이고, 다음으로비트맵처리과정을보이겠다. 1. 픽스맵의처리 RasterPos( ) 함수에서는주어진물체좌표 (object coordinates) 로부터대응되는윈도우좌표 (window coordinate) 를계산해야한다. 본논문에서는 OpenGL 좌표변환파이프라인을소프트웨어로그대로구현해서, 윈도우좌표를정확히계산하도록했다. 다음단계로, DrawPixels( ) 함수는다음단계들을수행한다. 입력 : RasterPos( ) 함수에서미리설정한 current raster location (x, y, z) 입력 : RGBA 또는 RGB 색상값으로저장된픽스맵정보단계1: OpenGL 상태변수들 (state variables) 을저장하고, 기하파이프라인을끈다. 현재의좌표변환설정을나중에그대로복원할수있도록, OpenGL 에서좌표변환파이프라인에관련된모든상태변수들을저장한다. 픽셀에부여되는색상값이그대로저장될수있도록, 텍스처매핑, 쉐이딩기능등을끈다. 2. 비트맵의처리 current raster color를설정하기위해서는 glcolor4f ( ) 등의함수를사용한다. 2절에서설명한바와같이, 필요로하는색상값을얻기위해서는쉐이딩기능전체를거쳐야할수도있다. 우리는 OpenGL의쉐이딩기능전체를에뮬레이트해서정확한계산을하게했다. 비트맵처리알고리즘은다음과같다. 입력 : current raster location (x, y, z) 와색상값 (R, G, B, A) 입력 : 각픽셀마다 0 또는 1이설정된비트맵정보단계1: OpenGL 상태변수들 (state variables) 을저장하고, 기하파이프라인을끈다. 현재의좌표변환설정을나중에그대로복원할수있도록, OpenGL에서좌표변환파이프라인에관련된모든상태변수들을저장한다. 픽셀에부여되는색상값이그대로저장될수있도록, 텍스처매핑, 쉐이딩기능등을끈다. 단계2: 전경색을이용해서점들의집합을출력한다. 투명한픽셀들이나올수있도록, 추가적인작업을해야한다. current raster color를전경색으로설정한다. 비트값이 1인부분은대응되는좌표를제공하고, 0인부분은무시하도록출력함수로주어진비트맵을그린다. 단계3: 원래의기하파이프라인을복원한다. 저장해놓았던모든상태변수들을복원한다. 좌표변환, 텍스처매핑, 쉐이딩기능등을다시켠다.
50 한국콘텐츠학회논문지 '13 Vol. 13 No. 8 단계4: 새로운위치로이동하는추가작업을한다. 이제 current raster position을 (xinc, yinc) 만큼이동시킨다. 될정도의속도저하는보이지않았고, 실시간응용에서사용하기에문제가없었다. 비트맵의처리는주로비트맵폰트의출력을염두에두고설계되었으므로, current raster position을다음폰트출력위치로이동시키도록설정되어있다. 위에서설명한알고리즘들은우리구현의핵심적인역할을담당하였다. 그구현결과는다음절에제시된다. IV. 구현결과본논문에서는 3절에서소개한알고리즘들에기초해서래스터파이프라인기능을구현했다. 우리의구현은이미설명한바와같이, 점들의집합을출력하는방식으로구현되었다. 따라서, 하드웨어래스터파이프라인의지원이전혀필요하지않고, 기하파이프라인의기능만을필요로한다. 실제구현은현재완전소프트웨어방식을택하였다. 설계초기부터기하파이프라인의기능만을사용하도록했으므로, 하드웨어래스터기능이없는, OpenGL ES 하드웨어들에서도아무런문제없이작동가능하다. 현재의구현은정확히는 OpenGL ES 1.1 하드웨어상에서소프트웨어방식만으로도작동가능하다. [ 그림 6] 은본논문에서의구현으로출력한비트맵글자들이다. 여기에나온바와같이, 이제 OpenGL ES 1.1 응용프로그램들에서도비트맵글자와픽스맵방식의이미지들을출력할수있다. 구현의정확성을보이기위해, 본논문에서는크로노스그룹에서제공하는공식 CTS(conformance test suites)[13] 의일부를사용했다. 본논문의구현은이들테스트를모두통과해서, 표준문서에서요구하는대로, 정확히구현되었음을보였다. 수행속도는출력하려는픽스맵, 비트맵의수나내용에따라차이가나지만, [ 그림 6](b) 의예제프로그램을 Freescale i.mx6 그래픽스칩에서테스트한결과로는평규적으로초당 113.47 프레임을기록하는등, 현재까지의실험결과로는문제가 V. 결론 (a) 비트맵폰트의출력 (c) 확대된화면 그림 6. 구현결과 (b) 임베디드보드의실행결과 현재사용하는모바일그래픽스플랫폼들은대부분하드웨어래스터파이프라인을제거했다. 반면에, 비트맵폰트의처리나, 이미지프로세싱응용에서는여전히래스터출력기능을필요로한다. 텍스처매핑을사용해서래스터기능을에뮬레이트할수있다고알려져있지만, 실제로는알파-블렌딩이나스텐실처리와같은, 추가기능이필요하다. 반면에, 어떤응용프로그램들은래스터처리와동시에, 이러한알파-블렌딩이나스텐실처리를함께요구하므로, 문제가될수있다. 이런문제점들을피하기위해, 본논문에서는래스터연산을구현하는새로운방법으로, 점들의집합을출력하는방식을제안했다. 이방식에서는픽스맵이나비트맵이미지마다점들의집합을생성한후, 전통적인 3차원기하파이프라인에서이들점들을처리해서화면에표시하게했다. 즉, 우리의방식에서는픽스맵이나비트
3 차원그래픽스기하파이프라인기반의래스터파이프라인구현 51 맵이미지를색상값을가지는 3차원점들의집합으로해석해서, 최종적으로는화면상에 2차원이미지를출력하게했다. 본논문에서는알고리즘의세부사항들과구현결과를보였다. 현재까지의결과로는 OpenGL ES 하드웨어와같이, 래스터처리기능이전혀없고, 기하파이프라인만제공하는플랫폼에서도, 소프트웨어기능의첨가만으로도요구되는래스터연산들을모두제공한다. 이는래스터연산들을활발히사용하던기존의 OpenGL 기반응용프로그램들이별다른수정없이 OpenGL ES 하드웨어상에서사용가능하다는것을의미한다. 개발비용측면에서는새로운모바일그래픽스응용들에서기존의데스크탑기반소프트웨어들이별다른수정없이그대로사용가능하므로, 소프트웨어개발비용을줄이는효과를가져온다. [8] B. Lipchak, OpenGL ES, Version 3.0.1, 2013(1). [9] M. Kilgard, The OpenGL Utility Toolkit (GLUT) Programming Interface API, Version 3, Silicon Graphics, 1996. [10] T. Olson, OpenGL ES Extension No. 7: OES_draw_texture, Khronos Group, 2004. [11] N. Baek, "Implementation of the raster pipeline over the 3D geometry pipeline: A point-set approach," Proc. ICCE 2013, pp.15-16, 2013. [12] N. Mansfield, The Joy of X: The Architecture of the X Window System, UIT Cambridge Ltd., 2010. [13] http://www.khronos.org/opengles/sc/ 저자소개 참고문헌 [1] E. Angle, Interactive Computer Graphics, A top-down approach with OpenGL, 6th Ed., 2012. [2] 최홍준, 김철홍, 범용응용프로그램실행시하드웨어구성과분기처리기법에따른 GPU 성능분석, 한국콘텐츠학회논문지, 제13권, 제3호, pp.9-21, 2013. [3] 도주영, 백낙훈, OpenGL을이용한 Direct3D 기능의구현, 한국콘텐측학회논문지, 제11권, 제11 호, pp.19-27, 2011. [4] K. Pulli, "New APIs for mobile graphics," Proc. SPIE Multimedia on Mobile Devices II, 2006. [5] D. Blythe, OpenGL ES Common/Common-Lite Profile Specification, Khronos Group, 2007. [6] M. Segal and K. Akeley, The OpenGL Graphics System: A Specification, Version 2.1, Khronos Group, 2006(12). [7] A. Munshi and J. Leech, OpenGL ES Common Profile Specification, Version 2.0.24, Khronos Group, 2009(4). 백낙훈 (Nakhoon Baek) 정회원 1992년 2월 : 한국과학기술원전산학과 ( 공학석사 ) 1997년 2월 : 한국과학기술원전산학과 ( 공학박사 ) 2004년 3월 ~ 현재 : 경북대학교컴퓨터학부교수 < 관심분야 > : 모바일그래픽스, 리얼타임그래픽스