●OpenCL의 실장 테스트의 스타트는5월

　온 세상의 게임 개발자가 모이는 컨퍼런스 「GDC (Game Developers Conference)」(으)로Khronos Group(은)는, 헤테로지니아스인 병렬 컴퓨팅을 위한 프로그램 언어인 「OpenCL」의 오버뷰의 세션을 행했다.

　OpenCL(은)는,NVIDIA의 「C for CUDA (OpenCL도CUDA의 런타임에 떨어뜨리기 위해, 종래의 확장C(을)를 베이스로 했다CUDA하C for CUDA(이)라고 부르게 되었다)」(와)과 같이,GPU(을)를 범용 컴퓨팅에 사용할 수 있는 프로그램 언어다.그러나,NVIDIA독자적인C for CUDA과는 달리, 크로스 플랫폼의 programming environment 가 되고 있다.OpenCL그럼,NVIDIA(이)나AMD(ATI)의GPU뿐만이 아니고, 멀티 코어CPU(이)나Cell Broadband Engine(Cell B.E.)그렇다고 한 다양한 프로세서(Larrabee도 포함된다고 추측된다)(을)를 커버한다.최대의 특징은,GPU형태의 데이터 병렬 모델에 대응한 것이지만, 동시에 멀티 코어CPU등의 태스크 병렬 모델도 서포트한다.

　이번 세션에서는, 우선Khronos(은)는,OpenCL의 도로지도의 업데이트를 행해,OpenCL의 실장의 열쇠가 되는 「콘포만스테스트」의 릴리스가 당초 예정의2달부터5달에 어긋난 것을 명확하게 했다.

　OpenCL(을)를 서포트하는 각 벤더는,Khronos(으)로부터 릴리스 되는 콘포만스테스트를 베이스로 테스트를 행하고, 실장을 완성시켜 가게 된다.그 때문에,OpenCL하지만 각 디바이스로 달리도록(듯이) 실장이 완성하는 것은, 콘포만스테스트의 릴리스로부터 당분간 후가 된다.말해 보면, 콘포만스테스트는, 스타트의 스타트이며,Khronos그럼 향후12개월간의 사이에 각사로부터의 실장이 등장한다고 예측하고 있다.

　GDC의 세션으로의 기본적인 내용은,Khronos하지만 작년(2008년)12달의SIGGRAPH Asia(으)로의OpenCL의 스펙 발표시에 행한 내용과 그만큼 다르지 않다.초기의 실장 후로의 데모로서는,EA에 의한 옷감 시뮬레이션이 공개되었다.이 데모는,NVIDIA의GPU(와)과AMD(구ATI)의GPU, 그리고AMD의 멀티 코어CPU각각의 위에서 달리고 있었다.

　드디어 초읽기 상태에 들어갔다OpenCL하지만, 이것으로, 크로스 플랫폼의GPU(이)나 고throughputCPU향해 범용 어플리케이션을 자꾸자꾸 쓸 수 있게 되는가 하면, 그렇게 간단한 이야기도 아니다.그것은,OpenCL의 성격이,C for CUDA등과는 꽤 다르기 때문이다.

　통상, 크로스 플랫폼의 휴대용인프로그래밍 모델을 구축하려고 하면, 컴파일러나 두꺼운 추상 층으로, 하드웨어의 차이가 안보이게 커버한다.로 레벨의 하드웨어에는 모두 손대게 한 하지 않고서, 추상화 하는 것이 일반적인 수법이다.그에 대하고,OpenCL의 어프로치는, 반대로 하드웨어의 차이를 프로그래머로부터 보이도록(듯이) 한다.OpenCL(은)는, 본질적으로는 로 레벨의 하드웨어API적인 성격을 가지고 있다.

　예를 들면,OpenCL그럼, 같다GPU그렇지만, 타겟의 하드의 콘퓨트코아의 수로부터 워크그룹의 사이즈의 상한, 메모리 계층의 종류나 양 등, 상세한 특성의 차이의 정보를 얻을 수 있다.메모리 계층이나 워크그룹은 언어속에서 모델화 되고 있기 때문에, 하드의 특성에 맞출 수 있다.

　그 때문에,OpenCL그럼, 특정의 플랫폼에 고리고리에 최적화한 코드를 쓸 수 있다.이것은, 크로스 플랫폼의 휴대용인 코드라고 하는 이념과는 반하는 것처럼 보이지만, portability는 프로그래머가 맡길 수 있다.이 근처의 어프로치는OpenGL(와)과 닮아 다닌 곳(점)이 있다.

　이러한 특성도 있고,OpenCL하C for CUDA(와)과 비교와 추상화의 정도가 얇다.코딩 하려고 하면,C for CUDA보다 코드가 번잡하게 된다.이 차이는,OpenCL(와)과C for CUDA그럼 목표로 하고 있는 곳(중)이 다르기 (위해)때문이다.

　OpenCL의 모델에서는, 하드웨어를 두껍게 추상화 하는 미들웨어는,OpenCL의 위에 구축된다.OpenCL(은)는 그러한 미들웨어를 쓰기 쉽게, 극력 로 레벨 액세스가 가능한 것 같게 만들어져 있다.즉, 어느 쪽일까하고 말하면, 미들웨어의 토대가 되지만OpenCL그렇다고 하는 위치설정이다.이것은, 보다 높은 레벨의 언어로 어플리케이션을 쓰는 것을 주안으로 했다C for CUDA(으)로 자리매김해가 어긋나 있다.

　이러한 성격으로부터,OpenCL(은)는 폭넓게 사용되기 위해서는,OpenCL의 위에서의 미들웨어나 툴이 충실하는 것이 필요하다.OpenCL(은)는, 그것 단체로 충족 하는 programming environment 라고 하는 것보다 오히려, 미들웨어등의 발판으로서 새로운프로그래밍 체제의 기초가 되는 부분이다.

　미들웨어 측에 해 보면, 일단OpenCL에 떨어뜨리면, 일단, 크로스 플랫폼에서 디바이스를 선택하지 않고 달리게 할 수 있다.게다가, 각 타겟 디바이스에 최적화시키고, 퍼포먼스를 꺼낼 수 있다.그것을 위한 환경을 통일적으로 정돈한 것이,OpenCL의 큰 포인트다.또, 이 수법에서는, 컴파일러나 런타임의 부담을 가볍게 할 수 있기 위해, 현재 상태로서는 현실적이라고 말할 수 있을지도 모른다.

OpenCL의 플랫폼 모델



커넬 실행

　GDC(으)로의OpenCL의 세션에는,AMD에서는, 원스탠포드 대학의Stanford Graphics Lab의 연구자였다Mike Houston(마이크·휴스턴)씨가 등장했다.Houston씨는, 스탠포드 대학의 스트림 프로그램 언어 「Brook」의 개발 팀의 주요 스탭의1사람이었다.그 당시의 동료였다Ian Buck씨는,NVIDIA그리고CUDA개발의 리더가 되었다.

　즉,NVIDIA중(안)에서CUDA의 리더에 상당하는 경력의 인물이,AMD그리고OpenCL(을)를 담당하고 있다(AMD하BROOK+도 서포트한다).덧붙여서,OpenCL그리고 받아들여진 프로세서의 메모리 계층의 모델화는,Houston씨가 연구하고 있던 「Sequoia (세코이아)」프로젝트에 가깝다(Houston씨도OpenCL책정에 참가하고 있다).GDC그럼,Houston씨 외에도,AMD GPU의 로 레벨 소프트웨어의 부대의 스탭이 집결하고 있어,AMD하지만OpenCL(을)를 매우 중시하고 있는 것이 방문했다.

　AMD하지만OpenCL(을)를 중시하는 것은, 이것이AMD에 있어서의GPU의 범용 이용의 열쇠를 잡는프로그래밍 모델이 된다고 생각하고 있기 때문이다.AMD에 있어서GPU의 범용 이용이 매우 중요해요는, 동사가2011해 이후에는,CPU에GPU코어를 비롯한 다양한 엔진을 통합할 계획으로 있기 때문이다.그 모델을 성공시키려면 , 견고한프로그래밍 모델을 확립할 필요가 있다.

　AMD하지만NVIDIA에GPU의 범용 이용의 분야에서 열세한 것은,NVIDIA하지만GPU하드웨어 뿐만이 아니라프로그래밍 체제도 포괄적으로 제공하고 있던 것에 대하고,AMD(은)는 매우 볼품없는 환경 밖에 제공 되어 있지 않았기 때문에다.구ATI Technologies(은)는,GPU의 범용 이용을 위한프로그래밍 체제의 구축으로NVIDIA에 늦어를 취했다.그리고,ATI하지만AMD(와)과 합병한 후의 혼란으로, 한층 더 지연이 축적되어NVIDIA에 대해서 완전하게 주회 지연이 되었다.

　그러나,OpenCL(은)는, 이 상황을 뒤집을 수 있다.어느 하드 위라도 달린다OpenCL의 원에서는, 입장상은 모든 프로세서 벤더가 같은 스타트 라인에 오기 때문이다.지금까지는,GPU하드의 성능이 아니고,프로그래밍 체제 포함의 환경에서 비교되고 있었다.그러나,OpenCL이후는, 같은프로그래밍 체제아래에서, 하드웨어의 우열(엄밀하게 말하면 런타임과 드라이버의 우열도 반영된다)그리고 비교되게 된다.

　GPU(으)로의 범용 컴퓨팅이OpenCL그리고 리셋트가 되고, 여기로부터 스타트한다면,AMD(은)는 원리적으로는 불리 없고NVIDIA(와)과 싸울 수 있게 된다.또, 같은프로그래밍 모델아래에서, 내부 아키텍쳐가 다른 프로세서를 만들어 겨룬다고 하는 스타일은,x86 CPU메이커이다AMD에 있어서 친숙해 지기 쉽다.

●OpenCL(와)과 자사판C(을)를CUDA플랫폼상에서 공존시킨다NVIDIA

　그럼,OpenCL하C for CUDA그리고 선행한다NVIDIA에 있어서, 귀찮은 흰색 물건일까하고 말하면, 의외로 그렇지도 않다.우선,OpenCL그리고GPU위에서의 범용 컴퓨팅 자체가 퍼진다면,GPU벤더이다NVIDIA에 있어서도리는 크다.

　또, 현상의C for CUDA(와)과OpenCL그럼, 자리 매김이 어긋난다.OpenCL하지만 미들웨어의 토대로서의 색채가 진한 로 레벨API인데 대하고,C for CUDA(분)편이 추상화의 정도가 높게 어플리케이션을 쓰기 쉽다(최적화는 놓아두면).그 때문에, 당면은 거주지 분리가 생긴다.

　게다가C for CUDA(으)로의NVIDIA의 리드도 그 나름대로 산다.OpenCL에서 만나도C에서 만나도,CUDA아키텍쳐상으로는 같은 중간 코드(PTX)에 일단 떨어뜨려져 같다CUDA런타임으로 달린다.런타임과 그 중의 리얼타임 컴파일러의 기술적인 축적은 그대로 산다.

　또,C for CUDA(으)로의NVIDIA GPU(으)로의 최적화의 기법도OpenCL(으)로의 코딩에 반영할 수 있다.실제,C for CUDA(와)과OpenCL(은)는, 기본적인 어프로치는 닮고 있어 같다NVIDIA하드웨어에 대한 최적화의 어프로치는,C for CUDA그렇지만OpenCL그렇지만 닮은 것이 될 것이다.또,NVIDIA(은)는,C for CUDA위의 라이브러리에서조차,OpenCL옆으로부터 액세스 할 수 있게 될지도 모른다고 한다.

　같은프로그래밍 모델아래에서, 순수하게GPU(으)로의 범용 어플리케이션의 성능으로 승부할 수 있는 일도NVIDIA에 있어서 이점이다.지금까지는, 같은 어플리케이션의 같은 코드가 달리는 것은 아니기 때문에, 범용 컴퓨팅의 성능의 비교가 어려웠다.그러나, 지금부터는 같은 코드의 실행 성능을 겨룰 수 있다.NVIDIA(은)는,AMD보다 범용 어플리케이션에의 최적화에 자원을 할애해 왔다.같은 코드가 달린다면, 그 우위성이 성능차이로서 겉(표)에 나타날 가능성이 있다.

　실제,GDC의OpenCL의 세션에서도,NVIDIA하AMD(와)과 교체로 사양의 설명을 행해, 적극적으로 관련되고 있는 것을 나타냈다.또,OpenCL의SIGGRAPH Asia(으)로의 발표에서는,NVIDIA자른GPGPU의 선교자Mark Harris씨가 등장하고 발표를 행했다.NVIDIA의 전략은,C for CUDA(으)로의 리드를 살리면서,OpenCL도 기르고, 양쪽 모두의 중개를 잘 한다고 하는 근처일 것이다.

　OpenCL하지만 당분간 경합 하는 것은DirectX Compute Shader(이)다.똑같이 멀티 플랫폼의 병렬 프로그램 언어이며,GPU(을)를 종래의 그래픽스 파이프라인의 밖에서 사용하는 것을 주목적으로 두고 있기 때문이다.GDC그렇지만,DirectX Compute Shader(을)를 사용해NVIDIA(와)과AMD쌍방의GPU그리고 같은 데모가 달리는 곳(중)이 실연되었다.

　그러나,OpenCL(와)과DirectX Compute Shader(은)는, 외관은 경합 하지만, 보다 앞까지 전망했을 때의 목적이 크게 다르다.DirectX Compute Shader(은)는, 어느 쪽일까하고 말하면, 그래픽스 처리와의 편성으로, 포스트프로세싱등을 행하는 것을 메인의 타겟으로 하고 있다.DirectX Compute Shader도, 그래픽스와 얽히게 할 수 없는 사용법은 물론 할 수 있다.그러나, 발상의 원점으로서는, 그래픽스API(으)로부터,GPU의 범용적인 이용으로 달리기 시작한 것이DirectX Compute Shader(이)다.

　그에 대하고,OpenCL(은)는, 포괄적인 헤테로지니아스인 병렬 programming environment 를 확립하는 것을 최대의 목적으로 하고 있다.OpenGL등 그래픽스API(와)과의 인타오페라비리티도 취하지만, 게임등에서 그래픽스와 얽히게 할 수 있었던 사용법은, 응용의 일부에 지나지 않는다.보다 폭넓은 분야에서 범용적으로 사용되는프로그래밍 플랫폼을 목표로 하고 있다.그 비전 중(안)에서는, 그래픽스API이다OpenGL(을)를 최종적으로는OpenCL의 라이브러리로 해 버리는 것조차 전망하고 있다.GPU등의 범용적인 이용이 제일에 있는 것이OpenCL(이)다.

　OpenCL의 이러한 성격은, 이 규격을 말하기 시작한 것이Apple인 일도 관계하고 있다.Apple하GPU의 컴퓨팅 퍼포먼스를 범용에 사용하고 싶기 위해(때문에)OpenCL(을)를 제안했다.OpenCL의 경우는 출자가, 그래픽스나 게임사이드가 아니고, 콘퓨팅사이드였다.

　그렇다고는 해도,GDC(은)는 게임 개발의 무대이며, 그곳에서는DirectX Compute Shader(와)과OpenCL(은)는 정면으로부터 경합 한다.그리고,DirectX(은)는 사실상PC(와)과Xbox 360게임의 표준적이고,Khronos(은)는 약간 불리한 입장에 있다.편입계는 차치하고,PC(이)나 게임 콘솔로의 게임 시장에서는Khronos(은)는 열세하다.OpenGL ES 2.0도PLAYSTATION 3(PS3)의 그래픽스API의 결정타가 될 것이었던 것이, 침투 되어 있지 않다.무엇보다,OpenCL하지만 정말로 경합 하는 것은,Microsoft내부의DirectX부대가 아니고,Microsoft의 언어 부대(분)편에 될 것이다.

●Cell B.E.의 눈에 띄지 않다OpenCL

　장소는 게임 개발자가 모이는 컨퍼런스로, 테마는 병렬 프로그램 언어인 것에도 불구하고,GDC(으)로의OpenCL의 세션에는 빠져 있는 멤버가 있었다.그것은,Cell B.E.진영의 모습이다.

　OpenCL(은)는,Cell B.E.에 있어서도, 잘 사용할 수 있으면 programming environment 의 폭을 펼치는 토대가 될 수 있다.디벨로퍼는, 같다OpenCL그리고,GPU(와)과Cell B.E.(한층 더 더한다면 멀티 코어CPU)그리고 공통하러 달리게 하는 코드를 쓸 수 있기 때문이다.그리고,GPU(와)과Cell B.E.(을)를 횡단하는 미들웨어도 만들 수 있다.Cell B.E.에 있어서도 이익이 있는 것처럼 보인다.

　그러나, 현재Cell B.E.진영이OpenCL그리고 활발하게 활동하고 있는 형적은 안보인다.OpenCL의 스펙의 초판의 콘트리뷰타의 리스트를 봐도, 눈에 띄는 것은AMD(와)과NVIDIA의GPU벤더(양사 모두 키퍼슨의 이름이 있다)라고CPU(을)를 안는다Intel, 말해 내밀기이다Apple등.SCE에서는,PS3의 패러렐 컴퓨팅 모델의 소프트웨어 개발자이다John Bates씨의 이름 밖에 들어가 있지 않았다(IBM의Cell B.E.관계자는 여러명 들어가 있다).SCE하지만OpenCL에 향후 어떻게 임해 가는지, 아직 불선명하다.

　덧붙여서, 콘트리뷰타의 리스트의Intel의 이름도 흥미롭다.Larrabee의 그래픽스측의 아키텍트이다Larry Seiler씨나,Intel하지만Larrabee(을)를 위해서 매수했다고 말해진다Neoptica(GPU향해의 범용프로그래밍 모델을 개발하고 있었다)출신의 개발자의 이름이 늘어서 있다.Intel하지만OpenCL(을)를Larrabee그리고 달리게 할 생각이 만만한 (일)것은, 이 리스트로부터 전해져 온다.Intel하GDC마지막 날에,Larrabee의 명령 세트를 발표할 예정이다.