KR101827395B1 - 확장성 있는 gpu기반의 대용량 obj 파일 처리 방법 및 장치 - Google Patents

Abstract

본 명세서에 따른 OBJ 파일 처리 방법은 out-of-core 방식으로 대용량 파일을 일정 단위 크기로 나누고, GPU 병렬 처리를 통해 순차적으로 파싱(parsing)할 수 있다.

Description

확장성 있는 GPU기반의 대용량 OBJ 파일 처리 방법 및 장치 {A SCALABLE METHOD AND APPARATUS FOR PROCESSING MASSIVE OBJ FILE BASED ON GPU}

본 발명은 파일 처리 방법에 관한 것으로서, 구체적으로는 대용량 OBJ 파일을 GPU를 이용하여 효율적으로 처리하는 방법에 관한 것이다.

OBJ 파일의 파싱(parsing) 방법은 CPU 구조에 최적화 되어있으므로, CPU 기반한 처리를 주로 해왔다. 이러한 CPU 기반한 처리는 OBJ 파일 크기가 증가할수록, 연산량이 선형적으로 증가하므로 대용량 크기의 경우 로딩은 많은 시간을 소비한다. 하드웨어의 성능이 개선되면서 앞서 언급한 한계를 극복 하고자 병렬처리를 통한 자체적인 최적화에 대한 시도가 있었다. 멀티 코어 CPU 기반의 XML parsing 연구는 기존의 단일 코어 CPU 기반에 비해 성능의 향상이 있었다. 어느 정도의 성능 향상이 있었지만, 대규모 크기의 OBJ 파일 처리에는 어려움이 있었다.

한편, GPU는 다수의 코어를 지원하므로 병렬 처리에 최적화된 성능을 가지고 있으며, 대용량 데이터의 처리에 적합하다. 이에 따라 GPU에 기반한 파일 로더(loader)가 등장하여 기존 CPU에 비해 월등히 가속화 되었지만, 여전히 대용량 OBJ 파일의 경우 GPU의 메모리 부족 문제로 어려움이 있었다.

따라서 대용량 OBJ 파일을 처리하기 위해 GPU 메모리에 파일을 로딩함에 있어서 보다 효율적으로 방법이 필요하다.

대한민국 등록특허공보 제10-1415200호

본 명세서는 대용량 OBJ 파일을 GPU를 통해 효율적으로 처리할 수 있는 방법을 제시하고 한다.

본 명세서에 기재된 해결과제는 이상에서 언급한 것들에 한정되지 않으며, 언급되지 아니한 다른 해결과제들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

상술한 과제를 해결하기 위한 본 명세서에 따른 OBJ 파일 처리 방법은, (a) CPU가 OBJ 파일을 미리 설정된 크기의 청크(chunk)로 나누고, 상기 청크들을 순차적으로 GPU의 전역 메모리에 로딩하는 단계; (b) 상기 GPU가 상기 전역 메모리에 로딩된 청크를 순차적으로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성하고, 메인 메모리로 순차적으로 다운로드하는 단계; (c) 상기 CPU가 상기 메인 메모리에 저장된 f 어레이를 미리 설정된 크기의 f 청크로 나누어서 순차적으로 상기 GPU의 상기 전역 메모리에 로딩하는 단계; (d) 상기 GPU가 상기 전역 메모리에 순차적 로딩된 f 청크를 이용하여 인덱스 버퍼를 생성하는 단계; 및 (e) 상기 GPU가 상기 인덱스 버퍼를 이용하여 버텍스 버퍼를 생성하는 단계;를 포함할 수 있다.

본 명세서의 일 실시예에 따르면, 상기 (b) 단계는, (b-1) 상기 GPU가 청크 내 태그를 찾고, 그 위치를 상기 전역 메모리에 저장하는 단계; (b-2) 상기 GPU가 각 태그의 라인 길이를 계산하고, 이를 상기 전역 메모리에 저장하는 단계; (b-3) 상기 GPU가 각 태그의 종류별 개수를 세고, 이를 상기 전역 메모리에 저장하는 단계; 및 (b-4) 상기 GPU가 각 태그 별로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성하는 단계;를 포함할 수 있다.

본 명세서의 일 실시예에 따르면, 상기 (b-1) 단계는, 상기 GPU가 태그에 해당하지 않는 위치 정보는 제외하여, 태그에 해당하는 위치 정보만으로 압축하여 저장할 수 있다.

본 명세서의 일 실시예에 따르면, 상기 (b-3) 단계는, 상기 GPU가 원자적 덧셈 연산을 통해 각 태그의 종류별 개수를 셀 수 있다.

본 명세서의 일 실시예에 따르면, 상기 (d) 단계는, (d-1) 상기 GPU가 상기 전역 메모리에 순차적 로딩된 f 청크를 태그 v를 기준으로 정렬하는 단계; (d-2) 상기 GPU가 태그 v가 같은 데이터가 시작되는 지점에 스레드를 할당하는 단계; 및 (d-3) 상기 GPU가 태그 v를 기준으로 인덱스 테이블을 작성하는 단계;를 포함할 수 있다.

본 명세서의 일 실시예에 따르면, (d-4) 상기 GPU가 모든 f 청크에 대해서 (d-1) 내지 (d-3)를 실행하여 작성된 상기 인덱스 테이블을 이용하여 지표(indices)를 생성하는 단계;를 더 포함할 수 있다.

본 명세서에 따른 OBJ 파일 처리 방법은 각 단계들이 수행하도록 작성되어 컴퓨터로 독출 가능한 기록 매체에 기록된 컴퓨터프로그램을 형태를 가질 수 있다.

상술한 과제를 해결하기 위한 본 명세서에 따른 컴퓨터 시스템은 CPU, 메인 메모리, GPU, 전역 메모리를 포함하여 OBJ 파일 처리하는 컴퓨터 시스템으로서, 상기 CPU는, OBJ 파일을 미리 설정된 크기의 청크(chunk)로 나누고, 상기 청크들을 순차적으로 상기 GPU의 상기 전역 메모리에 로딩하고, 상기 메인 메모리에 저장된 f 어레이를 미리 설정된 크기의 f 청크로 나누어서 순차적으로 상기 GPU의 상기 전역 메모리에 로딩하며, 상기 GPU는, 상기 전역 메모리에 로딩된 청크를 순차적으로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성하고, 상기 메인 메모리로 순차적으로 다운로드하고, 상기 전역 메모리에 순차적 로딩된 f 청크를 이용하여 인덱스 테이블을 생성 후 인덱스 버퍼를 생성하며, 상기 인덱스 버퍼를 이용하여 버텍스 버퍼를 생성할 수 있다.

본 명세서에 따른 OBJ 파일 처리 방법은 대용량 OBJ 파일의 처리 속도를 상당히 향상시킬 수 있다.

본 명세서에 기재된 효과는 이상에서 언급된 것들에 한정되지 않으며, 언급되지 아니한 다른 효과들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

도 1은 OBJ 청크 내 태그의 위치를 찾는 개념도이다.
도 2는 태그의 라인 길이를 계산하는 개념도이다.
도 3은 각 태그의 개수를 세는 개념도이다.
도 4는 각 태그 별로 파싱하는 개념도이다.
도 5는 인덱스 테이블을 바탕으로 인덱스 버퍼를 생성하는 과정을 도시한 개념도이다.
도 6은 인덱스 테이블을 이용하여 버텍스 버퍼를 생성하는 과정을 도시한 개념도이다.

이하, 첨부한 도면을 참조하여, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 본 발명의 실시예를 설명한다. 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 용이하게 이해할 수 있는 바와 같이, 후술하는 실시예는 본 발명의 개념과 범위를 벗어나지 않는 한도 내에서 다양한 형태로 변형될 수 있다. 가능한 한 동일하거나 유사한 부분은 도면에서 동일한 도면부호를 사용하여 나타낸다.

본 명세서에서 사용되는 전문용어는 단지 특정 실시예를 언급하기 위한 것이며, 본 발명을 한정하는 것을 의도하지는 않는다. 여기서 사용되는 단수 형태들은 문구들이 이와 명백히 반대의 의미를 나타내지 않는 한 복수 형태들도 포함한다.

본 명세서에서 사용되는 "포함하는"의 의미는 특정 특성, 영역, 정수, 단계, 동작, 요소 및/또는 성분을 구체화하며, 다른 특정 특성, 영역, 정수, 단계, 동작, 요소, 성분 및/또는 군의 존재나 부가를 제외시키는 것은 아니다.

본 명세서에서 사용되는 기술용어 및 과학용어를 포함하는 모든 용어들은 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 일반적으로 이해하는 의미와 동일한 의미를 가진다. 사전에 정의된 용어들은 관련기술문헌과 현재 개시된 내용에 부합하는 의미를 가지는 것으로 추가 해석되고, 정의되지 않는 한 이상적이거나 매우 공식적인 의미로 해석되지 않는다.

본 명세서에 따른 OBJ 파일은 렌더링 분야에 사용되는 파일을 의미한다.

본 명세서에 따른 OBJ 파일 처리 방법은 out-of-core 방식으로 대용량 파일을 일정 단위 크기로 나누고, GPU(Graphics Processing Unit) 병렬 처리를 통해 순차적으로 파싱(parsing)할 수 있다. 본 명세서에서 파싱이란 문자열 타입의 OBJ 파일을 integer 혹은 float 타입의 데이터로 변환하는 것을 의미한다. 본 명세서에 따른 OBJ 파일 처리 방법은 크게 두 부분으로 나누어진다. OBJ 파일을 문자열 타입에서 데이터 타입으로 파싱(parsing) 부분과 파싱한 데이터에서 버텍스 버퍼(vertex buffer)와 인덱스 버퍼(index buffer)를 생성하는 부분이다.

종래 OBJ 파일의 처리 방법은 CPU(Central Processing Unit, 중앙 처리 장치) 기반한 처리 방법이며, OBJ 파일 크기가 증가할수록 연산량이 선형적으로 증가하므로 OBJ 파일의 로딩은 많은 시간을 소비한다. GPU가 병렬처리 통하여 대용량 데이터에 대해 최적화된 성능을 지원하여도, 과도한 크기의 데이터가 GPU 메모리에 로딩되었을 때 오히려 GPU에 부담을 주며 성능을 하락시키는 원인이된다. 따라서 본 명세서에 따른 OBJ 파일 처리 방법은 OBJ 파일을 일정 단위로 나누어 GPU에 로딩하여 연산 부하를 줄일 수 있어, 대용량의 파일도 처리가 가능하다.

한편, 이하에서 상세히 설명될 본 명세서에 따른 OBJ 파일 처리 방법은 컴퓨터 프로그램 형태로 구현될 수 있다. 상기 컴퓨터 프로그램은 본 발명이 속한 기술분야에 알려진 프로세서, ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로, 레지스터, 통신 모뎀, 데이터 처리 장치 등이 독출할 있는 메모리 장치에 저장될 수 있으며, 상기 프로세서 등이 상기 메모리에 저장된 프로그램을 독출하여 본 명세서에 따른 메모리 로딩 방법을 실행할 수 있다. 이 경우, 상기 프로세서 등은 본 명세서에 따른 메모리 로딩 장치가 될 수 있음은 자명하다.

이하 도면을 참조하여 본 명세서에 따른 OBJ 파일 처리 방법을 설명하도록 하겠다.

먼저, CPU가 OBJ 파일을 미리 설정된 크기의 청크(chunk)로 나누고, 상기 청크들을 순차적으로 GPU의 전역 메모리(Global Memory)에 로딩할 수 있다.

상기 '청크(chunk)'란 OBJ 파일을 임의의 크기로 나누었을 때, 임의의 크기만큼 읽어드린 문자열을 의미한다. 상기 청크의 크기는 GPU의 전역 메모리의 크기에 따라 다양하게 설정될 수 있다. 본 명세서의 출원 당시 상용 판매 중인 NVIDIA GPU 980 Ti 기준 상기 청크의 크기는 64MB일때 최대 성능을 가진다.

다음으로, 상기 GPU는 상기 전역 메모리에 로딩된 청크를 순차적으로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성할 수 있다.

먼저, 상기 GPU는 각 청크 내 태그(v, vt, vn 및 f) 위치를 찾을 수 있다.

도 1은 OBJ 청크 내 태그의 위치를 찾는 개념도이다.

도 1을 참조하면, 하나의 청크 내에서 태그(v, vt, vn, f)를 병렬적으로 찾는 과정을 확인할 수 있다. 각 청크 내의 모든 태그(v, vt, vn, f)들의 위치(index) 정보를 알아야 다음 과정에서 이 위치(index)를 통해 각 태그에 접근이 가능하기 때문에 위치를 찾을 필요가 있다.

도 1의 (a)를 보면, 각 스레드(thread)가 문자 하나하나에 할당된 것을 확인할 수 있다. 각 스레드들은 자신에게 할당된 문자가 v 혹은 f 로 시작하는 지를 판단하여, 태그로 판단되면 위치를 별도의 전역 메모리에 저장할 수 있다. 이 때 각각의 스레드들은 동시다발적으로 진행되고, 그 순서를 제어할 수 없다. 그렇지만 스레드ID를 이용하면(파란색 블록) 동시 다발적으로 진행되어도, 순차적으로는 저장할 수 있다.

한편, 도 1의 (a)를 거치면, 도 1의 (b) 왼쪽에 도시된 것과 같이 결과물(output)이 생성된다. 그런데 도 1의 (b) 왼쪽에 보이는 대로, 위치(index) 데이터 분포가 드문드문(sparse)하기 때문에, 이를 압축(packing)하는 과정이 필요하다.

도 1의 (b) 오른쪽에 도시된 것과 같이, 위치 정보를 압축할 수 있다. 이때 태그에 해당하지 않는 위치 정보는 제외하여, 태그에 해당하는 위치 정보만으로 압축하여 저장한다. 즉, 도 1의 (b)에서 '3, 9, 22 ...' 가 최종적인 결과물(output)이다. 이 과정을 통해 전역 메모리의 낭비를 방지할 수 있다.

다음으로, 상기 GPU는 각 태그의 라인 길이를 계산하고 이를 전역 메모리에 저장할 수 있다.

도 2는 태그의 라인 길이를 계산하는 개념도이다.

도 2를 참조하면, GUP는 상기 위치 정보의 개수만큼 스레드의 수를 할당하고 할당된 각 스레드는 캐리지 리턴(carriage return)을 만날 때까지 병렬적으로 센 후, 이 값을 전역 메모리에 저장할 수 있다. 각 태그 별로 위치 정보는 알지만, 어디까지 처리해야하는 지에 대한 정보가 없기 때문에, 각 태그의 라인 길이를 미리 계산하면, 태그의 위치와 태그 길이를 모두 알고 있으므로, 각 스레드는 병렬로 처리가 가능하다.

다음으로, 상기 GPU는 각 태그의 종류별 개수를 세고 이를 전역 메모리에 저장할 수 있다.

도 3은 각 태그의 개수를 세는 개념도이다.

도 3을 참조하면, 한 청크내 각 태그별로 개수가 파악 태그(v=33, vt=32, vn=20, f=35)되어 이에 대한 정보가 전역 메모리에 저장된 예시를 확인할 수 있다. 각 태그(v, vt, vn, f)의 수 정보가 필요한 이유는 사용자에게 모델에 대한 정보 제시 혹은 메모리 할당을 위해서 정보가 필요하므로 OBJ 파일내의 태그 정보의 각 개수를 파악하는 것이 필요하다. 이를 위해, 위치 정보에 스레드를 할당하고, 원자적 덧셈 연산(atomic Add)으로 개수를 셀 수 있다. 각 스레드는 태그의 종류(v, vt, vn, f)를 파악하고 카운트(count)를 담당하는 변수에 1을 더하는 식으로 처리할 수 있다. 원자적 덧셈 연산(atomic Add)를 하는 이유는 스레드간의 동시적으로 쓰기(write)를 하는 것은 기본적으로 문제가 발생한다. 예를 들어, 어느 한 스레드가 데이터를 쓰고 있는 시점에 다른 스레드가 접근을 해서 써버리면 이상한 값이 발생되는 등의 문제가 발생한다. 그러므로 스레드가 쓰기(write)를 하는 동안에 다른 스레드가 접근하지 못하는 기능을 지원하는 'atomic 함수'를 사용하고 그 중에서 덧셈을 하는 'atomic Add'를 사용할 수 있다.

다음으로, 상기 GPU는 각 태그 별로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성할 수 있다.

도 4는 각 태그 별로 파싱하는 개념도이다.

도 4를 참조하면, 각 태그 별로 파싱되어 생성된 v 어레이(array), vt 어레이(array), vn 어레이(array) 및 f 어레이(array)를 확인할 수 있다. 좀 더 자세하게는, 각 태그 별로 스레드를 할당하고, 각 파싱이 끝나는 지점까지 이동하면서 문자 정보를 숫자 정보로 변환한다. 문자에서 숫자 변환은 아스키 코드(ascii code)값을 이용하여, 문자 정보에서 '48'만큼 빼서 숫자 정보로 변환할 수 있다.

다음으로, 상기 GPU는 상기 v, vt, vn 및 f 어레이를 메인 메모리로 순차적으로 다운로드할 수 있다. 하나의 청크에 대해서 태그 별로 파싱이 완료되면 전역 메모리에는 파싱된 v, vt, vn, f 어레이가 있다. GPU의 전역 메모리는 일반적으로 CPU의 메인 메모리보다 저장 용량이 적기 때문에(예: Intel Core i7-4790 CPU 기준 메인 메모리는 '16GB' / NVIDIA GPU 980 Ti 기준 GPU의 전역 메모리는 '6GB') 다음 차례의 청크를 처리하기 위해서는 GPU에 처리된 데이터를 메인 메모리에 다운로드 해야 한다. 도 4의 우측에 도시된 내용이 이에 대한 개념도이다.

상기 GPU는 도 1 내지 도 4에 도시된 과정을 모든 청크가 파싱 완료될 때까지 반복한다. 따라서 모든 청크에 대한 파싱이 끝나면, 태그 별로 파싱된 정보가 메인 메모리에 저장된다.

다음으로, 모든 청크에 대한 파싱이 완료되었으므로, 로딩을 위해서 버텍스 버퍼(vertex buffer)와 인덱스 버퍼(index buffer)를 생성하는 것이 필요하다. 상기 메인 메모리에 저당된 v, vt, vn, f 어레이로부터 버텍스 버퍼(vertex buffer)와 인덱스 버퍼(index buffer)를 생성하는 과정은 다음과 같다.

대용량의 크기의 OBJ 파일일수록 삼각형의 개수도 비례하여 증가하며 f 태그의 개수는 비례하여 증가함은 자명하다. 그러므로 f 어레이 전부를 GPU의 전역 메모리에 로딩하여 처리할 경우, GPU에 부하가 많이 발생한다. 따라서 본 명세서에 따른 CPU는 상기 메인 메모리에 저장된 f 어레이를 미리 설정된 크기의 f 청크로 나누어서 순차적으로 상기 GPU의 전역 메모리에 로딩할 수 있다. 상기 f 청크의 크기는 GPU의 전역 메모리의 크기에 따라 다양하게 설정될 수 있다. 본 명세서 출원 당시 상용 판매 중인 NVIDIA GPU 980 Ti 기준 상기 청크의 크기는 256KB 일 때 최대 성능을 가진다.

한편, 본 명세서에 따른 OBJ 파일 처리 방법은, 종래 기술과 달리, 버택스 버퍼(vertex buffer)를 먼저 생성하는 것이 아닌, 인덱스 버퍼(index buffer)를 먼저 생성한다. 상기 f 어레이에 의해 인덱싱(indexing)된 버택스(vertex)보다 f의 메모리 사이즈가 더 적기 때문에, 연산 비용이 상대적으로 적고 인덱스 버퍼(index buffer)를 먼저 생성하면 중복된 버텍스(vertex) 정보가 제거되므로, f를 이용하여 인덱스 버퍼(index buffer)를 먼저 생성할 수 있다.

도 5는 인덱스 버퍼를 생성하는 과정을 도시한 개념도이다.

도 5를 참조하면, 먼저 상기 GPU는 상기 전역 메모리에 순차적 로딩된 f 청크를 태그 v를 기준으로 정렬할 수 있다. 그 결과, 태그 v가 같은 데이터끼리 모여있는다.

다음으로, 상기 GPU는 태그 v가 같은 데이터가 시작되는 지점에 스레드를 할당할 수 있다. 이 과정은 인덱스 테이블(index table)을 만들기 위한 사전 작업으로서, 태그 v를 키(key)로 간주하고 병렬로 인덱스 테이블(index table)에 저장하기 때문에, 정렬을 하지 않으면, 쓰기 충돌(write conflict) 문제가 발생할 수 있다. 그리고 같은 태그 v를 가진 클러스터(cluster)가 시작되는 지점(v가 1, 2, 3 시작되는 지점)에 스레드를 할당해야 병렬로 처리가 가능하다. 구체적으로, GPU는 전역 메모리에 같은 태그 v를 가진 클러스터(cluster)가 시작되는 곳에 1을 저장하고, f의 수만큼 스레드를 할당하고 상기 '1'이 마킹(marking)된 스레드만 작업을 하도록 하면 클러스터(cluster)시작되는 지점에 접근이 가능하다.

다음으로, 상기 GPU는 태그 v를 기준으로 인덱스 테이블을 작성할 수 있다. 구체적으로, 각 스레드는 태그 v를 키(key)로 보고 해당위치에 vt/vn을 저장할 수 있다(도면 5 참조). 그리고 각 스레드는 저장 시에 버택스(vertex)가 인덱스 (index table)에 해당 값이 있는지를 확인하고, 이미 존재할 경우 그 값은 인덱스 테이블에 입력하지 않는다.

상기 도 5에 도시된 과정은 모든 f 청크가 처리될 때까지 반복한다. 따라서 f 청크가 처리 될 때마다 인덱스 테이블 내의 f 정보는 누적된다. 모든 f의 버텍스(vertex)에 대해서 인덱스 테이블에 등록하면, 인덱스 테이블에는 중복된 데이터는 전부 제거가 되기 때문에 그 크기는 매우 작아진다. 그리고 상기 GPU는 상기 인덱스 테이블을 참조하여 지표(indices)를 생성할 수 있다. 이 경우, 지표(indices)를 생성하는 작업도 f 청크를 나누어서 처리할 수 있다. 상기 CPU는 f 청크를 다시 GPU의 전역 메모리에 로딩하고, 상기 GPU는 미리 생성된 인덱스 테이블(index table)을 참조하여 지표(indices)를 분할하여 생성할 수 있다. 상기 과정을 모든 f 청크에 대해여 진행하면 지표 버퍼(indices buffer) 생성이 가능하다.

마지막으로 상기 GPU는 상기 인덱스 테이블을 이용하여 버텍스 버퍼를 생성할 수 있다.

도 6은 인덱스 버퍼를 이용하여 버텍스 버퍼를 생성하는 과정을 도시한 개념도이다.

도 6을 참조하면, 인덱스 버퍼를 통해 버텍스 버퍼가 생성된 것을 확인할 수 있다. 본 명세서에 따른 OBJ 파일 처리 방법은 중복된 버택스(vertex) 정보가 확연하게 줄어들었기 때문에, GPU가 전역 메모리에서 인메모리(in memory)방식으로 한번에 처리할 수 있다.

본 명세서에서 설명되는 실시예와 첨부된 도면은 본 발명에 포함되는 기술적 사상의 일부를 예시적으로 설명하는 것에 불과하다. 따라서, 본 명세서에 개시된 실시예들은 본 발명의 기술적 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이므로, 이러한 실시예에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아님은 자명하다. 본 발명의 명세서 및 도면에 포함된 기술적 사상의 범위 내에서 당업자가 용이하게 유추할 수 있는 변형 예와 구체적인 실시 예는 모두 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (13)

1. (a) CPU가 OBJ 파일을 미리 설정된 크기의 청크(chunk)로 나누고, 상기 청크들을 순차적으로 GPU의 전역 메모리에 로딩하는 단계;
   (b) 상기 GPU가 상기 전역 메모리에 로딩된 청크를 순차적으로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성하고, 메인 메모리로 순차적으로 다운로드하는 단계;
   (c) 상기 CPU가 상기 메인 메모리에 저장된 f 어레이를 미리 설정된 크기의 f 청크로 나누어서 순차적으로 상기 GPU의 전역 메모리에 로딩하는 단계;
   (d) 상기 GPU가 상기 전역 메모리에 순차적 로딩된 f 청크를 이용하여 인덱스 버퍼를 생성하는 단계; 및
   (e) 상기 GPU가 상기 인덱스 버퍼를 이용하여 버텍스 버퍼를 생성하는 단계;를 포함하는 것을 특징으로 하는 OBJ 파일 처리 방법.
2. 청구항 1에 있어서,
   상기 (b) 단계는,
   (b-1) 상기 GPU가 청크 내 태그를 찾고, 그 위치를 상기 전역 메모리에 저장하는 단계;
   (b-2) 상기 GPU가 각 태그의 라인 길이를 계산하고, 이를 상기 전역 메모리에 저장하는 단계;
   (b-3) 상기 GPU가 각 태그의 종류별 개수를 세고, 이를 상기 전역 메모리에 저장하는 단계; 및
   (b-4) 상기 GPU가 각 태그 별로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성하는 단계;를 포함하는 것을 특징으로 하는 OBJ 파일 처리 방법.
3. 청구항 2에 있어서,
   상기 (b-1) 단계는, 상기 GPU가 태그에 해당하지 않는 위치 정보는 제외하여, 태그에 해당하는 위치 정보만으로 압축하여 저장하는 것을 특징으로 하는 OBJ 파일 처리 방법.
4. 청구항 2에 있어서,
   상기 (b-3) 단계는, 상기 GPU가 원자적 덧셈 연산을 통해 각 태그의 종류별 개수를 세는 것을 특징으로 하는 OBJ 파일 처리 방법.
5. 청구항 1에 있어서,
   상기 (d) 단계는,
   (d-1) 상기 GPU가 상기 전역 메모리에 순차적 로딩된 f 청크를 태그 v를 기준으로 정렬하는 단계;
   (d-2) 상기 GPU가 태그 v가 같은 데이터가 시작되는 지점에 스레드를 할당하는 단계; 및
   (d-3) 상기 GPU가 태그 v를 기준으로 인덱스 테이블을 작성하는 단계;를 포함하는 것을 특징으로 하는 OBJ 파일 처리 방법.
6. 청구항 5에 있어서,
   (d-4) 상기 GPU가 모든 f 청크에 대해서 (d-1) 내지 (d-3)를 실행하여 작성된 상기 인덱스 테이블을 이용하여 지표를 생성하는 단계;를 더 포함하는 것을 특징으로 하는 OBJ 파일 처리 방법.
7. 컴퓨터에서 청구항 1 내지 청구항 6 중 어느 한 청구항에 따른 OBJ 파일 처리 방법의 각 단계들을 수행하도록 작성되어 컴퓨터로 독출 가능한 기록 매체에 기록된 컴퓨터프로그램.
8. CPU, 메인 메모리, GPU, 전역 메모리를 포함하여 OBJ 파일 처리하는 컴퓨터 시스템에 있어서,
   상기 CPU는, OBJ 파일을 미리 설정된 크기의 청크(chunk)로 나누고, 상기 청크들을 순차적으로 상기 GPU의 상기 전역 메모리에 로딩하고, 상기 메인 메모리에 저장된 f 어레이를 미리 설정된 크기의 f 청크로 나누어서 순차적으로 상기 GPU의 상기 전역 메모리에 로딩하며,
   상기 GPU는, 상기 전역 메모리에 로딩된 청크를 순차적으로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성하고, 상기 메인 메모리로 순차적으로 다운로드하고, 상기 전역 메모리에 순차적 로딩된 f 청크를 이용하여 인덱스 버퍼를 생성하며, 상기 인덱스 버퍼를 이용하여 버텍스 버퍼를 생성하는 것을 특징으로 하는 컴퓨터 시스템.
9. 청구항 8에 있어서,
   상기 GPU는 상기 전역 메모리에 로딩된 청크를 순차적으로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성함에 있어서,
   청크 내 태그를 찾고, 그 위치를 상기 전역 메모리에 저장하고, 각 태그의 라인 길이를 계산하고, 이를 상기 전역 메모리에 저장하고, 각 태그의 종류별 개수를 세고, 이를 상기 전역 메모리에 저장하며, 각 태그 별로 파싱하여 v, vt, vn 및 f 어레이를 각각 생성하는 것을 특징으로 하는 컴퓨터 시스템.
10. 청구항 9에 있어서,
    상기 GPU는, 청크 내 태그를 찾고, 그 위치를 상기 전역 메모리에 저장함에 있어서,
    태그에 해당하지 않는 위치 정보는 제외하여, 태그에 해당하는 위치 정보만으로 압축하여 저장하는 것을 특징으로 하는 컴퓨터 시스템.
11. 청구항 9에 있어서,
    상기 GPU는, 상기 GPU가 각 태그의 종류별 개수를 세고, 이를 상기 전역 메모리에 저장함에 있어서,
    원자적 덧셈 연산을 통해 각 태그의 종류별 개수를 세는 것을 특징으로 하는 컴퓨터 시스템.
12. 청구항 9에 있어서,
    상기 GPU는, 상기 GPU가 상기 전역 메모리에 순차적 로딩된 f 청크를 이용하여 상기 인덱스 버퍼를 생성함에 있어서,
    상기 전역 메모리에 순차적 로딩된 f 청크를 태그 v를 기준으로 정렬하고, 태그 v가 같은 데이터가 시작되는 지점에 스레드를 할당하며, 태그 v를 기준으로 인덱스 테이블을 작성하는 것을 특징으로 하는 컴퓨터 시스템.
13. 청구항 12에 있어서,
    상기 GPU는, 상기 인덱스 테이블을 이용하여 지표를 더 생성하는 것을 특징으로 하는 컴퓨터 시스템.

Images