OpenCL

{{{+3 {{{#ffffff Open Computing Language}}}}}} [1]

1. 개요

2. 배경

3. 특징

#!syntax cpp
kernel void
arrAdd(global const int *src1, global const int *src2, global int *dest)
{
  const uint index = get_global_id(0);
  dest[index]      = src1[index] + src2[index];
  return;
}

4. 역사

5. 단점

• 2.0 미만 버전에서는 OpenCL은 호환성 확보를 위해 Online Compile 이라는 방법을 사용하는데 소스 코드를 불러와 그걸을 즉석에서 컴파일하여 바이너리를 만드는 방식이다. 문제는 이런 방식으로는 소스 코드 공개를 막을 방법이 없다. 소스코드를 난독화하더라도(암호화, 압축 등) 소스를 컴파일하여 바이너리를 만드는 그 함수에 반드시 원본 소스를 집어넣어야 하기 때문이다. 그래서 이 함수만 잘 추적한다면 원본 소스를 통째로 도둑맞게 된다. 그렇다고 미리 컴파일된 바이너리를 로드하는 방법을 쓰자니, 각 아키텍처에 맞게 컴파일된 바이너리라 호환성을 보장할 수 없다. 이 상황에서 유일한 방법은 각각 아키텍처마다 일일이 바이너리를 만드는 것이다. 다른 벤더 전용 GPGPU 코드들의 경우 컴파일러를 한차례 거친 바이트코드를 하드웨어에 맞게 재컴파일을 하는 방식을 사용하고 있어 평문으로 된 소스코드를 분석하는것과 컴파일러의 최적화 패스를 거친 바이트코드를 분석하는 난이도는 차이가 분명히 존재한다.
  OpenCL 2.0 부터는 Vulkan API의 SPIR-V를 사용할 수 있고 2.1 부터 해당 기능은 Core Feature 로 편입되었다.
• 버전의 파편화가 심하다. OpenCL 2.0은 메이저 회사에서 모두 지원하지 않았다. 특히 NVIDIA는 3.0 표준이 나올 때 까지도 1.2 만을 지원하였다. 또한 2.0 위의 핵심 기능들을 Optional로 처리하는 행위 등으로 말만 2.0 지원이지 확장 기능을 지원하지 않는 물건들도 많았으며 3.0은 아예 1.2의 기능만 Core Feature로 처리하고 SPIR 바이트코드 컴파일과 같은 것들을 모두 Optional로 바꿔버렸다. 이 때문에 OpenCL 3.0은 2.0의 슈퍼셋이 아니며 CUDA를 밀고 있는 NVIDIA의 OpenCL 3.0지원 드라이버는 1.2지원때와 별 다른 상황이 아니다.
• OpenGL과 같은 범용이고 구현 없이 명세만 되어 있는 특성상 OpenCL 드라이버 회사마다 성능이 제각각이며 버그도 튀어나온다. 이러한 문제는 OpenCL 자체의 문제라기 보다는 이를 구현하는 벤더의 드라이버 퀄리티 문제긴 하나 생태계 전반적으로 보면 분명한 단점이다.