KR20120054027A

KR20120054027A - 프로세서들에 걸쳐 데이터-병렬 쓰레드들을 지닌 프로세싱 로직을 매핑하는 방법

Info

Publication number: KR20120054027A
Application number: KR1020127005130A
Authority: KR
Inventors: 라우렌트 모리체티; 베네딕트 가스터; 자얀쓰 굼마라주
Original assignee: 어드밴스드 마이크로 디바이시즈, 인코포레이티드
Priority date: 2009-07-27
Filing date: 2010-07-23
Publication date: 2012-05-29
Also published as: EP2460073B8; KR101759266B1; WO2011017026A1; CN102576314B; EP2460073B1; CN102576314A; JP2013500543A; JP5934094B2; EP2460073A1; US9354944B2; IN2012DN00929A; US20110022817A1; TW201112118A; TWI525540B

Abstract

프로세서 코어 상의 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하는 방법이 개시되며, 본 방법은 복수의 데이터-병렬 쓰레드들을 하나 이상의 작업그룹들로 그룹화하는 단계, 상기 하나 이상의 작업그룹들로부터의 제1 작업그룹과 상기 프로세서 코어 상의 운영 시스템 쓰레드를 관련시키는 단계, 그리고 상기 제1 작업그룹으로부터의 쓰레드들을 상기 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 구성하는 단계를 포함한다. 예에서, 본 방법은 GPU에 대해 사전에 구성된(previously configured) GPU-커널들의 실행을 멀티-코어 CPU와 같은 CPU 상에서 실행할 수 있도록 인에이블한다. 다수의 데이터-병렬 쓰레드들의 CPU로의 매핑은 CPU 상에 인스턴스화된 고가의 운영 시스템 쓰레드들의 수를 감소시키고 효율적인 디버깅을 가능하게 하는 방식으로 행해진다.

Description

프로세서들에 걸쳐 데이터-병렬 쓰레드들을 지닌 프로세싱 로직을 매핑하는 방법{MAPPING PROCESSING LOGIC HAVING DATA PARALLEL THREADS ACROSS PROCESSORS}

본 발명은 일반적으로 컴퓨터 프로세서 및 데이터-병렬 쓰레드(data-parallel threads)에 관한 것이다.

컴퓨터 및 다른 그러한 데이터 프로세싱 디바이스들은, 일반적으로 제어 프로세싱 유닛(CPU; control processing unit)으로 알려져 있는 적어도 하나의 제어 프로세서를 가진다. 그러한 컴퓨터들 및 프로세싱 디바이스들은 또한 다양한 타입의 특화된 프로세싱을 위해 사용되는 다른 프로세서들, 예를 들어 그래픽 프로세싱 유닛(GPU)을 가질 수 있다. 예를 들어, GPU는 특히 그래픽 프로세싱 연산들에 적합하게 되도록 설계된다. GPU는 일반적으로, 데이터-병렬 프로세싱에서와 같이, 병렬 데이터 스트림들 상에서 동일한 명령을 실행하는데에 이상적으로 적합한 복수의 프로세싱 소자들을 포함한다. 일반적으로, CPU는 호스트 또는 제어 프로세서로서 기능하며 그래픽 프로세싱과 같은 특화된 기능들을 GPU와 같은 다른 프로세서들에 핸드오프(hands-off)한다.

각각의 CPU가 복수의 프로세싱 코어들을 가진 멀티-코어 CPU들을 사용할 수 있므로, 특화된 기능들을 위해서 사용될 수도 있는 실질적인 프로세싱 성능이 CPU들에서 사용가능하다. 멀티-코어 CPU들 또는 GPU들의 계산 코어들 중 하나 이상이 동일한 다이(예를 들어, AMD Fusion^TM)의 일부이거나 상이한 다이들(예를 들어, NVIDIA GPU를 구비한 Intel Xeon^TM )에 있을 수 있다. 최근, CPU와 GPU(예를 들어, CellSPE^TM, Intel Larrabee^TM)의 특성들을 모두 가진 하이브리드 코어들이 범용 GPU(GPGPU; General Purpose GPU) 스타일 컴퓨팅에 일반적으로 제안되어왔다. GPGPU 스타일의 컴퓨팅은 CPU를 사용하여 주로 제어 코드를 실행하고 그리고 성능이 중요한 데이터-병렬 코드(performance critical data-parallel code)를 GPU에 오프로드하는 것을 지원한다. GPU는 주로 가속기(accelerator)로서 사용된다. 멀티코어 GPU들과 GPGPU 컴퓨팅 모델의 결합은 가속기 타겟으로서 CPU 코어들과 GPU 코어들 모두를 포함한다. 상당수의 멀티코어 CPU 코어들이 많은 영역들에서 GPU들과 비슷한 성능을 가진다. 예를 들어, 상당수의 CPU 코어들의 FLOPS(flating point operations per second)는 이제 일부 GPU 코어들의 FLOPS과 비슷하다.

CPU와 GPU를 지닌 이기종 컴퓨팅(heterogeneous computing) 플래폼을 위하여 몇가지 프레임워크들이 개발되어왔다. 이 프레임워크들은 Stanford University의 BrookGPU, NVIDIA의 CUDA, 그리고 Khronos Group이라 명명된 산업 컨소시엄의 OpenCL을 포함한다. OpenCL 프레임워크는 C와 유사한 개발 환경을 제공하는바, 사용자는 이를 이용하여 GPU용 애플리케이션들을 생성할 수 있다. Open CL은, 예를 들어, 사용자로 하여금, 데이터-병렬 계산들과 같은 몇몇 계산들을 GPU로 오프로드하기 위한 명령들을 규정할 수 있게 해준다. OpenCL은 또한 이기종 컴퓨팅 시스템 내에서 코드를 컴파일하고 실행할 수 있는 컴파일러 및 런타임 환경을 제공한다.

그러므로, 일반적으로 GPU 상에서 처리되는 기능들을 실행하기 위하여 CPU 성능을 효율적으로 사용할 수 있게 해주는 방법 및 시스템이 필요하다.

프로세서 코어 상에서 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하기 위한 시스템 및 방법이 개시된다. 프로세서 코어 상에서 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하기 위한 방법은, 복수의 데이터-병렬 쓰레드들을 하나 이상의 작업그룹들로 그룹화하는 단계, 상기 하나 이상의 작업그룹들로부터의 제1 작업그룹과 상기 프로세서 코어 상의 운영 시스템 쓰레드를 관련시키는 단계, 그리고 상기 제1 작업그룹으로부터의 쓰레드들을 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 구성하는 단계를 포함한다. 프로세싱 로직은 앞서서 GPU 상에서 실행하도록된 GPU 커널들을 포함할 수 있다. 프로세서 코어들은 다코어 CPU의 프로세싱 코어들과 같은 CPU 코어들을 포함할 수 있다.

또 다른 실시예는, GPU-커널을 실행하기 위한 방법으로서, 상기 방법은 GPU-커널을 호스트 프로세서에 로딩(load)하는 단계와, 하나 이상의 작업그룹들을 형성하는 단계와(여기서, 각각의 작업그룹은 데이터-병렬 쓰레드들을 포함함), 상기 작업그룹들을 상기 호스트 프로세서에 결합된 하나 이상의 프로세서 코어들의 운영 시스템 쓰레드들과 관련시키는 단계를 포함한다. 각각의 작업그룹은 하나 이상의 운영 시스템 쓰레드들과 관련될 수 있고, 각각의 운영 시스템 쓰레드는 일 프로세서 코어 상에서만 실행되도록 구성된다. 본 방법은 또한 각각의 작업그룹의 데이터-병렬 쓰레드들을 각각의 관련된 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 구성하는 단계를 포함할 수 있다.

또 다른 실시예는 프로세서 코어 상에서 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하기 위한 시스템이다. 이러한 시스템은 프로세서 코어, 상기 프로세서 코어에 결합된 적어도 하나의 메모리, 그리고 GPU-커널 스케쥴러를 포함하는 적어도 하나의 프로세서를 포함한다. GPU-커널 스케쥴러는 복수의 데이터-병렬 쓰레드들을 하나 이상의 작업그룹들로 그룹화하고, 상기 하나 이상의 작업그룹들로부터의 제1 작업그룹을 상기 프로세서 코어 상의 운영 시스템 쓰레드와 관련시키고, 그리고 상기 제1 작업그룹으로부터의 쓰레드들을 상기 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 실행하도록 구성된다.

또 다른 실시예는 컴퓨터 프로그램 로직이 수록된 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품으로서, 상기 컴퓨터 판독가능 매체는 적어도 하나의 프로세서로하여금 복수의 데이터-병렬 쓰레드들을 하나 이상의 작업그룹들로 그룹화하고, 상기 하나 이상의 작업그룹들로부터의 제1 작업그룹을 상기 프로세서 코어 상의 운영 시스템 쓰레드와 관련시키고, 그리고 상기 제1 작업그룹으로부터의 쓰레드들을 상기 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 실행하게 한다.

본 발명의 추가적인 실시예들, 특징들, 및 이점들은, 본 발명의 다양한 실시에들의 구조 및 동작과 함께 첨부의 도면을 참조로 하기에서 자세히 기술될 것이다.

본 명세서에 포함되며 본 명세서의 일부를 이루는 첨부된 도면들은 본 발명의 실시예들을 도시하며, 위에서 제공된 개략적인 설명 및 하기에서 제공되는 실시예들에 대한 상세한 설명과 함께, 본 발명의 원리들을 설명하도록 기능한다. 도면들에서,
도 1은 본 발명의 실시예에 따른 이기종 컴퓨팅 시스템(heterogeneous computing system)을 도시한다.
도 2는 본 발명의 실시예에 따른 GPU 커널 스케쥴러를 도시한다.
도 3은 본 발명의 실시예에 따라 이기종 컴퓨팅 시스템 상에서 코드를 실행하기 위한 프로세스이다.
도 4는 본 발명에 따른 예시적인 메모리 레이아웃을 도시한다.
도 5는 본 발명에 따라 이기종 컴퓨팅 시스템 상에서 작업아이템들을 스케쥴링하기 위한 프로세스이다.
도 6은 본 발명에 따른 쓰레드 스케쥴링의 예시적인 도면이다.

본 발명의 실시예들은 CPU 프로세서 및 GPU 프로세서에서 동일하거나 유사한 코드 베이스를 사용할 수 있게함으로써, 그리고 또한 그러한 코드 베이스들의 디버깅을 용이하게 함으로써 실질적인 이점들을 달성할 수 있다. 비록 본 발명이 여기에서는 특정 애플리케이션들에 대한 예시적인 실시예들을 사용하여 기술되었으나, 본 발명이 이러한 실시예들로 제한되는 것은 아님이 이해되어야 한다. 여기에서 제공되는 기술을 접한 본 기술분야의 통상의 기술자는 본 기술의 범주 및 본 발명이 현저한 유용성을 가진 추가의 분야들에서의 추가적인 수정, 응용, 및 실시예들을 인지할 것이다.

본 발명의 실시예들은 임의의 컴퓨터 시스템, 컴퓨팅 디바이스, 엔터테인먼트 시스템, 미디어 시스템, 게임 시스템, 통신 디바이스, PDA(personal digital assistant) 또는 하나 이상의 프로세서들을 사용하는 임의의 시스템에서 사용될 수 있다. 본 발명은 시스템이 이기종 컴퓨팅 시스템을 포함하는 곳에서 특히 유용하다. 본 명세서에서 사용되는 용어로서의 "이기종 컴퓨팅 시스템"은 복수의 종류의 프로세서들이 사용될 수 있는 컴퓨팅 시스템이다.

본 발명의 실시예들은, 동일한 코드 베이스가 GPU 및 CPU들과 같은 서로 다른 프로세서들에서 실행될 수 있게 한다. 본 발명의 실시예들은, 예를 들어, 제1 타입의 프로세서를 위해 개발된 코드가 약간의 추가적인 노력으로 또는 추가의 노력 없이 또 다른 타임의 프로세서에서 사용될 수 있기 때문에, 멀티코어 CPU들, 및/또는 GPU들을 지닌 프로세싱 시스템들에서 특히 유익할 수 있다. 예를 들어, 본 발명의 실시예들을 사용하여, GPU 상에서 실행하도록 개발된 코드(GPU 커널들이라고도 알려져 있음)가 CPU 상에서 실행되도록 사용될 수 있다.

또한, 본 발명은 쓰레드들의 디버깅을 보조하는 방식으로 CPU 및 다른 프로세서들 상에서, 일반적으로 다양한 데이터-병렬 쓰레드들을 포함하는 GPU 커널들을 사용(deployment)할 수 있게 한다.

이기종 컴퓨팅 시스템(A heterogeneous computing system)

본 발명의 실시예에 따른 예시적인 이종 컴퓨팅 시스템(100)이 도 1에 도시된다. 이종 컴퓨팅 시스템(100)은 CPU(101)와 같은 하나 이상의 CPU들, GPU(102)와 같은 하나 이상의 GPU들을 포함할 수 있다. 이기종 컴퓨팅 시스템(100)은 또한 적어도 하나의 시스템 메모리(103), 적어도 하나의 영구 저장 디바이스(104), 적어도 하나의 시스템 버스(105), 적어도 하나의 입출력 디바이스(106), GPU-커널 스케쥴러(109), 및 디버거(108)를 포함할 수 있다.

CPU(101)는 임의의 상용 제어 프로세서 또는 커스텀 제어 프로세서를 포함할 수 있다. CPU(101)는, 예를 들어, 이기종 컴퓨팅 시스템(100)의 연산을 제어하는 제어 로직을 실행한다. CPU(101)는 두개의 CPU 코어들(141, 142)을 지닌 멀티-코어 CPU와 같은 멀티-코어 CPU일 수 있다. CPU(101)는, 임의의 제어 회로에 부가하여, CPU 코어들(141, 142)의 캐시 메모리들(143, 144)과 같은 CPU 캐시 메모리를 포함할 수 있다. CPU 캐시 메모리들(143, 144)은 CPU 코어들(141, 142) 각각에서 애플리케이션의 실행 중에 명령들 및/또는 파라미터 값들을 임시로 보유(hold)하기 위하여 사용될 수 있다. 예를 들어, CPU 캐시 메모리(143)는 CPU 코어(141) 상에서 제어 로직 명령들의 실행 중에 시스템 메모리(103)로부터, 하나 이상의 제어 로직 명령들, 변수들의 값들, 또는 상수 파라미터들의 값들을 임시로 보유하기 위하여 사용될 수 있다. 일부 실시예들에서, CPU(101)는 또한 특화된 벡터 명령 프로세싱 유닛들을 포함할 수 있다. 예를 들어, CPU 코어(142)는 벡터화된 명령들(vectored instructions)을 효율적으로 프로세싱할 수 있는 SSE(Streaming SIMD Extensions)를 포함할 수 있다. 본 기술분야의 통상의 기술자는 CPU(101)가 선택된 예의 CPU 커어들 보다 더 많은 또는 더 적은 CPU 코어들을 포함할 수 있고, 또한 캐시 메모리를 구비하지 않거나 더 복잡한 캐시 메모리 계층들(hierarchies)을 가질 수 있음을 이해할 것이다.

GPU(102)는 임의의 상용 그래픽 프로세서 또는 커스텀 설계된 그래픽 프로세서를 포함할 수 있다. GPU(102)는, 예를 들어, 선택된 기능들을 위한 특화된 코드을 실행할 수 있다. 일반적으로, GPU(102)는 디스플레이상의 영상에 대한 렌더링 및 기하구조 계산과 같은 그래픽 파이프라인 계산들과 같은 그래픽 기능들을 실행하는데 사용될 수 있다.

GPU(102)는 GPU 전역 캐시(global cache) 메모리(110) 및 하나 이상의 계산 유닛들(112, 113)을 포함할 수 있다. 그래픽 메모리(107)는 GPU(102)에 포함되거나 GPU(102)에 결합될 수 있다. 각각의 계산 유닛(112, 113)은 각각 GPU 로컬 메모리(114 및 115)와 관련된다. 각각의 컴포넌트 유닛은 하나 이상의 GPU 프로세싱 소자들(PE)을 포함한다. 예를 들어, 컴퓨팅 유닛(112)은 GPU 프로세싱 소자들(121, 122)을 포함하고, 컴퓨팅 유닛(113)은 GPU 프로세싱 소자들(123, 124)을 포함한다. 각각의 GPU 프로세싱 소자(121, 122, 123, 124)는 적어도 하나의 프라이빗 메모리(PM)(131, 132, 133, 134) 각각과 관련된다. 각각의 GPU 프로세싱 소자는 하나 이상의 스칼라 및 벡터 부동 소수점 유닛들을 포함할 수 있다. GPU 프로세싱 소자들은 또한 역-제곱 루트 유닛들(inverse-square root units) 및 사인/코사인 유닛들과 같은 특수 목적 유닛들을 포함할 수 있다. GPU 전역 캐시 메모리(110)는 시스템 메모리(103)와 같은 시스템 메모리, 및/또는 그래픽 메모리(107)와 같은 그래픽 메모리에 연결될 수 있다.

시스템 메모리(103)는 동적 랜덤 엑세스 메모리(DRAM)와 같은 적어도 하나의 비-영구적(non-persistent) 메모리를 포함할 수 있다. 시스템 메모리(103)는, 애플리케이션들 또는 다른 프로세싱 로직의 일부를 실행하는 동안 프로세싱 로직 명령들, 상수 값들 및 변수 값들을 보유할 수 있다. 예를 들어, 일 실시예에서, GPU 커널 스케쥴러(109)의 제어 로직 및/또는 다른 프로세싱 로직이 CPU(101)에 의한 GPU-커널 스케쥴러(109)의 실행 중에 시스템 메모리(103) 내에 상주할 수 있다. 여기서 사용되는 것과 같은 용어 "프로세싱 로직"은 제어 흐름 명령들, 계산을 수행하기 위한 명령들, 및 자원에 대한 관련된 액세스를 위한 명령들을 지칭한다.

영구 메모리(persistent memory)(104)는 자기 디스크, 광학 디스크, 또는 플래시 메모리와 같은, 디지털 데이터를 저장할 수 있는 하나 이상의 저장 디바이스들을 포함한다. 영구 메모리(104)는, 예를 들어, GPU-커널 스케쥴러(109) 및 디버거(108)의 명령 로직 중 적어도 일부를 저장할 수 있다. 예를 들어, 이기종 컴퓨팅 시스템(100)의 시작시, 운영 시스템 및 다른 애플리케이션 소프트웨어가 영구 저장장치(104)로부터 시스템 메모리(103)로 로딩될 수 있다.

시스템 버스(105)는 PCI(Peripheral Component Interconnect) 버스, AMBA(Advanced Microcontroller Bus Architecture) 버스, ISA(Industry Standard Architecture) 버스, 또는 그러한 디바이스를 포함할 수 있다. 시스템 버스(105)는 또한 로컬 영역 네크워크(LAN)과 같은 네트워크를 포함할 수 있다. 시스템 버스(105)는 이기종 컴퓨팅 시스템(100)의 컴포넌트들을 포함하는 컴포넌트들을 결합하기 위한 기능을 포함한다.

입/출력 인터페이스(106)는 키보드, 마우스, 디스플레이 및/또는 터치 스크린과 같은 사용자 입출력 디바이스들을 연결하는 하나 이상의 인터페이스들을 포함한다. 예를 들어, 사용자 입력이 사용자 인터페이스(106)에 연결된 키보드 및 마우스를 통해 이기종 컴퓨팅 시스템(100)에 제공될 수 있다. 출력 GPU-커널 스케쥴러(109) 및 디버거(108)와 같은 이기종 컴퓨팅 시스템(100)의 출력은 사용자 인터페이스(106)를 통해 디스플레이로 출력될 수 있다.

그래픽 메모리(107)가 시스템 버스(105) 및 GPU(102)에 연결된다. 그래픽 메모리(107)는, 일반적으로, GPU에 의한 빠른 액세스를 위해 시스템 메모리(103)로부터 전송된 데이터를 보유하는데 사용된다. 예를 들어, GPU(102)와 그래픽 메모리(107) 사이의 인터페이스는 시스템 버스 인터페이스(105)보다 몇배 빠를 수 있다.

디버거(108)는 이기종 컴퓨팅 시스템(100) 상에서 실행되는 애플리케이션 코드 및 다른 프로세싱 로직을 디버깅하는 기능을 포함한다. 예를 들어, 디버거(108)는 애플리케이션 코드 및/또는 다른 프로세싱 로직의 실행 중에 하나 이상의 변수들을 모니터링하기 위한 기능을 포함할 수 있다. 이기종 컴퓨팅 환경에서, 디버거(108)는 CPU들 상에서 그리고 GPU들 상에서 애플리케이션 코드 및 다른 프로세싱 로직의 실행을 모니터링하는 성능을 필요로할 수 있다.

GPU-커널 스케쥴러(109)는 명시적으로 GPU 상에서 실행하도록 기록된 프로세싱 로직 및 함수들을 GPU 또는 CPU에 대해 스케줄링하는 기능을 포함한다. GPU-커널 스케쥴러는 하기에서 도2와 관련하여 더 기술된다. 본 기술분야의 통상의 기술자는 디버거(108)와 GPU-커널 스케쥴러(109)가 소프트웨어, 펌웨어, 하드웨어, 또는 이것들의 임의의 조합을 사용하여 구현될 수 있음을 이해할 것이다. 소프트웨어에서 구현될 때, 예를 들어, GPU-커널 스케쥴러(109)는, 컴파일되어 실행할 때 시스템 메모리(103)에 상주하는 C 또는 OpenCL로 기록된 컴퓨터 프로그램일 수 있다. 소스 코드 형태 및/또는 컴파일된 실행가능한 형태에서, GPU-커널 스케쥴러(109)는 영구 메모리(104) 내에 저장될 수 있다. 일 실시예에서, GPU-커널 스케쥴러(109) 및/또는 디버거(108)의 기능 중 일부 또는 전부가 Verilog, RTL, 네트리스트와 같은 하드웨어 기술 언어에 규정되어, 여기에 기술된 발명의 양상들을 구현하는 하드웨어 디바이스를 생성하기 위한 마스크작업물/포토마스크의 생성을 통해 제조 공정을 구성한다.

본 기술분야의 통상의 기술자는 이기종 컴퓨팅 시스템(100)이 도 1에 도시된 것보다 많은 또는 적은 컴포넌트들을 포함할 수 있음을 이해할 것이다. 예를 들어, 이기종 컴퓨팅 시스템(100)은 하나 이상의 네트워크 인터페이스들, 그리고 또는 OpenCL 프레임워크와 같은 소프트웨어 애플리케이션들을 포함할 수 있다.

GPU-커널들

여기에서 사용된 용어로서의 "GPU-커널"은 GPU 상에서 하나 이상의 기능들 또는 연산들을 실행하는 코드 및/또는 프로세싱 로직을 포함한다. 예를 들어, GPU 커널들은 행렬 곱셈(matrix multiplication), 행렬 전치(matrix transpose), 세부분할(subdivision), 식 해법(equation solving), 및 다양한 다른 연산들을 위해 개발된다. 예를 들어, GPGPU 모델에서, GPU 커널들은 GPU 상에서 실행되도록 CPU에 의해 오프로드될 수 있는 함수들 및/또는 다른 연산들의 코드 단편들(code fragments)이다. 일반적인 GPGPU 애플리케이션에서, 동일한 GPU-커널 코드가 복수의 병렬 데이터 스트림들 상에서 동시에 실행될 것이다. 이는 "데이터-병렬" 컴퓨팅으로 알려져 있다. 예를 들어, 두개의 행렬들을 곱하는데 있어서, 두개의 소스 행렬들로부터 복수의 대응하는 원소들의 쌍들이 서로 다른 프로세싱 코어들을 사용하여 동시에 곱해질 수 있다. 비록 간단한 예이지만, 행렬 곱셈은 GPU 상에서 데이터-병렬 연산들을 보여줄 수 있다.

위의 행렬 곱셈 예에 이어, 결과적인 행렬의 각각의 원소(element)에 대한 계산은 별개의 실행 쓰레드(쓰레드)로서 고려될 수 있다. 결과 행렬의 각각의 원소에 대응하는 쓰레드들은 병렬로 실행할 수 있다. GPU(102)에서, 예를 들어, 쓰레드들은 각각의 프로세싱 소자(121, 122, 123 및 124)에 대해 동시에 실행될 수 있다.

그래픽 애플리케이션들에서 일반적인 것과 같이, 예를 들어, 복수의 행렬 쌍들이 곱해질 것이라면, 행렬들의 각각의 쌍은 컴퓨팅 소자들(112 및 113)과 같은 컴퓨팅 소자에 할당될 수 있다.

GPU 커널들의 실행은 GPU(102)와 관련하여 기술될 수 있다. GPU-커널은 일반적으로 복수의 쓰레드들을 병렬로 실행한다. 이 병렬 쓰레드들 각각은 "작업아이템"이다. 각각의 작업아이템은, 프로세싱 소자들(121, 122, 123, 또는 124)과 같은 프로세싱 소자상에서 실행할 수 있다. 계산 유닛에 할당된 작업아이템들은 "작업그룹"으로 알려져 있다.

일반적으로, 작업아이템들 사이의 동기화(synchronization)는 단일 작업그룹 내의 동기화로 제한된다. 이러한 제약은 일반적으로 다수의 쓰레드들이 있는 환경들에서 강화되는바, 따라서 쓰레드들의 수가 효율적으로 관리될 수 있다. 그러나, 일부 실시예들에서, 동기화는 단일 작업그룹 내의 작업아이템들로 제한되지 않을 수 있다.

GPU-커널 스케쥴러

도 2는 본 발명의 실시예에 따른, GPU-커널 스케쥴러(109)의 컴포넌트들을 도시한다. GPU 커널 스케쥴러(109)는 코드 분석기(201), CPU 메모리 매핑기(mapper)(203), 작업그룹 스케쥴러(205), 및 쓰레드 스케줄러(207)를 포함할 수 있다. 본 기술분야의 통상의 기술자는 GPU-커널 스케쥴러(109)가 추가의 컴포넌트들 및/또는 컴포넌트들(201-207)의 상이한 조합들을 포함할 수 있음을 이해할 것이다.

코드 분석기(201)는 OpenCL 코드와 같은 코드를 분석하기 위한 기능을 포함한다. 코드 분석기(201)는, CPU 또는 대안적으로 GPU 상에서 유익하게 스케쥴링될 수 있는 분석되고 있는 코드 내의 GPU-커널들 및/또는 코드 조각들을 식별할 수 있다. 코드 분석기(201)는 또한 타겟 플래폼의 세부사항들을 알기 위한 기능을 포함할 수 있다. 예를 들어, 코드 분석기(201)는 CPU 코어들의 수, 및 타겟 플래폼에서 사용가능한 GPU 코어들을 식별할 수 있다. 코드 분석기(201)는 또한 시스템 메모리, 캐시 메모리, 범용 GPU 캐시 메모리 등의 양을 식별할 수 있다.

CPU 메모리 매핑기(203)는 실행을 위해 코드가 디스패치될 수 있는 CPU의 메모리 사용가능성을 결정하고, 그리고 매핑된 GPU 커널들을 실행하기 위하여 CPU 메모리를 준비하는 기능을 포함한다.

작업그룹 스케쥴러(205)는 작업그룹을 스케쥴링하는 기능을 포함한다. 예를 들어, 작업그룹 스케쥴러(205)는 각각의 작업그룹을 실행하는데 사용될 수 있는 GPU의 컴퓨팅 유닛들의 적합한 세트를 결정할 수 있다. 또 다른 실시예에서, 작업그룹 스케쥴러는 또한, 작업그룹들이 하나 이상의 CPU 코어들 상의 쓰레드들에 할당될 수 있도록 GPU-커널의 작업아이템 쓰레드들이 어떻게 작업그룹들로 그룹화되어야 하는지를 결정할 수 있다. 작업그룹 스케쥴러는 또한 GPU-커널 쓰레드들의 작업그룹을 CPU 또는 CPU 코어에 매핑하는 기능을 포함할 수 있다.

쓰레드 스케쥴러(207)는 GPU-커널의 쓰레드들을 GPU 또는 CPU 상에 스케쥴링하는 기능을 포함한다. 예를 들어, 쓰레드 스케쥴러(207)는 쓰레드들의 프로세싱 요건들이 수용될 수 있는 방식으로 프로세싱 소자들(121, 122, 123, 또는 124)에 대한 쓰레드들의 할당을 결정할 수 있다. 일 실시예에서, 쓰레드 스케쥴러(207)는 GPU(102) 내의 어떤 프로세싱 소자에서 각각의 작업아이템이 스케쥴링될 수 있는지를 결정한다. 또 다른 실시예에서, 쓰레드 스케쥴러(207)는 CPU(101) 상의 작업아이템 쓰레드들을 스케쥴링한다. 예를 들어, 쓰레드 스케쥴러(207)는 CPU 코어(142)와 같은 단일의 CPU 코어 상에서 하나의 작업그룹의 작업아이템 쓰레드들을 스케쥴링할 수 있다. 예를 들어, 쓰레드 스케쥴러(207)는 CPU 코어(142)와 같은 단일 CPU 코어 상에서 하나의 작업그룹의 작업아이템 쓰레드들을 스케쥴링할 수 있다. 본 발명의 실시예에 따른 모듈들(201-207)의 기능은 하기에서 도 3 내지 도 6과 관련하여 더 설명된다.

CPU 코어들에서 GPU-커널들을 매핑 및 실행(Mapping and executing GPU-kernels on CPU cores)

도 3은 본 발명의 실시예에 따른 이기종 컴퓨팅 시스템 상에서 코드들 실행하기 위한 프로세스(300)를 도시한다. 프로세스(300)는, 예를 들어, 이기종 컴퓨팅 시스템(100) 상에서 실행할 수 있다. 일 실시예에서, 프로세스(300)는 GPU 커널 스케쥴러(109)의 프로세싱 로직의 흐름을 나타낼 수 있다.

일반성을 잃지 않고, 하기의 설명은 주로 OpenCL 프레임워크에 기반한다. 본 기술분야의 당업자는 본 발명의 실시예들이 CUDA 프레임워크, BrookGPU 프레임워크 등과 같은(그러나 이것들에 국한된 것은 아님) 다른 개발 및 실행 프레임워크를 사용하여 구현될 수 있음을 인지할 것이다. 위에서 기술된 바와 같이, OpenCL은 이기종 컴퓨팅 시스템에서 코드가 개발, 컴파일, 및 실행될 수 있는 개발환경, 컴파일러, 그리고 런타임 환경을 제공한다.

OpenCL은 또한 선택된 프로세서에서 실행될 GPU-커널을 배치하는 것과 같은 다양한 기능들을 실행하기 위하여 사용자 애플리케이션들에 의해 호출될 수 있는 애플리케이션 프로그래밍 인터페이스들(API) 및 빌트인 라이브러리 함수들을 제공한다. 일반적으로, OpenCL 프레임워크는 주로 호스트 시스템에서 실행되며 그리고 명령들(예를 들어, GPU 커널들을 포함하는 실행가능한 코드)을 각각의 프로세서에 배치함으로써 결합된 프로세서들의 동작을 제어한다. 예를 들어, OpenCL은 주로 CPU 코어(141) 상에서 실행될 수 있고, 그리고 각각의 디바이스들에 실행될 명령들을 배치함으로써 GPU(102) 및 CPU 코어들(141, 142)의 동작을 제어할 수 있다.

단계(301)에서, 하나 이상의 애플리케이션들에 대한 코드가 로딩된다. 로딩된 코드는 소스 코드 또는 바이트-코드와 같은 다른 형태의 사전-컴파일 코드일 수 있다. 일부 실시예들에서, 코드는 또한 임베딩된 컴파일된 함수들(embeded compiled functions)을 포함할 수 있다. 예를 들어, 일부 함수들은 애플리케이션 내에 임베딩된 함수 호출들(function calls)에 근거하여 라이브러리로부터 동적으로 링크될 수 있다. 설명의 목적을 위하여, 로딩된 코드는 소스 코드 형태, OpenCL과 같은 프로그래밍 언어로되어 있는 것으로 가정될 것이다. 소스 코드는 초기에, 예를 들어, 영구 저장 디바이스(104)에 상주할 수 있다. 단계(301)에서 코드를 로딩하는 데 있어서, 소스 코드는 메모리, 예를 들어 시스템 메모리(103)에 로딩될 수 있다. 로딩된 코드는 소스코드, 사전-컴파일 코드, 및/또는 컴파일된 바이너리들의 조합을 포함할 수 있다. 예를 들어, 프로세스(300)가 구현될 수 있는, OpenCL 개발, 컴파일, 및 실행 프레임워크는 GPU 커널의 소스 코드 및/또는 컴파일된 바이너리들의 로딩을 허용한다. OpenCL 프로그램은, 예를 들어, GPU-커널들, 제어 흐름 코드, 및 GPU-커널들에 의해 호출되는 다른 함수들을 포함할 수 있다.

단계(303)에서, 로딩된 코드가 분석된다. 코드의 분석은 코드를 파싱하는 것을 포함한다. 일부 실시예들에서, 단계(303)에서 분석된 코드는 유효한 OpenCL 코드 또는 C와 같은 또 다른 프로그래밍 언어나 프레임워크 내의 코드를 포함할 수 있다. 분석 단계(303)에서, 요구되는 CPU 자원들이 결정될 수 있다. 예를 들어, 분석 및/또는 파싱은 하나 이상의 CPU 코어들에서 스케쥴링되는데 요구되는 쓰레드들(작업아이템들)의 전체 개수를 결정할 수 있다. 또한, 분석 단계(303)는 GPU-커널에 의해 사용되는 로컬 메모리 및 프라이빗 메모리의 실제 양과 같은 메모리 요구조건들을 결정하기 위하여 사용될 수 있다. 일 실시예에서, 단계들(301, 303)은 코드 분석기(201)의 프로세싱 로직을 사용하여 구현될 수 있다.

단계(305)에서, 이기종 컴퓨팅 시스템은 단계(301)에서 로딩된 코드를 실행하도록 구성된다. 예를 들어, 단계(303)에서 수행된 코드 분석에 근거하여, 로딩된 코드를 작동(run)시키기 위하여 다수의 CPU들 및 GPU들이 할당될 수 있다. 단계(305)는 로딩된 코드의 실행을 준비하기 위하여 메모리(103)와 같은 메모리 자원들을 구성하는 것을 포함할 수 있다.

로딩된 코드 내의 각각의 함수 및/또는 GPU-커널에 대해 단계들(307-323)이 반복된다. 예를 들어, 로딩된 소스 코드는 각각의 함수 및/또는 GPU 커널을 식별하는 탑-바텀 방식으로 스캔될 수 있다. 단계(307)에서, 함수 및/또는 GPU-커널이 식별된다. 일 실시예에서, 예를 들어, GPU 커널들은 OpenCL 내의 _kernel 식별자와 같은 소정의 식별자에 의해 식별될 수 있다.

단계(309)에서, 단계(307)에서 식별된 코드 세그먼트를 CPU 상에서 실행할지 또는 GPU 상에서 실행할지가 결정된다. 예를 들어, 디폴트 기능이 CPU 상에서 GPU-커널들이 아닌 다른 함수들을 실행하고, 그리고 GPU 상에서 모든 GPU 커널들을 실행하려 할 수 있다. 명령 또는 함수가 데이터-병렬이면, 예를 들어, 코드 내에 임베딩된 식별자들에 근거하여 다른 고려사항이 결정될 수 있다. 데이터-병렬 명령들 또는 함수들은 바람직하게는 GPU에 스케쥴링될 수 있다. 로드 밸런싱 요건들 및 애플리케이션 특성들과 같은 다른 기준들이 또한 사용될 수 있다.

프로세싱 로직 및/또는 코드 세그먼트가 GPU 상에서 실행될 것으로 결정된다면, 그것은 단계(311)에서 GPU 상에서 실행되도록 스케쥴링된다. 일부 실시예들에서, 처리 로직 및/또는 코드 세그먼트들은 특정 GPU 상에서 구현되도록 스케쥴링된다.

단계(311)에서, 처리 로직 및/또는 코드 세그먼트가 선택된 GPU 상에서 스케쥴링된다. 단계(311)은 GPU의 구조, 예를 들어, GPU 내의 컴퓨팅 디바이스들의 수, 및 각각의 컴퓨팅 디바이스 내의 프로세싱 소자들의 수를 결정하는 것을 포함할 수 있다. 단계(311)은 또한 GPU를 위한 콘텍스트 및 커맨드 큐를 생성하는 단계, 상기 콘텍스트와 관련된 메모리 오브젝트들을 생성하는 단계, GPU-커널 오브젝트들을 컴파일하고 생성하는 단계, GPU-커널 오브젝트들을 실행하기 위하여 대응하는 커맨드들을 커맨드 큐에 발행하는 단계, 그리고 발행된 커맨드들에 대한 임의의 동기화를 수행하는 단계를 포함할 수 있다.

GPU의 구조를 결정하는 단계는, 예를 들어, OpenCL API를 사용하여 시스템에서 사용가능한 컴퓨팅 디바이스들(예를 들어, CPU들, GPU들)에 대해 쿼리하고, 그것의 로컬 정보에 대하여 식별된 컴퓨팅 디바이스들 중 하나 이상을 쿼리하는 것을 포함할 수 있다. 컴퓨팅 디바이스들의 리스트로부터, GPU 프로세싱 소자들, 범위 제한들, 작업그룹 사이즈, 서로 다른 메모리 공간들의 사이즈들, 최대 메모리 오브젝트 사이즈 등을 결정하기 위하여 GPU 디바이스가 쿼리될 수 있다.

선택된 GPU 상에서 실행될 프로세싱 로직 및/또는 코드 세그먼트를 스케쥴링하는데 있어서, 코드 세그먼트(예를 들어, 실행가능한 커널 오브젝트)를 포함하는 실행가능한 코드를 포함하는 명령이 선택된 GPU의 콘텍스트에 생성된 명령 큐에 대해 스케쥴될 수 있다. 여기에서 사용되는 것과 같이, "콘텍스트"는, GPU-커널을 위한 실행 환경을 정의한다. 콘텍스트는 디바이스, 메모리, 및 커널과 관련된 다른 프로그램 오브젝트들에 대한 핸들들 및 다른 정보를 포함할 수 있다. 예를 들어, 콘텍스트는 상기 콘텍스트가 사용하도록 허용된 GPU 디바이스 및 메모리 위치들에 실행 커널을 제공할 수 있다.

생성된 메모리 오브젝트들은 소스 및 목적지 오브젝트들에 대응할 수 있다. 예를 들어, 프로세싱 로직 및/또는 코드 세그먼트가 반복적인 어레이 합산을 수행한다면, 소스 오브젝트들은 두개의 소스 어레이들일 수 있다. 목적지 오브젝트는 출력 결과가 기록되는 어레이일 수 있다. 메모리 오브젝트들은 시스템 메모리(103) 내에 생성되거나 그래픽 메모리(107) 내에 생성될 수 있다. 메모리 오브젝트들은 캐시들(110, 143, 144)과 같은 다양한 캐시들에서 실질적으로 캐시될 수 있다. 생성된 각각의 메모리 오브젝트는 대응하는 콘텍스트와 관련된다.

실행가능한 커널 오브젝트들의 생성은 프로세싱 로직 및/또는 코드 세그먼트를 컴파일하고, 그리고 임의의 필요한 디바이스 특정 모듈들을 링크함으로써 이루어진다. 예를 들어, 컴파일된 커널 오브젝트는 커널 함수 코드 또는 명령들, 커널에 제공된 임의의 인자들(arguments), 관련된 콘텍스트, 및 실행될 GPU에 관련된 라이브러리 코드를 포함할 수 있다.

커널 오브젝트들이 생성된 후, 커널을 실행하는 커맨드가 커맨트 큐에 큐잉(queueing)된다. 커맨드가 인큐(enqueue)되는 방식은 그 커맨드가 데이터-병렬인지 또는 태스크-병렬 커맨드인지에 따라 특정될 수 있다. 예를 들어, 반복적인 어레이 합산 예에서, 데이터-병렬 커맨드는 단일 커맨드를 특정 수의 컴퓨팅 디바이스들에서 병렬적으로 실행할 명령들로 인큐(enqueue)할 수 있으며, 반면 태스크-병렬 모델은 결과적으로 다수의 개별 커맨드들이, 각각의 어레이 요소(array element)에 대해 일 커맨드씩, 인큐되게 할 수 있다.

단계(309)에서, 프로세싱 로직 및/또는 코드 세그먼트가 CPU 상에서 실행되어야 한다는 결정이 이루어지면, 프로세스(300)는 단계(313)으로 진행한다. 단계(313)에서, 하나 이상의 CPU들이 코드 세그먼트를 실행하기 위하여 선택될 수 있다. 일부 실시예들에서, 예를 들어, 멀티-코어 CPU 시스템들에서, CPU의 선택은 CPU의 로드 또는 프로세싱 성능에 근거할 수 있다. 사용가능한 캐시 메모리의 유효성 및 크기 등과 같은 다른 고려사항들이 또한 고려될 수 있다.

설명의 편이를 위하여, 단계들(311-321)에 대한 설명은 CPU 상에서 실행될 프로세싱 로직 및/또는 코드 세그먼트가 GPU-커널임을 가정한다. GPU 커널을 선택된 CPU에 매핑하는 것은 미세립(fine-grained) GPU 쓰레드들(즉, 워크아이템들)을 CPU 코어에 매핑하는 것과 그리고 또한 GPU 메모리 계층을 CPU 메모리 시스템에 매핑하는 것을 포함한다. 단계(315)에서, GPU-커널 쓰레드들은 선택된 CPU에 매핑된다. 만약 GPU-커널이 쉽게(naively) CPU에 매핑된다면, 각각의 GPU 작업아이템은 운영 시스템(OS) 쓰레드에 매핑될 것이다. 단계(315)의 프로세싱은 워크그룹 스케쥴러(205)에 의해 제공된 기능의 일부일 수 있다.

CPU는 훨신 더 제한된 수의 하드웨어 콘텍스트들의 가지며, 종종 단 하나의 하드웨어 콘텍스트를 가진다. OS는 일반적으로 OS 쓰레드들을 스케쥴링 및 실행하는 역할을 한다. OS 쓰레드들로 작업아이템들을 쉽게 매핑하는 것은 결과적으로 수천개 아니면 수백개의 쓰레드들이 되게 한다. 단일 콘텍스트에서 실행하는 다수의 쓰레드들을 가지는 것은 결과적으로 각각의 프로세스가 실행될 때 요구되는 많은 콘텍스트-스위치들을 포함하는 이유들로 실질적인 비효율성을 야기할 수 있다. 또한, OS로 하여금 다수의 쓰레드들을 관리하게 하는 것은 매우 비효율적일 수 있다. 본 발명의 실시예들은, 높은 성능을 달성하고 또는 많은 쓰레드들을 가진 애플리케이션들의 디버깅을 용이하게 해주는 그러한 방식으로 GPU로부터 CPU로의 매핑을 달성한다.

본 발명의 실시예들에서, GPU 커널의 작업아이템들을 CPU 코어에 매핑하는 것은, 멀티-코어 CPU들을 이용하는 것, 그리고 콘텍스트 스위칭 등과 관련된 비효율성을 피하기 위하여 관리가능한 수의 OS 쓰레드들을 가지는 것과 같은 방식으로 행해진다. 그러므로, 본 발명의 실시예들에서, 작업아이템들 대신, 작업그룹이 OS 쓰레드와 매핑 및/또는 관련된 유닛이다. 하나 이상의 작업아이템들이 작업그룹으로 그룹화된다. 작업그룹 내의 작업아이템들의 수는 미리정해지거나 사용가능한 프로세싱 코어들의 수 및 용량과 같은 기준에 근거하여 결정될 수 있다. 작업그룹을 OS 쓰레드들과 매핑 및/또는 관련짓는 것은 워크 그룹을 위한 새로운 OS 쓰레드를 야기하거나, 또는 상기 워크그룹을 이미 존재하는 OS 쓰레드에 첨부(attach)하는 구성을 포함할 수 있다. 새로운 OS 쓰레드들을 발생시키고 그리고 기존의 쓰레드에 첨부하기 위한 API 함수들은, 하나 이상의 OpenCL 프레임워크(OpenCL 런타임 시스템을 포함함) 및 기저의 운영 시스템에 의해 제공된다.

예를 들어, 작업그룹과 관련된 OS 쓰레드를 위한 프로세서 친화도(processor affinity)를 설정함으로써, GPU-커널의 각각의 작업그룹이 CPU 코어에 매핑될 수 있다. 각각의 CPU 코어는 하나 이상의 작업그룹들에 할당될 수 있다. CPU 코어 당 복수의 작업그룹들이 병렬로 실행될 수 있다. 일 실시예에서, 각각의 CPU 코어는 한번에 단일의 작업그룹만을 실행하도록 구성된다. 예를 들어, 각각의 CPU 코어에는 단일의 OS 쓰레드만이 생성된다. 각각의 CPU 코어는 하나의 작업그룹을 끝까지 실행하고 그리고 또 다른 작업그룹을 실행함으로써 복수의 작업그룹들을 실행할 수 있다.

단계(317)에서, 작업그룹 내의 쓰레드들이 매핑되고 그리고/또는 구성된다. 단계(317)의 프로세싱은 쓰레드 스케쥴러(207)에 의해 제공된 기능의 일부일 수 있다. 작업그룹에 매핑되는 각각의 OS 쓰레드 내에서, 작업그룹 쓰레드들은 순차적으로(in sequence) 하나씩 실행되도록 구성된다. 작업그룹 쓰레드들은 사용자-레벨 쓰레드들로써 구현된다. 사용자-레벨 쓰레드들로서 작업아이템 쓰레드들을 구현하는 것은 사용자 스페이스와 커널 스페이스 사이에서 스위치해야하는 부담 및 다수의 콘텍스트 스위치들과 관련된 비용을 방지해준다. 대부분의 경우, GPU-커널들은 사용자 스페이스 애플리케이션들에 적용되며 커널 스페이스 액세스를 필요로하는 시스템 자원들에 대한 직접적인 액세스를 필요로 하지 않는다. 당업자에 의해 공지된 바와 같이, 단일의 운영 시스템 레벨 쓰레드 내에서 복수의 사용자 레벨 쓰레드들이 구현될 수 있다.

본 발명의 일부 실시예들에서, 작업아이템 쓰레드들은 작업그룹 내의 그룹들에서 실행될 수 있다. 예를 들어, 하나 이상의 부동 소수점 계산 또는 이중 계산을 동시에 수용할 수 있는 SSE유닛(예를 들어, 시스템(100)내의 SSE 유닛(145))과 같은 벡터 유닛이 사용가능한 실시예들에서, 컴파일러는 SSE 유닛의 풀 프로세싱 성능(full processing capacity)이 사용되게끔 병렬로 실행할 다수의 작업아이템들을 결합할 수 있다.

단계(319)에서, CPU 코어들에 액세스가능한 메모리는 GPU가 사용가능한 메모리 계층을 수용하도록 매핑된다. 단계(203)의 프로세싱은 CPU 메모리 매퍼(203)에 의해 제공되는 기능의 일부일 수 있다. GPU 커널들이 CPU 코어들 상에서 실행될 수 있도록 GPU 메모리 계층을 CPU 코어들에 매핑하는 것은 몇가지 양상들을 포함한다. GPU-커널 코드가 GPU 메모리 계층 내의 위치들에 대한 참조들을 포함할 수 있으므로 GPU 메모리 계층으로부터 CPU 메모리로의 매핑이 요구될 수 있다. CPU 코어들은 일반적으로 그것의 메모리(예를 들어, 시스템 메모리(103))를 위한 단일의 어드레스 공간만을 가지며, 반면, GPU 코어들은 몇개의 개별적으로 어드레스가능한 메모리들을 가질 수 있다. GPU 전역 메모리, 컴퓨팅 디바이스 로컬 메모리, 및 프로세싱 소자 프라이빗 메모리는 모두 CPU 메모리에 매핑될 수 있다.

GPU 메모리(107)와 같은 GPU 전역 메모리는 메모리(103)와 같은 시스템 메모리에 직접 매핑될 수 있다. GPU 로컬 메모리 및 프라이빗 메모리의 매핑은 더 많은 더 많은 어감의 접근을 필요로 한다. 메모리와 관련되어 사용되는 것과 같은 매핑은 자동 주소 변환 메커니즘을 설정하는 것을 포함하며, 상기 자동 주소 변환 메커니즘에 의해, CPU 코어 상에서 실행되는 GPU-커널에 포함된 메모리 주소가 GPU와 관련된 메모리 계층 내의 위치 대신 시스템 메모리(103)에 리디렉션(redirection)된다.

GPU 로컬 메모리(114, 115)와 같은 GPU 로컬 메모리는 컴퓨팅 유닛의 프로세싱 소자들 간에 공유된다. 그러므로, 일 GPU 로컬 메모리가 작업그룹의 모든 작업아이템들 간에 공유된다. 작업그룹들이 CPU에 매핑될 때, 일 작업그룹이 단일의 CPU 코어에 매핑되므로, 대응하는 CPU 로컬 메모리가 이 CPU 코어로 있게될 수 있다. 많은 경우에, GPU에서 로컬 메모리의 실제 사용은 CPU 코어의 캐시 메모리에 완전히 적합하게(fit)끔 될 수 있다.

GPU 로컬 메모리들(114, 115)과 같은 GPU 로컬 메모리는 작업그룹 내의 작업아이템들 사이에서 공유된다. 본 발명의 실시예들은 한번에 단일의 작업그룹만을 실행하기 위하여 각각의 CPU 코어를 제한할 수 있다. CPU가 한번에 단일 작업그룹만을 실행할 때, GPU 로컬 메모리에 대응하는 단일의 할당(single allocation)만이 CPU 코어에 의해 사용된다. 따라서, CPU 코어마다 단일의 로컬 메모리가 할당될 수 있고, 할당된 로컬 메모리는 CPU 코어 상에서 실행되는 연속적인 작업그룹들에 대해 재사용될 수 있다. 각각의 컴퓨팅 디바이스에 대해 시스템 메모리의 연속적인 메모리 영역에서 로컬 메모리가 할당될 수 있다. 바람직하게는, CPU 코어 내의 캐시 메모리는 시스템 메모리 내에 로컬 메모리를 할당하는 예(instance)를 수용하기에 충분한 크기가 될 수 있다. 본 기술분야의 통상의 기술자는 메모리 및/또는 캐시에 할당된 로컬 메모리 영역이 각각의 연속적인 작업그룹에 대해 사용되기 전에 플러시되는 것이 요구될 수 있음을 이해할 것이다. 일부 실시예들에서, 메모리 및/또는 캐시에 할당된 로컬 메모리 영역은 전의 콘텐츠들을 오버라이팅함으로써 재사용될 수 있다.

GPU 프라이빗 메모리들(131, 132, 133, 134)과 같은 GPU 프라이빗 메모리는 각각의 프로세싱 소자들에 대해 전용(private)이다. GPU 환경에서 각각의 프라이빗 메모리는 한번에 단일의 작업아이템에 의해 사용된다. 그러므로, 로컬 메모리들과 유사하게, 프라이빗 메모리들은 시스템 메모리 내에 할당될 수 있고 연속적인 작업아이템들에 대해 재사용될 수 있다. 예를 들어, 시스템 메모리(103) 내의 프라이빗 메모리에 대한 단일 할당은, 동일한 CPU 코어에 의해 실행되는 연속적인 작업그룹들 내에서, 단일 작업그룹의 작업아이템들을 연속적으로 실행함으로써, 재사용될 수 있다. GPU 프라이빗 메모리, 및 그에 따른 GPU 프라이빗 메모리에 대응하는 시스템 메모리(103)에서의 할당은 일반적으로 커널 내부에 있는 그리고 각각의 작업아이템에 대해 로컬인 스택 변수들(stack variables that are internal to kernel)을 보유하기 위하여 사용된다.

상수 메모리(constant memory)는 코드의 실행 전반에 걸쳐 일정(constant)한 값들을 가지는 데이터를 포함한다. GPU 상에 실행되는 GPU 커널들에 대해, 상수 메모리는 그래픽 메모리(107) 및/또는 GPU 전역 캐시 메모리(110)에 있을 수 있다. 상수 메모리는, 일반적으로 판독 전용일 수 있고 작업그룹에 의존하지 않는다. 본 발명의 실시예들에서, 상수 메모리는 모든 CPU 코어들이 액세스할 수 있는 시스템 메모리 내의 영역에 매핑되는바, 이는 임의의 CPU 코어 상에서 실행되는 임의의 작업그룹 또는 작업아이템이 상수 메모리에 대한 액세스를 필요로 할 수 있기 때문이다. 또한, 주 메모리로부터 상수 메모리 할당이 각각의 CPU 코어의 캐시 메모리에서 복제(replication)되는 것이 바람직하다. GPU 메모리 계층을 CPU에 매핑하는 예시적인 레이아웃은 도 4에 도시된다.

단계(321)에서, GPU-커널은 코어들(141 및/또는 142)과 같은 하나 이상의 선택된 CPU 코어들 상에서 실행하도록 스케쥴링될 수 있다. 실행을 위한 GPU-커널을 스케쥴링하는 것은 선택된 CPU 코어들 상에 작업그룹들 및 작업아이템들의 매핑을 구현하기 위하여 OpenCL 런타임 시스템과 같은 실행 환경을 구성하는 것을 포함할 수 있다.

본 발명의 일 실시예에서, OpenCL 프레임워크는 이기종 컴퓨팅 시스템(100) 상에서 코드를 컴파일하고 실행하는데 사용되며, 단계(321)은 하나 이상의 커맨드들을 커맨드 큐에 큐잉하는 것을 포함할 수 있다. 예를 들어, 이기종 컴퓨팅 시스템(100)에서 OpenCL 프레임워크를 사용하여, GPU 커널이 하나 이상의 코어들(141) 및 멀티코어 CPU(101) 상에서 실행되도록 스케쥴링될 수 있다. 일반적으로, OpenCL 프레임워크를 사용하여 이기종 컴퓨팅 시스템(100) 상에서 애플리케이션을 실행하는데 있어서, 제어 부분은 GPU(102) 또는 코어들(141 또는 142)과 같은 시스템(100) 디바이스들에서 선택된 코드의 실행을 개시하는 호스트 상에서 작동(run)된다. 코어들(141 또는 142) 중 하나와 같은 CPU 코어가 호스트로서 기능할 수 있고, GPU 커널들을 실행될 시스템(100)의 디바이스들에 배포할 수 있다. 예를 들어, CPU 메모리에 매핑하기 위한 커맨드들, 그리고 GPU 커널을 실행하기 위한 커맨드들이 멀티-코어 CPU(101)에 대해 생성된 콘텍스트 내에 생성된 커맨트 큐 내에서 스케쥴링될 수 있다. OpenCL 런타임 환경은 시스템(100) 내의 특정 디바이스 내의 각각의 커맨드 큐에 기록된 커맨드들 각각을 실행한다.

멀티-코어 CPU(101) 상에서 실행하기 위한 GPU-커널을 스케쥴링하는데 있어서, 단계들(313-325)에서 결정된 매핑들 및 구성들을 강제하기 위한 명령들이 멀티-코어 CPU(101) 상에서 실행될 코드내에 삽입될 수 있다. 예를 들어, 작업그룹 내의 작업아이템들은 프로그래머에 의해 자동적으로 또는 수동적으로 삽입될 동기화 포인트를 요구할 수 있다.

멀티-코어 CPU(101) 상의 작업그룹 내에서 작업아이템 동기화를 구현하는데 있어서, 본 발명의 실시예들은 작업아이템들이 동기화 포인트까지 실행될 수 있게 할 수 있다. 예를 들어, 각각의 작업아이템이 하나씩 직렬 방식으로 동기화 포인트(예를 들어, barrier() 함수)까지 실행되고, 다음 작업아이템이 실행되기 전에 동기화 포인트에서 중단된다. 동기화 포인트를 가진 작업 그룹 내의 모든 작업아이템들이 동기화 포인트에 도달했을 때, 각각의 작업아이템은 상기 동기화 포인트로부터 작업아이템의 끝까지 직렬로 실행된다. 작업아이템 상태를 저장하기 위한 setjmp(), 및 그 작업아이템의 상태를 복구하기 위한 longjmp()와 같은 함수들이 코드 내에 삽입될 수 있다. 본 발명의 실시예들에서, 그러한 추가적인 코드는 GPU 커널들의 소스 코드내에 삽입되지 않는다. 오히려, 그러한 추가적인 코드는 GPU-커널들의 엔트리, 출구, 및/또는 장벽 루틴들에(GPU-커널 코드 내에는 아님) 삽입된다. GPU-커널들 자체의 소스 코드를 변경하지 않음으로써, 본 발명의 실시예들은 디버깅 수고를 덜어준다.

단계(323)에서, 실행될 추가적인 코드가 존재하는지 여부가 결정되고, 만약 그렇다면, 프로세스(300)가 단계(307)로 복귀된다. 더 이상의 코드가 실행되지 않을 것이라면, 프로세스(300)는 단계(325)에서 종료된다.

CPU에 매핑하는 예시적인 메모리

도 4는 시스템 메모리 내의 그리고 일 CPU 코어의 캐시 메모리 내의 예시적인 메모리 레이아웃을 도시한다. 도면부호(401)은, 예를 들어, 시스템 메모리(103) 내에서, 본래 GPU(102)와 같은 GPU 상에서 실행되도록 기록된 GPU-커널에 대응하는 메모리 할당들의 레이아웃을 도시한다. 도면부호(402)는 단일 CPU 코어의 캐시(예를 들어, CPU(101) 내의 캐시(109)) 내의 대응하는 메모리 레이아웃을 도시한다.

예를 들어, GPU(102)에서라면, 로컬 메모리(411, 421)는 로컬 메모리(114 및 115)에 각각 대응할 수 있다. 프라이빗 메모리들(412, 413, 422, 및 423)은 GPU(102)의 프라이빗 메모리들(131, 132, 133, 및 134)에 각각 대응할 수 있다. 상수 메모리(즉, 상수 파라미터들이 저장되는 메모리 영역). 도면부호(402)에 도시된 바와 같이, CPU 코어의 캐시는 일 로컬 메모리 블록, 작업그룹 내의 각각의 작업아이템에 대한 일 블록에 대응하는 일련의 프라이빗 메모리 블록들, 그리고 상수 메모리 영역을 가질 수 있다. 일부 실시예들에서, 시스템 메모리(103)에 대한 액세스와 관련된 지연들이 감소될 수 있게끔, 로컬 메모리, 프라이빗 메모리, 그리고 CPU 코어에 의한 프로세싱에 요구되는 상수 메모리 전부를 CPU 코어의 캐시에서 사용가능하도록 가지는 것이 특히 유익할 수 있다.

도면부호(401)에 도시된 바와 같이, 시스템 메모리의 연속적인 영역은, 그것이 GPU(102)의 로컬 메모리들(114, 115) 각각을 에뮬레이션하게끔, 각각의 로컬 메모리(411, 421)에 할당될 수 있다. GPU-커널 코드에 의해 액세스된 로컬 메모리 주소들은 이 할당 영역 내의 오프셋으로 변환될 수 있다. 시스템 메모리 내에 할당된 로컬 메모리의 전체 사이즈는 M*(작업그룹당 로컬 메모리 사이즈)일 수 있고, 여기서 M은 CPU 코어들의 수이다. 프라이빗 메모리의 총 사이즈는 M*N*(작업아이템당 프라이빗 메모리의 사이즈)일 수 있으며, 여기서 M은 코어들의 수이고 N은 작업그룹당 작업아이템들의 수이다.

추가된 디버깅 성능을 위해, 본 발명의 일부 실시예들은 시스템 메모리 내의 개별 메모리 할당들 사이에 가드 페이지들을 포함할 수 있다. 예를 들어, 가드 페이지들(441, 442, 443, 444, 445, 446)은, 동일한 쓰레드를 위해 상이한 메모리 할당들 사이에 삽입되는 것과 마찬가지로, 상이한 OS 쓰레드들을 위한 할당들 사이에 삽입될 수 있다. 일부 실시예들에서, 명령이 메모리의 가드 페이지 영역을 액세스하려 시도할 때마다 레지스터가 설정될 수 있다. 메모리 액세스의 빠른 검출은 다양한 병렬 쓰레드들이 실질적으로 병렬 방식으로 실행되는 애플리케이션들에서 특히 유용할 수 있다.

도 5는 본 발명의 실시예에 따라 단계(317)을 구현하는 프로세싱 단계들(501-523)을 도시한다. 단계(501)에서, 작업그룹 쓰레드들이 스케쥴링된다. 위에서 기술된 바와 같이, 본 발명의 실시예들은, 각각의 CPU 코어 상에 단일의 운영 시스템 쓰레드를 생성할 수 있으며, 상기 단일의 운영 시스템 쓰레드 내에서 복수의 사용자 레벨 쓰레드들이 스케쥴링 된다. 예를 들어, GPU-커널의 20개의 인스턴스들(1...20)이 스케쥴링될 것이라면, (작업아이템들 1..10과 같은) GPU-커널 쓰레드들(1..10)은, 코어(141), 및 (작업아이템들 11..20과 같은) GPU-커널 쓰레드들(11..20)이 코어(142)에 대해 스케쥴링될 수 있다. 작업아이템들(1..10) 및 (11..20)은 작업그룹 1 및 작업그룹 2 각각에 대해 수집될 수 있다. 위에서 공지된 바와 같이, 각각의 작업그룹은 OS 쓰레드들로서 구현되며, 따라서 일 OS 쓰레드가, 작업그룹들(1, 2)을 각각 실시하기 위하여, 코어들(141 및 142) 각각에 대해 생성될 수 있다.

단계(503)에서, GPU-커널이 다른 병렬 실행 GPU-커널들과의 동기화를 필요로하는지가 결정된다. 예를 들어, OpenCL 코드는 barrier() 함수에 대해 하나의 호출, 또는 호출들을 포함할 수 있다. 동기화를 위한 이러한 호출이 존재한다면, GPU-커널이 동기화를 필요로하는 것으로 결정되고, 그렇지 않다면, GPU-커널은 동기화를 필요로하지 않을 수 있다.

GPU-커널이 동기화를 필요로하지 않는 것으로 결정되면, GPU-커널은, 요구되는 수 인스턴스들에 따라 시작부터 끝까지 실행되도록 스케쥴링된다. 예를 들어, 단계(501)에서 생성된 OS 쓰레드들 각각에서, 소정 수의 GPU 커널들, 작업아이템들이 사용자 레벨 쓰레드로서 실행되도록 스케쥴링된다. 작업아이템들 사이에 동기화가 요구되지 않으므로, 각각의 작업아이템이 시작부터 끝까지 실행되도록 스케쥴링된다.

단계(505)에서, 작업아이템 사용자 쓰레드의 실행이 완료될 때, OpenCL 실행 프레임워크는, 예를 들어, 콜백 함수의 사용에 의해 통보(notify)될 수 있다. 단계(507)에서 작업아이템이 실행을 완료했을 때, 단계(509)에서 작업그룹 내의 다음 작업아이템이 사용자 레벨 쓰레드로서 실행을 위해 스케쥴될 수 있다. OpenCL 실행 프레임워크는 또한 작업아이템이 실행을 완료하였는지 결정하기 위하여 하나 이상의 상태 파라미터들을 주기적으로 쿼리할 수 있다. 작업그룹 내에서 스케쥴링될 작업아이템들이 더 남이있지 않다면, 작업그룹은 실행을 완료한다.

일부 실시예들에서, 하나 이상의 작업그룹이 하나씩 직렬로 실행되도록 각각의 CPU 코어에 스케쥴링될 수 있다. 단계(509)에서, 실행되는 작업그룹 내의 모든 작업아이템들이 실행을 완료하였음이 결정되면, 단계(511)에서 현재의 코어에서 실행될 다른 작업그룹들이 있는지가 결정된다. 현재의 CPU 코어 상에 스케쥴링될 작업그룹들이 더 있다면, 다음 작업그룹이 실행을 위해 스케쥴링된다. 또 다른 작업그룹을 스케쥴링하는 것은 현재의 CPU 코어 상에서 현재 실행하는 OS 쓰레드를 위한 메모리 할당을 다시 초기화(re-initialize)하는 것을 포함할 수 있다. 본 발명의 실시예들에서, 메모리 할당은, OS 쓰레드가 생성될 때 이루어질 수 있고, 일반적으로 그 OS 쓰레드에 할당된 각각의 작업그룹을 위한 재할당을 필요로하지 않는다.

단계(503)에서 동기화가 요구되는 것으로 결정되면, GPU-커널은 요구되는 수 인스턴스들에 따라 시작부터 다음 동기화 포인트(예를 들어, barrier() 호출)까지 실행되도록 스케쥴링된다. 예를 들어, 단계(513)에서, 작업아이템의 사용자-레벨 쓰레드는 시작부터 다음 발생 콜로 그리고 barrier()로 실행되도록 스케쥴링된다. barrier()에 대한 호출을 만나게될 때, 실행 쓰레드의 상태가 저장(save)될 수 있다. 일 실시예에서, 사용자-레벨 쓰레드의 상태를 저장(save)하기 위하여 setjmp()와 같은 함수 호출이 사용될 수 있다. 저장된 쓰레드의 상태는, 스택 포인터, 프레임 포인터, 및 프로그램 카운터와 같은 레지스터들의 콘텐츠들을 포함할 수 있다. 각각의 작업아이템 사용자-레벨 쓰레드의 상태가 시스템 메모리(103)와 같은 시스템 메모리의 영역 또는 영구 메모리(104)와 같은 영구 메모리에 저장될 수 있다.

단계(515)에서, 실행 작업아이템 쓰레드가 동기화 포인트에 도달하면, 단계(517)에서, 더 많은 작업아이템들이 현재의 작업그룹 내에 스케쥴링될 것인지가 결정된다. 단계(515)에서, 작업아이템 사용자-레벨 쓰레드의 실행이 동기화 포인트에 도달할 때, OpenCL 실행 프레임워크가 예를 들어, 콜백 함수를 사용하여 통보될 수 있다. 단계(515)에서 작업아이템이 동기화 포인트에 도달했음이 통보될 때, 예를 들어, 콜백 함수를 사용하여, OpenCL 실행 프레임워크가 통보될 수 있다. 단계(515)에서 작업아이템이 동기화 포인트에 도달했을 때, 작업그룹 내의 다음 작업아이템은 단계(517)에서 사용자 레벨 쓰레드로서 실행을 위해 스케쥴링될 수 있다. OpenCL 실행 프레임워크는 또한 작업아이템이 동기화 포인트에 도달했는지 결정하기 위하여 하나 이상의 상태 파라미터들을 주기적으로 쿼리할 수 있다. 작업그룹 내에서 스케쥴링될 작업아이템들이 더 이상 남아있지 않을 때, 작업그룹은 각각의 작업아이템을 동기화 포인트까지 실행하는 것을 완료하였다.

단계(519)에서, 작업아이템들은 쓰레드 실행 끝에 도달하기 전에 더 많은 동기화 포인트들을 가지도록 결정되고, 단계들(513-525)은 각각의 작업아이템에 대해현재의 동기화 포인트로부터 다음 동기화 포인트까지 실행하도록 반복된다.

단계(519)에서, 작업그룹 내의 작업아이템들이 더 이상 동기화 포인트들을 가지지 않는다면, 단계(521)에서, 동기화 포인트에 도달한 하나의 작업아이템 또는 작업아이템들이 그 포인트로부터 끝까지 실행되도록 스케쥴링된다. 동기화 포인트로부터 끝까지 실행하도록 작업아이템 쓰레드를 스케쥴링하는 것은 쓰레드의 상태를 복구하는 것을 포함할 수 있다. 일 실시예에서, longjmp()와 같은 함수 호출이, setjmp()를 사용하여 전에 저장되었던 쓰레드의 상태를 복구하기 위하여 사용될 수 있다. setjmp()와 longjmp()는 프로세스 또는 쓰레드의 상태의 저장 및 복구를 각각 편리하게 나타내는 함수 이름이다.

단계(523)에서, 실행 작업아이템 쓰레드가 실행을 완료하였는지가 결정된다. 단계(507)과 관련하여 설명된 바와 같이, 작업아이템 쓰레드가 실행을 완료하였는지를 결정하는 것은 콜백 함수 또는 주기적인 쿼리에 근거할 수 있다. 작업아이템이 실행을 완료하였다면, 단계(523)에서, 최종적으로 겪은(last encountered) 동기화 포인트로부터 끝까지 더 많은 작업아이템 쓰레드들이 실행될것인지 여부가 결정된다. 만약 그렇다면, 다음 작업아이템이 스케쥴링되고 실행될 각각의 작업아이템에 대해 단계들(521-525)이 반복된다.

작업그룹의 작업아이템 쓰레드들이 모두 실행 완료되면, 단계(527)에서, 현재 선택된 CPU 코어상에서 다른 작업그룹들이 스케쥴링되는지가 결정된다. 만약 다른 작업그룹들이 스케쥴링 되면, 단계들(513-527)은 다른 작업그룹들 각각에 대해 반복된다.

도 6은 작업아이템 쓰레드 실행을 그래픽적으로 도시한다. 단계(601)에서, 작업아이템 쓰레드들(Wi₀ ... Wi_n-1)은 작업그룹의 모든 작업아이템들이 시작부터 끝까지 실행될 때까지 하나씩 실행된다. 단계(601)는 동기화가 요구되지 않는 경우를 도시한다. 단계(602)에서, 작업아이템 쓰레드들(Wi0 ... Win-1)은 작업그룹의 모든 작업아이템들이 시작부터 제1 동기화 포인트(여기에서는 barrier()에 대한 호출로 표시됨)까지 실행될때까지 차례로 실행된다. 작업그룹의 모든 작업아이템들이 시작부터 barrier()까지 실행된 후, 이 작업아이템들 각각이 동기화 포인트로부터 끝까지, 차례로 실행된다.

결론

본 명세서의 개요 및 요약 부분은 당업자(들)에 의해 고려되는 바와 같이 본 발명의 하나 이상의 예시적인 실시예들(그러나, 예시적인 실시예들 전체는 아님)을 기술하며, 따라서, 어떠한 방식으로든 본 발명 및 첨부된 청구항들을 제한하려 의도된 것이 아니다.

본 발명은 특정 기능들 및 그것들 간의 관계에 대한 구현을 도시하는 기능적 빌딩 블록을 사용하여 설명되었다. 이 기능적 빌딩 블록들의 경계들은 여기에서 설명의 편이를 위해 임의로 정의된 것이다. 특정 함수들 및 그것들의 관계들이 적절하게 수행되는한 대안적인 경계들이 정의될 수 있다.

구체적인 실시예들에 대한 위의 설명은, 본 발명의 일반적인 개념으로부터 벗어남이 없이 과도한 실험 없이도 본 기술 분야의 지식을 적용함으로써 이러한 구체적인 실시예들을 다양한 애플리케이션들에 대해 쉽게 수정 및/또는 적용할 수 있는 본 발명의 일반적인 특징을 완전히 드러낼 것이다. 그러므로, 그러한 적용 및 수정은 제시된 내용 및 안내에 근거하여, 개시된 실시예들의 등가의 범위 및 의미 내에 있도록 의도된 것이다. 여기에서의 어법 또는 용어는 설명을 위한 것이고 제한적인 것이 아니며, 본 명세서의 어법 또는 용어는 당업자에 의해 본 내용에 비추어 해석될 것이다.

본 발명의 범주 및 폭이 위에서 설명된 예시적인 실시예들 중 임의의 것에 의해 제한되어서는 안되며, 봄 발명의 범주 및 폭은 하기의 청구항들 및 그것들의 등가에 의해서만 정의되어야 한다.

Claims

프로세서 코어 상에서 프로세싱 로직의 복수의 데이터-병렬 쓰레드들(data-parallel threads)을 실행하는 방법으로서,
(a) 상기 복수의 데이터-병렬 쓰레드들을 하나 이상의 작업그룹들(workgroups)로 그룹화하는 단계와;
(b) 상기 하나 이상의 작업그룹들(workgroups)로부터의 제1 작업그룹을 상기 프로세서 코어 상에서 실행하도록 된 운영 시스템 쓰레드와 관련(association)시키는 단계와;
(c) 상기 제1 작업그룹으로부터의 쓰레드들을 상기 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 구성(configure)하는 단계를 포함하는 것을 특징으로 하는 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제1 항에 있어서, 상기 (c) 단계는,
상기 제1 작업그룹으로부터의 쓰레드들을 하나 이상의 쓰레드들의 하나 이상의 서브세트들로 그룹화하는 단계와;
상기 하나 이상의 서브세트들로부터의 제1 서브세트를 실행하도록 구성하는 단계와; 그리고
상기 제1 서브세트의 실행을 완료한 후, 상기 하나 이상의 서브세트들로부터의 제2 서브세트를 실행하도록 구성하는 단계를 포함하는 것을 특징으로 하는 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제1 항에 있어서, 상기 (a) 단계는,
프로세서 상에서 상기 프로세싱 로직을 실행하는기 위해 사용가능한 프로세서 코어들의 수를 결정하는 단계와, 여기서 상기 프로세서는 상기 프로세서 코어를 포함하고; 그리고
하나 이상의 프로세서 코어들에 대해 다수의 작업그룹들을 형성하는 단계를 포함하며, 여기서 상기 작업그룹들의 수는 상기 프로세서 코어들의 수에 근거한 것을 특징으로 하는 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제1 항에 있어서,
상기 하나 이상의 작업그룹들로부터의 제2 작업그룹을 제2 프로세서 코어 상의 제2 운영 시스템 쓰레드와 관련시키는 단계와; 그리고
상기 제2 작업그룹으로부터의 쓰레드들을 상기 제2 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 구성하는 단계를 더 포함하며,
여기서 상기 제1 및 제2 작업그룹들은 실질적으로 동시에 실행되도록 된 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제1 항에 있어서, 상기 (c) 단계는,
상기 제1 작업그룹으로부터의 쓰레드들에 대해 동기화 포인트를 정의하는 단계와;
상기 제1 작업그룹으로부터의 상기 쓰레드들 각각을 상기 동기화 포인트까지만 실행하도록 구성하는 단계와;
상기 쓰레드들 모두가 상기 동기화 포인트에 도달한 후, 상기 제1 작업그룹으로부터의 상기 쓰레드들 각각을 상기 동기화 포인트로부터 실행 재개(restart)하도록 구성하는 단계를 포함하는 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제5 항에 있어서, 상기 (c) 단계는,
상기 동기화 포인트에 도달한 후 상기 제1 작업그룹으로부터의 상기 쓰레드들 각각에 대한 상태를 저장하는 단계와; 그리고
상기 실행 재개 전에 상기 제1 작업그룹으로부터의 상기 쓰레드들 각각에 대항 상태를 복구(restore)하는 단계를 더 포함하는 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제5 항에 있어서,
상기 제1 작업그룹으로부터의 쓰레드들에 대해 동기화 포인트를 정의하는 단계는,
상기 제1 작업그룹으로부터의 상기 쓰레드들에 대한 코드 내에 동기화 호출(synchronization call)을 삽입하는 단계를 포함하는 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제1 항에 있어서,
상기 프로세싱 코어는 제어 프로세싱 유닛(CPU) 코어인것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제1 항에 있어서,
상기 프로세싱 로직은 그래픽 프로세싱 유닛(GPU) 커널인것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제1 항에 있어서,
(d) 제2 프로세서와 관련된 메모리 계층을 상기 프로세서 코어와 관련된 메모리에 매핑하는 단계를 더 포함하는 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제10 항에 있어서, 상기 매핑하는 단계는,
상기 프로세서 코어에 결합된 시스템 메모리 내에 복수의 제1 영역들을 할당하는 단계와, 여기서 상기 제1 영역들 각각은 상기 제1 작업그룹으로부터의 일 쓰레드에 의해 액세스가능한 프라이빗 메모리에 대응하며; 그리고
상기 프로세서 코어에 결합된 시스템 메모리 내에 복수의 제2 영역들을 할당하는 단계를 포함하고, 여기서 상기 제2 영역들 각각은 상기 제1 작업그룹으로부터의 모든 쓰레드들과 관련된 로컬 메모리에 대응하는 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제11 항에 있어서, 상기 매핑하는 단계는,
상기 복수의 제1 영역들로부터의 제1 영역들의 각각의 쌍 사이에 가드 페이지들(guard pages)을 할당하는 단계와; 그리고
상기 복수의 제2 영역들로부터의 제2 영역들의 각각의 쌍 사이에 가드 페이지들을 할당하는 단계를 더 포함하는 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
제11 항에 있어서, 상기 매핑하는 단계는,
상기 프로세서 코어에 결합된 캐시 메모리 내에 캐시 영역을 형성하는 단계를 더 포함하며, 여기서 상기 캐시 영역은 상기 제1 영역들 및 제2 영역 중 적어도 하나의 내용(contents)을 포함하는 것을 특징으로 하는 복수의 데이터-병렬 쓰레드들을 실행하는 방법.
그래픽 프로세싱 유닛(GPU) 커널을 실행하는 방법으로서,
상기 GPU-커널을 포함하는 애플리케이션을 호스트 프로세서에 로딩(loading)하는 단계와, 여기서 상기 GPU-커널은 GPU 상에서의 실행을 위하여 사전에(previously) 구성(configuration)되었으며, 그리고 상기 GPU-커널은 상기 GPU 상에서 복수의 데이터-병렬 쓰레드들(data-parallel threads)을 인스턴스화(instantiate)하도록 되어있고;
하나 이상의 작업그룹들을 형성하는 단계와, 여기서 각각의 작업그룹은 복수의 상기 데이터-병렬 쓰레드들을 포함하며;
상기 하나 이상의 작업그룹들을 상기 포스트 프로세서에 결합된 하나 이상의 프로세서 코어들의 운영 시스템 쓰레드들과 관련(association)시키는 단계를 포함하며, 여기서 상기 작업그룹들 각각은 상기 운영 시스템 쓰레드들 중 단 하나와 관련되고, 그리고 여기서 상기 운영 시스템 쓰레드들 각각은 상기 프로세서 코어들 중 하나만을 실행하도록 되어있고; 그리고
상기 작업그룹들 각각의 데이터-병렬 쓰레드들을 각각의 관련된 운영 시스템 쓰레드 내에서 사용자-레벨 쓰레드들로서 구성하는 단계를 포함하는 것을 특징으로 하는 그래픽 프로세싱 유닛(GPU) 커널을 실행하는 방법.
제14 항에 있어서,
상기 GPU에 결합된 메모리 계층으로부터의 하나 이상의 할당들(allocations)을 상기 하나 이상의 프로세서 코어들에 결합된 시스템 메모리에 매핑하는 단계를 더 포함하는 것을 특징으로 하는 그래픽 프로세싱 유닛(GPU) 커널을 실행하는 방법.
프로세서 코어 상에서 프로세싱 로직의 복수의 데이터-병렬 쓰레드들을 실행하기 위한 시스템으로서,
상기 프로세서 코어를 포함하는 적어도 하나의 프로세서와;
상기 프로세서 코어에 결합된 적어도 하나의 메모리와;
상기 적어도 하나의 메모리 및 상기 적어도 하나의 프로세서에 결합된 그래픽 프로세싱 유닛(GPU) 커널 스케쥴러를 포함하며, 상기 그래픽 프로세싱 유닛 커널 스케쥴러는,
상기 복수의 데이터-병렬 쓰레드들을 하나 이상의 작업그룹들로 그룹화하고;
상기 하나 이상의 작업그룹들로부터의 제1 작업그룹을 상기 프로세서 코어 상의 운영 시스템 쓰레드와 관련시키고; 그리고
상기 제1 작업그룹으로부터의 쓰레드들을 상기 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 실행하도록 된 것을 특징으로 하는 시스템.
제16 항에 있어서, 상기 그래픽 프로세싱 유닛 커널 스케쥴러는 또한,
상기 제1 작업그룹으로부터의 쓰레드들을 하나 이상의 쓰레드들의 하나 이상의 서브세트들로 그룹화하고;
상기 하나 이상의 서브세트들로부터의 제1 서브세트를 실행하도록 구성하고; 그리고
상기 제1 서브세트가 실행 완료된 후 상기 하나 이상의 서브세트들로부터의 제2 서브세트를 실행하도록 구성하는 것을 특징으로 하는 시스템.
제16 항에 있어서, 상기 그래픽 프로세싱 유닛 커널 스케쥴러는 또한,
상기 프로세서 코어와 관련된 메모리에 제2 프로세서와 관련된 메모리 계층을 매핑하도록 된 것을 특징으로 하는 시스템.
컴퓨터 프로그램 로직이 기록된 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품(tantible computer program product)으로서, 상기 컴퓨터 프로그램 로직이 기록된 컴퓨터 판독가능 매체는, 적어도 하나의 프로세서로 하여금,
복수의 데이터-병렬 쓰레드들을 하나 이상의 작업그룹들로 그룹화하고;
상기 하나 이상의 작업그룹들로부터의 제1 작업그룹을 적어도 하나의 프로세서 코어 상의 운영 시스템 쓰레드와 관련시키고; 그리고
상기 제1 작업그룹으로부터의 쓰레드들을 상기 운영 시스템 쓰레드 내의 사용자-레벨 쓰레드들로서 실행하게 하는 것을 특징으로 하는 컴퓨터 프로그램 제품.
제19 항에 있어서, 상기 컴퓨터 프로그램 로직이 기록된 컴퓨터 판독가능 매체는 또한 적어도 하나의 프로세서로 하여금,
상기 제1 작업그룹으로부터의 쓰레드들을 하나 이상의 쓰레드들의 하나 이상의 서브세트들로 그룹화하고;
상기 하나 이상의 서브세트들로부터의 제1 서브세트를 실행하도록 구성하고; 그리고
상기 제1 서브세트가 실행을 완료한 후 상기 하나 이상의 서브세트들로부터의 제2 서브세트를 실행하도록 구성하게 하는 것을 특징으로 하는 컴퓨터 프로그램 제품.