KR20130087257A - Ｇｐｕ의 자원 할당을 위한 방법 및 장치 - Google Patents

Abstract

본 발명은 GPU의 자원을 효율적으로 할당하기 위한 방법 및 장치에 대한 것으로, 자원할당 방법은 적어도 하나 이상의 오퍼레이션을 포함하는 테스크(Task)를 수신하고, 상기 오퍼레이션 각각을 리퀘스트 단위로 구분하여 저장하는 단계; 둘 이상의 동일한 오퍼레이션을 하나의 리퀘스트 단위로 설정하기 위하여 머징(Merging)하는 단계; 및 상기 리퀘스트의 실행순서에 따라 상기 GPU의 자원을 할당하는 단계를 포함하는 것을 특징으로 한다.
본 발명에 따르면, 오퍼레이션 레벨에서 GPU 자원을 효율적으로 할당할 수 있는 효과가 있다.

Description

ＧＰＵ의 자원 할당을 위한 방법 및 장치{METHOD AND APPARATUS FOR RESOURCE ALLOCATION OF GPU}

본 발명은 GPU의 자원할당을 위한 방법 및 장치에 관한 것이다.

보다 구체적으로, 본 발명은 GPGPU(General Purpose GPU) 를 이용하는 테스크(task)를 오퍼레이션(operation) 단위로 구분하고, 동일한 오퍼레이션을 합쳐서 하나의 리퀘스트(request)로 설정하여 GPU(Graphic Processing Unit)의 자원을 효율적으로 활용하는 방법 및 장치에 관한 것이다.

본 발명은 GPU의 자원할당을 위한 방법 및 장치에 관한 것이다.

보다 구체적으로, 본 발명은 GPGPU(General Purpose GPU) 를 이용하는 테스크(task)를 오퍼레이션(operation) 단위로 구분하고, 동일한 오퍼레이션을 합쳐서 하나의 리퀘스트(request)로 설정하여 GPU(Graphic Processing Unit)의 자원을 효율적으로 활용하는 방법 및 장치에 관한 것이다.

본 발명은 상기와 같은 문제점을 해결하기 위한 것이다. 특히 본 발명은 오퍼레이션 레벨에서 GPU 자원을 효율적으로 할당할 수 있는 방법 및 장치를 제공하는 것을 목적으로 한다.

나아가 본 발명은 GPU의 파이프라인 효율을 높일 수 있는 방법 및 장치를 제공하는 것을 목적으로 한다.

상기와 같은 문제점을 해결하기 위한 GPU 자원할당 방법은 적어도 하나 이상의 오퍼레이션을 포함하는 테스크(Task)를 수신하고, 상기 오퍼레이션을 리퀘스트 단위로 저장하는 저장 단계, 둘 이상의 동일한 오퍼레이션을 합쳐서 하나의 리퀘스트 단위로 설정하는 머징(Merging) 단계 및 상기 리퀘스트의 실행순서에 따라 상기 GPU의 자원을 할당하는 단계를 포함하는 것을 특징으로 한다.

그리고 본 발명의 GPU 자원할당 장치는 리퀘스트를 저장하는 메모리 및 적어도 하나 이상의 오퍼레이션을 포함하는 테스크(Task)를 수신하고, 상기 오퍼레이션을 리퀘스트 단위로 저장하도록 제어하고, 동일한 오퍼레이션의 데이터를 합쳐서 하나의 리퀘스트 단위로 설정하며, 상기 리퀘스트의 실행순서에 따라 상기 GPU의 자원을 할당하는 제어부를 포함하는 것을 특징으로 한다.

본 발명에 따르면, GPU의 코어 활용의 효율성을 높임으로서 GPU의 리퀘스트 처리 횟수를 줄일 수 있다.

나아가 GPU 파이프라인의 효율성을 높임으로서 시스템의 반응시간을 줄일 수 있다.

도 1은 종래에 GPU를 이용하여 리퀘스트를 처리하는 구조를 도시하는 도면.
도 2는 본 발명의 실시예에 따른 자원 할당 장치(200)의 구조를 도시하는 블록도.
도 3은 본 발명의 실시예에 따라 자원을 할당하는 과정을 도시하는 순서도.
도 4a는 오퍼레이션의 실행순서에 의해 발생하는 데이터 종속성의 예시를 도시하는 도면.
도 4b는 오퍼레이션의 특성에 의해 발생하는 데이터 종속성의 예시를 도시하는 도면.
도 5a는 도 3의 단계 350의 실시예를 구체적으로 도시하는 도면.
도 5b는 도 5a에 따라 리퀘스트를 처리하는 최적화된 구조를 도시하는 도면.
도 6는 도 3의 단계 350의 또다른 실시예를 구체적으로 도시하는 도면.
도 7은 본 발명의 실시예에 따라 리퀘스트 최적화 작업을 구현한 윈도우 매커니즘의 예시를 도시하는 도면.
도 8은 본 발명의 실시예에 따른 자원 할당 장치(200)의 개략적인 구조를도시하는 도면.

본 발명은 이하에 기재되는 실시예들의 설명 내용에 한정되는 것은 아니며, 본 발명의 기술적 요지를 벗어나지 않는 범위 내에서 다양한 변형이 가해질 수 있음은 자명하다. 그리고 실시예를 설명함에 있어서 본 발명이 속하는 기술 분야에 널리 알려져 있고 본 발명의 기술적 요지와 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다.

한편, 첨부된 도면에서 동일한 구성요소는 동일한 부호로 표현된다. 그리고 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시될 수도 있다. 이는 본 발명의 요지와 관련이 없는 불필요한 설명을 생략함으로써 본 발명의 요지를 명확히 설명하기 위함이다. 이하 첨부된 도면을 참조하여 본 발명의 바람직한 실시 예들을 상세히 설명한다.

도 1은 종래에 GPU를 이용하여 리퀘스트를 처리하는 프로그래밍 모델의 구조를 도시하는 도면이다. 도 1은 프로그램 사이즈가 다르나, 동일한 오퍼레이션을 수행하는 3가지 경우의 GPGPU 리퀘스트에 대한 GPU 코어 utilization을 도시한다.

도 1에서 Case A, B, C는 각각 데이터의 개수가 40, 20, 30개인 동일한 오퍼레이션 리퀘스트가 발생한 상황이다. 도 1의 블록 101은 오퍼레이션을 수행하는 코어, 블록 102는 오퍼레이션을 수행하지 않는 코어를 표시한다. 그런데 GPU 코어의 개수가 100개 이므로, 각 오퍼레이션의 수행에 있어서 GPU 코어 utilization rate는 40%, 20%, 30%에 불과하다.

동일한 오퍼레이션을 수행하므로 core에는 동일한 program이 loading되어있는 상황이다. 또한 데이터의 개수가 40, 20, 30개이므로 모두 합쳐도 90개로 GPU core의 개수인 100개가 되지 않는다. 그런데도 Case A, B, C는 각각 별도의 수행시간을 가지게 되고 GPU는 3번의 수행을 해야만 한다. 이는 GPU에 오퍼레이션 request를 할 때 테스크 단위로만 그 요청이 발생하기 때문에 현재 상황에서는 피할 수 없는 문제이다.

기존의 GPGPU programming model의 경우 테스크에서 발생하는 데이터 processing request를 처리함에 있어 테스크 단위로 request에 대한 처리가 발생한다. 따라서 오퍼레이션과 같이 테스크 level보다 작은 단위의 최적화가 불가능한 구조이다.

한편, GPU는 pipeline 방식으로 동작하므로 동일한 오퍼레이션을 연속하여 수행할 수 있다면, GPU의 core에서 수행되는 program이 고정되므로 pipeline의 효율이 높아질 수 있다. 하지만 기존 GPGPU programming model에서는 테스크 단위로 request를 처리하므로 동일한 오퍼레이션의 연속 수행 역시 불가능한 구조이다.

도 2는 본 발명의 실시예에 따른 자원 할당 장치(200)의 구조를 도시하는 블록도이다.

도 2에서 도시되는 바와 같이 본 발명의 자원 할당 장치(200)는 GPU자원 할당자, 즉 제어부(220) 및 메모리(230)를 포함할 수 있다. 본 명세서에는 CPU(210)와 자원할당장치(200)를 별도의 블록으로 표현하였지만, 반드시 이에 한정되는 것은 아니다. 자원할당장치(200)는 시스템에 따라 CPU(210) 또는 GPU(240)에서 구동될 수 있다.

CPU(210)는 GPGPU를 이용하여 생성된 테스크 정보를 자원 할당 장치(200)에 전달한다. 이를 수신한 자원 할당 장치(200)는 테스크를 오퍼레이션 단위로 구분하여, GPU자원을 할당할 순서를 생성한다. 그리고 GPU(240)는 자원 할당 장치(200)로부터 결과를 수신하여, 실행 순서에 따라 리퀘스트를 처리(실행)한다.

보다 구체적으로 제어부(220)는 적어도 하나 이상의 오퍼레이션을 포함하는 테스크(Task)를 수신하고, 상기 오퍼레이션 각각을 리퀘스트 단위로 구분하여 선입선출(first in first out) 인 큐(Queue) 구조로 저장하도록 메모리(230)를 제어한다.

나아가, 제어부(220)는 리퀘스트의 개수가 임계값을 초과했는지 판단하고, 오퍼레이션의 데이터가 의존성을 띄는지 판단한다. 이는 리퀘스트 최적화를 위한 작업이 오히려 오버헤드(overhead)가 되는 경우를 방지하기 위한 것이다.

리퀘스트의 개수가 임계값을 초과하고, 오퍼레이션의 데이터가 의존성이 없는 경우, 제어부(220)는 리퀘스트 최적화 작업을 실행한다. 그리고 제어부(220)는 리퀘스트 최적화 작업 결과에 따라 큐의 리퀘스트 실행순서를 재설정하게 된다. 이러한 과정은 첨부된 도면과 함께 자세히 후술된다.

도 3은 본 발명의 실시예에 따라 자원을 할당하는 과정을 도시하는 순서도이다.

단계 310에서 제어부(220)는 GPGPU programming model을 사용하여 생성된 테스크를 수신한다. 이후 제어부(220)는 단계 320에서 수신한 테스크를 오퍼레이션 별로 각각 구분하여 리퀘스트 큐를 생성한다. 이러한 큐에는 각 테스크에서 수행될 오퍼레이션들이 순차적으로 저장된다.

단계 330에서 제어부(220)는 리퀘스트의 개수가 임계값을 초과하는지를 판단한다. 이러한 임계값은 시스템에 따라 제어부(220)가 미리 설정할 수 있으며, 구체적인 예시는 첨부된 도면 8에 대한 설명과 함께 후술된다.

만약 리퀘스트된 오퍼레이션의 수가 최적화를 위한 임계값을 초과하지 않으면 제어부(220)는 큐의 오퍼레이션을 GPU가 순차적으로 수행하도록 전달한다 (단계 360).

`만약 리퀘스트의 개수가 임계값을 초과하는 경우, 제어부(220)는 단계 340에서 데이터 의존성을 판단한다.

제어부(220)는 동일 테스크에서 리퀘스트된 두 개 이상의 오퍼레이션에 대해서 오퍼레이션의 input 데이터와 output 데이터가 실행 순서에 의한 데이터 종속성이 있는지 판단한다. 그리고 제어부(220)은 리퀘스트된 오퍼레이션의 특성에 따라 원래의 input 데이터 외에 다른 input 데이터를 추가시켜 output 데이터에 영향을 미치게 되는 데이터 종속성이 있는지 판단한다.

단계 340에서 데이터 의존성을 판단하는 이유는 머징(merging)이나 연속화(Seriating) 처리된 오퍼레이션의 데이터 상호간에 의존성이 존재하는 경우, 이를 처리하기 위한 오버헤드가 머징 등의 이득보다 훨씬 크기 때문이다. 따라서 리퀘스트 최적화 작업은 데이터 의존성 문제가 존재하지 않는 상황에서만 수행된다. 데이터 종속성의 예시는 도 4a 및 도 4b에서 도시된다.

도 4a는 오퍼레이션의 실행순서에 의해 발생하는 데이터 종속성의 예시를 도시하는 도면이다.

모든 오퍼레이션에 대해 머징이나 연속화가 가능한 것은 아니다. 데이터 종속성의 문제 때문이다. 데이터 종속성의 문제는 동일 테스크 내에서 실행 순서에 의해 발생하는 inter-operation dependency problem과 오퍼레이션의 특성에 의한 intra-operation data dependency로 구분할 수 있다.

도 4a와 같은 실행순서를 가지는 오퍼레이션이 inter-operation dependency problem의 예시가 될 수 있다. 도 4a에서 a, b, c, d는 각각 vector나 matrix일 수 있다. 두 번째와 세 번째 오퍼레이션의 결과로 c, d의 data가 결정되게 된다.

네 번째 오퍼레이션을 보면 add 오퍼레이션을 수행하는데, 그 입력으로 a와 두 번째 오퍼레이션의 결과인 c를 입력으로 받고 있다. 만약 두 번째와 네 번째 오퍼레이션에 대해 data 머징 작업을 하게 되면 c의 data가 결정되기 전에 a와 add 오퍼레이션을 수행하게 되므로 올바른 결과를 얻을 수 없게 된다.

나아가, 첫 번째와 마지막 오퍼레이션의 경우 seriating 작업을 할 수 없다. 왜냐하면 모두 product 오퍼레이션을 수행하기는 하지만 마지막 오퍼레이션에서는 두 번째와 세 번째 오퍼레이션으로 인해 value가 변경된 c와 d가 입력 data로 계산되어야 하기 때문이다.

도 4b는 오퍼레이션의 특성에 의해 발생하는 데이터 종속성, 즉 intra-operation data dependency의 예시를 도시하는 도면이다.

도 4b에는 matrix add와 matrix multiply 오퍼레이션을 예시하고 있다. matrix add의 경우 각각의 input matrix에서 동일한 index를 가지는 데이터끼리 오퍼레이션이 수행되며, 그 결과 또한 동일한 index를 가지는 위치에 존재하게 된다.

그러나 matrix multiply의 경우에는 그 계산과정에서 다른 index를 가지는 데이터의 값에 영향을 받게 된다. 만약 데이터 머징을 통해 종래에 다른 리퀘스트에 존재하던 데이터를 처리해야 하는 경우, 이에 대한 처리로 인한 오버헤드가 데이터 머징의 이득보다 훨씬 크게 된다. 따라서 리퀘스트 최적화 작업은 데이터 의존성의 문제가 없는 경우에 한해 진행된다.

다시 도 3에 대한 설명으로 복귀하면, 단계 350에서 제어부(220)는 리퀘스트 최적화 작업을 수행하는데, 이에 대한 구체적인 과정은 도 5 및 도 6에서 상세히 도시된다.

도 5a는 리퀘스트 최적화 작업을 수행하는 도 3의 단계 350의 실시예를 구체적으로 도시하는 도면이다.

도 5의 단계 510에서 제어부(220)는 동일한 오퍼레이션의 존재를 확인하고, 단계 520에서 상기 오퍼레이션의 데이터와 상기 오퍼레이션이 속해있는 테스크의 주소를 저장한다. 각 오퍼레이션들은 리퀘스트된 테스크와 데이터의 위치가 다르기 때문이다.

단계 530에서 제어부(220)는 동일한 오퍼레이션을 합해 하나의 리퀘스트로 설정한다. 본 발명에서는 이와 같이 2개 이상의 동일 오퍼레이션의 데이터를 합쳐서 하나의 리퀘스트 단위로 만드는 것을 머징(merging)이라고 정의한다.

이후 단계 540에서 제어부(220)는 큐의 리퀘스트 실행 순서를 변경한다.

도 5b는 도 5a에 따라 리퀘스트를 처리하는 최적화된 구조를 도시하는 도면이다.

도 5b와 같이, GPU에 core가 100개가 존재하며 데이터의 개수가 각각 40, 20, 30개인 request case A, case B, case C가 있을 수 있다.

이때 각각의 case를 별도로 수행하는 경우 3번의 오퍼레이션 수행시간을 필요로 한다. 그러나 본 발명의 실시예에 따르면 각 케이스의 오퍼레이션이 동일하며, case A의 남아있는 core(560)에 case B, case C의 데이터를 할당하면 1번의 프로세싱으로 완료할 수 있다.

도 6는 리퀘스트 최적화 작업을 수행하는 도 3의 단계 350의 또다른 실시예를 구체적으로 도시하는 도면이다.

도 6의 단계 610에서 제어부(220)는 동일한 오퍼레이션의 존재를 확인하고, 단계 620에서 상기 오퍼레이션의 데이터와 상기 오퍼레이션이 속해있는 테스크의 주소를 저장한다. 각 오퍼레이션들은 리퀘스트된 테스크와 데이터의 위치가 다르기 때문이다.

단계 630에서 제어부(220)는 동일한 오퍼레이션을 연속된 리퀘스트로 설정한다. 본 발명에서는 이와 같이 2개 이상의 동일 오퍼레이션을 연속된 리퀘스트로 만드는 것을 연속화(Seriating)라고 정의한다.

GPGPU는 오퍼레이션을 수행하기 위해 구현된 shader program을 vertex processor와 fragment processor에 loading 시키는 작업을 수반한다. 따라서 오퍼레이션이 자주 변경되면 shader를 계속해서 변경시켜야 하는데, 동일 오퍼레이션을 반복해서 여러 번 수행하는 경우에는 shader program의 loading 작업이 생략 가능하다.

동일 오퍼레이션을 연속적으로 수행하게 되면 데이터 세트만 변경하면 되고, vertex processor와 fragment processor에서 수행시간이 일정하게 되므로 pipeline의 효율이 높아질 수 있다. 따라서 만약 리퀘스트 리스트에서 동일한 오퍼레이션이 여러 군데에 흩어져서 리퀘스트되어 있는 경우, 해당 오퍼레이션을 연속화할 수 있으면 파이프라인의 효율이 높아질 수 있다. 단계 630은 제어부(220)가 이러한 연속화를 실행하는 단계이다. 이후 단계 640에서 제어부(220)는 큐의 리퀘스트 실행 순서를 변경한다.

다시 도 3의 설명으로 복귀하면, 단계 360에서 제어부(220)는 GPU에 프로세싱을 요청하게 된다.

도 7은 본 발명의 실시예에 따라 리퀘스트 최적화 작업을 구현한 윈도우 매커니즘(window mechanism)의 예시를 도시하는 도면이다.

본 발명의 실시예에 따르는 자원할당장치(200)는 최적화를 수행하는 시점을 결정하기 위해 윈도우 메커니즘을 사용한다. 리퀘스트 리스트의 최적화를 위한 작업이 오히려 오버헤드가 될 수 있기 때문이다.

따라서 자원할당장치(200)는 특정 임계값 이상의 GPGPU request가 발생하는 경우에 request 최적화 작업을 수행하고, 이 때 최적화 작업을 위한 범위가 window가 된다. 도 7에서는 윈도우의 크기를 8로 예시하였다. window 크기보다 큰 임계값보다 많은 리퀘스트가 발생하는 경우 최적화 작업을 수행하게 된다. 이러한 윈도우의 크기와 임계값은 시스템에 따라 달리 설정될 수 있다.

도 7의 위쪽과 아래쪽은 각각 최적화 수행 전과 후를 나타내며, 큐에 저장된 리퀘스트 리스트를 도시한다. 도 7에 도시된 바와 같이, 최적화 전에는 GPU는 테스크 단위로 리퀘스트가 발생하므로 동일 테스크에서 리퀘스트한 operation이 모여있다.

최적화 후에는 각 테스크의 add와 subtract 오퍼레이션들이 merging되어 각각 하나의 리퀘스트가 된다. 나아가, 테스크 D의 두 개의 matrix multiply 리퀘스트는 연속된 순서로 최적화 되었다.

도 8은 본 발명의 실시예에 따른 자원 할당 장치(200)의 개략적인 구조를 도시하는 도면이다.

도 8은 multi-core 및 multi-tasking 환경에서 GPGPU 리퀘스트에 대한 오퍼레이션 level 최적화를 수행하기 위해서 queue-based 자료구조를 사용하는 것으로 예시하였다.

도 8에 따르면 본 발명의 실시예에 따른 자원할당장치(200)는 각 테스크에서 queue에 enqueue한 리퀘스트에 대한 최적화를 수행하는 머징 모듈, 오퍼레이션 연속화 모듈 및 최적화 작업을 수행하기 이전에 리퀘스트된 데이터의 종속성을 체크하는 종속성 확인 모듈을 포함한다. 이러한 모듈이 실행되는 위치는 그 구현에 따라서 GPU device driver나 operating system이 될 수 있다.

도 8에서 도시된 테스크 2, 4, 5는 GPGPU programming model을 사용하는 테스크이다. 테스크 2,4 및 5는 GPGPU service 리퀘스트(enqueuing, function call)를 요청한다. 리퀘스트를 통해 queue에는 각 테스크에서 수행될 오퍼레이션들이 순차적으로 저장된다.

만약 리퀘스트된 오퍼레이션의 수가 최적화 임계값를 넘지 않으면 자원 할당 장치(200)는 queue 내의 오퍼레이션을 GPU device driver를 통해 순차적으로 수행한다.

만약 GPU가 수행중인 상태에서 queue에 저장된 리퀘스트의 개수가 threshold를 넘어서게 되면 자원 할당 장치(200)는 리퀘스트 list에 대해서 최적화 작업을 수행하게 된다.

최적화 작업을 위해 자원 할당 장치(200)는 window 내부의 리퀘스트 list에 대하여 먼저 dependency check module을 통해 data dependency information을 추출한 다음 이 정보를 바탕으로 data merging, 오퍼레이션 seriating 작업을 수행한다.

기존 GPU에서 수행중인 오퍼레이션이 끝나고 GPU가 idle상태가 되면, 자원 할당 장치(200)는 queue에서 대기 중인 리퀘스트를 최적화 된 순서로 수행하게 된다. 수행이 끝난 오퍼레이션은 queue 자료구조에 저장된 callback mechanism을 이용하여 GPGPU service를 리퀘스트한 테스크에 오퍼레이션이 완료되었음을 알려 주게 되고, callback mechanism은 callback function 혹은 event trigger, signal 등 구현 방법에 따라 달라질 수 있다.

본 명세서와 도면에 개시된 본 발명의 실시 예들은 본 발명의 기술 내용을 쉽게 설명하고 본 발명의 이해를 돕기 위해 특정 예를 제시한 것뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예들 이외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.

101 : 오퍼레이션이 수행되는 GPU의 코어
102: 오퍼레이션이 수행되지 않는 GPU의 코어
200 : 자원 할당 장치
210: CPU
220 : 자원할당 장치의 제어부
230 : 자원할당 장치의 메모리
540 : GPU

Claims (16)

1. GPU(Graphic Processing Unit)의 자원을 할당하는 방법에 있어서,
   적어도 하나 이상의 오퍼레이션을 포함하는 테스크(테스크)를 수신하고, 상기 오퍼레이션을 리퀘스트 단위로 저장하는 저장 단계;
   동일한 오퍼레이션의 데이터를 합쳐서 하나의 리퀘스트 단위로 설정하는 머징(Merging) 단계; 및
   상기 리퀘스트의 실행순서에 따라 상기 GPU의 자원을 할당하는 단계를 포함하는 것을 특징으로 하는 자원 할당 방법.
2. 제 1항에 있어서, 상기 저장 단계 이후에,
   동일한 오퍼레이션을 연속된 리퀘스트 단위로 설정하는 단계를 더 포함하는 것을 특징으로 하는 자원 할당 방법.
3. 제 2항에 있어서, 상기 머징 단계 이전에,
   상기 리퀘스트의 개수가 미리 설정된 임계값을 초과하는지 여부를 판단하는 효율성 판단 단계를 더 포함하는 것을 특징으로 하는 자원 할당 방법.
4. 제 3항에 있어서, 상기 효율성 판단 단계 이후에,
   상기 오퍼레이션의 데이터 상호 간에 의존 관계가 있는지 여부를 판단하는 데이터 종속성 판단 단계를 더 포함하는 것을 특징으로 하는 자원 할당 방법.
5. 제 4항에 있어서, 상기 테스크는,
   GPGPU 랭귀지 (General Purpose GPU Program Language)를 이용하여 생성된 것을 특징으로 하는 자원 할당 방법.
6. 제 5항에 있어서, 상기 저장 단계는,
   상기 오퍼레이션을 상기 리퀘스트(Request) 단위로 하여 큐 구조(Queue Structure)로 저장하는 단계인 것을 특징으로 하는 자원 할당 방법.
7. 제 6항에 있어서, 상기 머징 단계는,
   상기 동일한 오퍼레이션의 데이터 및 상기 동일한 오퍼레이션이 포함된 테스크의 주소를 저장하는 단계를 더 포함하는 것을 특징으로 하는 자원 할당 방법.
8. 제 7항에 있어서, 상기 머징 단계 이후에,
   상기 큐 구조의 상기 리퀘스트 실행 순서를 변경하는 단계를 더 포함하는 것을 특징으로 하는 자원 할당 방법.
9. GPU(Graphic Processing Unit)의 자원을 할당하는 장치에 있어서,
   리퀘스트를 저장하는 메모리; 및
   적어도 하나 이상의 오퍼레이션을 포함하는 테스크(테스크)를 수신하고, 상기 오퍼레이션을 리퀘스트 단위로 저장하도록 제어하고, 동일한 오퍼레이션의 데이터를 합쳐서 하나의 리퀘스트 단위로 설정하며, 상기 리퀘스트의 실행순서에 따라 상기 GPU의 자원을 할당하는 제어부를 포함하는 것을 특징으로 하는 자원 할당 장치.
10. 제 9항에 있어서, 상기 제어부는,
    동일한 오퍼레이션을 연속된 리퀘스트 단위로 설정하는 것을 특징으로 하는 자원 할당 장치.
11. 제 10항에 있어서, 상기 제어부는,
    상기 리퀘스트의 개수가 미리 설정된 임계값을 초과하는지 여부를 판단하는 것을 특징으로 하는 자원 할당 장치.
12. 제 11항에 있어서, 상기 제어부는,
    상기 오퍼레이션의 데이터 상호 간에 의존 관계가 있는지 여부를 판단하는 것을 특징으로 하는 자원 할당 장치.
13. 제 12항에 있어서, 상기 테스크는,
    GPGPU 랭귀지 (General Purpose GPU Program Language)를 이용하여 생성된 것을 특징으로 하는 자원 할당 장치.
14. 제 13항에 있어서, 상기 제어부는,
    상기 오퍼레이션을 상기 리퀘스트(Request) 단위로 하여 큐 구조(Queue Structure)로 저장하도록 제어하는 것을 특징으로 하는 자원 할당 장치.
15. 제 14항에 있어서, 상기 제어부는,
    상기 동일한 오퍼레이션의 데이터 및 상기 동일한 오퍼레이션이 포함된 테스크의 주소를 저장하도록 제어하는 것을 특징으로 하는 자원 할당 장치.
16. 제 7항에 있어서, 상기 제어부는,
    상기 큐 구조의 상기 리퀘스트 실행 순서를 변경하도록 제어하는 것을 특징으로 하는 자원 할당 장치.

Images