OpenGL 대 OpenCL, 무엇을 선택해야하며 그 이유는 무엇입니까?

계산을 위해 GLSL이있는 OpenGL보다 OpenCL을 독특하게 만드는 기능은 무엇입니까? 그래픽 관련 용어와 실용적이지 않은 데이터 유형에도 불구하고 OpenGL에 대한 실제주의 사항이 있습니까?

예를 들어, 다른 텍스처를 사용하여 a를 텍스처로 렌더링하여 병렬 함수 평가를 수행 할 수 있습니다. 축소 작업은 더 작고 작은 텍스처로 반복적으로 렌더링하여 수행 할 수 있습니다. 반면에 임의 쓰기 액세스는 효율적인 방식으로 불가능합니다 (할 수있는 유일한 방법은 텍스처 기반 정점 데이터로 삼각형을 렌더링하는 것입니다). OpenCL로 가능합니까? OpenGL로 불가능한 다른 것은 무엇입니까?

OpenCL은 컴퓨팅을 위해 특별히 만들어졌습니다. OpenGL을 사용하여 과학 컴퓨팅을 수행 할 때 컴퓨팅 문제를 그래픽 컨텍스트에 매핑하는 방법에 대해 항상 생각해야합니다.

OpenCL에서는 메모리 버퍼에서 계산 커널을 사용하여 계산을 공식화하면 좋습니다. 이것은 실제로 큰 승리입니다 (두 변형을 모두 고려하고 구현 한 관점에서 볼 때).

메모리 액세스 패턴은 동일합니다 (계산은 여전히 ​​GPU에서 발생하지만 GPU는 요즘 점점 더 유연 해지고 있습니다).

그러나 번역하는 방법에 대해 머리를 쓰지 않고 12 개 이상의 병렬 "CPU"를 사용하는 것보다 더 기대할 수있는 것은 무엇입니까? 예를 들어 (어리석은 예) 푸리에를 삼각형과 쿼드로 ...?

지금까지 어떤 답변에서도 언급되지 않은 것은 실행 속도입니다. 만약알고리즘을 OpenGL 그래픽으로 표현할 수있는 (예 : 분산 된 쓰기, 로컬 메모리 없음, 작업 그룹 없음 등) OpenCL에 비해 매우 빠르게 실행됩니다. 저의 구체적인 경험은 AMD, nVidia, IMG 및 Qualcomm GPU에서 이미지 필터 (수집) 커널을 수행하는 것입니다. OpenGL 구현은 하드 코어 OpenCL 커널 최적화 후에도 항상 더 빠르게 실행됩니다. (제외 : 그래픽 지향 워크로드에 맞게 특별히 조정 된 수년 간의 하드웨어 및 드라이버 때문이라고 생각합니다.)

내 조언은 컴퓨팅 프로그램 이 그래픽 도메인에 잘 매핑되는 것처럼 느껴 지면 OpenGL을 사용한다는 것입니다. 그렇지 않은 경우 OpenCL은 컴퓨팅 문제를 표현하는 데 더 일반적이고 간단합니다.

언급해야 할 또 다른 요점 (또는 질문)은 취미로 (즉, 자신을 위해) 또는 상업적으로 (즉, 다른 사람에게 배포하기 위해) 글을 쓰고 있는지 여부입니다. OpenGL은 거의 모든 곳에서 지원되지만 OpenCL은 모바일 장치에서 완전히 지원되지 않으며, imho는 향후 몇 년 내에 Android 또는 iOS에 나타날 가능성이 거의 없습니다. 단일 코드 기반의 광범위한 플랫폼 간 호환성이 목표 인 경우 OpenGL이 강제 될 수 있습니다.

계산을 위해 GLSL이있는 OpenGL보다 OpenCL을 독특하게 만드는 기능은 무엇입니까? 그래픽 관련 용어와 실용적이지 않은 데이터 유형에도 불구하고 OpenGL에 대한 실제주의 사항이 있습니까?

예 : 그래픽 API입니다. 따라서 그 안에서하는 모든 작업은 이러한 용어에 따라 공식화되어야합니다. 데이터를 "렌더링"형식으로 패키징해야합니다. 속성, 균일 한 버퍼 및 텍스처 측면에서 데이터를 처리하는 방법을 파악해야합니다.

OpenGL 4.3 및 OpenGL ES 3.1 사용 컴퓨 트 셰이더를 사용 하면 상황이 좀 더 복잡해집니다. 컴퓨팅 셰이더는 OpenCL 컴퓨팅 작업과 유사한 방식으로 SSBO / 이미지로드 / 저장을 통해 메모리에 액세스 할 수 있습니다 (OpenCL은 실제 포인터를 제공하지만 GLSL은 제공하지 않음). OpenGL과의 상호 운용은 OpenCL / GL interop보다 훨씬 빠릅니다.

그렇더라도 컴퓨팅 셰이더는 한 가지 사실을 변경하지 않습니다. OpenCL 컴퓨팅 작업은 은 OpenGL의 컴퓨팅 셰이더 매우 다른 정밀도로 . GLSL의 부동 소수점 정밀도 요구 사항은 그다지 엄격하지 않으며 OpenGL ES는 훨씬 덜 엄격합니다. 따라서 부동 소수점 정확도가 계산에 중요한 경우 OpenGL은 계산에 필요한 것을 계산하는 가장 효과적인 방법이 아닙니다.

또한 OpenGL 컴퓨팅 셰이더에는 4.x 지원 하드웨어가 필요하지만 OpenCL은 훨씬 열등한 하드웨어에서 실행할 수 있습니다.

또한 렌더링 파이프 라인을 선택하여 컴퓨팅을 수행하는 경우 OpenGL 드라이버는 여전히 렌더링을 수행한다고 가정합니다. 따라서 그 가정을 기반으로 최적화 결정을 내릴 것입니다. 그림을 그리는 경우 셰이더 리소스 할당을 최적화합니다.

예를 들어 부동 소수점 프레임 버퍼로 렌더링하는 경우 드라이버가 R11_G11_B10 프레임 버퍼를 제공하기로 결정할 수 있습니다. 알파로 아무것도 수행하지 않고 알고리즘이 낮은 정밀도를 허용 할 수 있기 때문입니다. 사용하는 경우 이미지로드 / 저장을 하지만 대신 프레임 버퍼, 당신은 더 적은이 효과를 얻을 가능성이있어.

OpenCL은 그래픽 API가 아닙니다. 계산 API입니다.

또한 OpenCL은 더 많은 항목에 대한 액세스를 제공합니다. GL과 관련하여 암시적인 메모리 레벨에 액세스 할 수 있습니다. 특정 메모리는 스레드간에 공유 될 수 있지만 GL의 개별 셰이더 인스턴스는 서로 직접적으로 영향을 미칠 수 없습니다 (이미지로드 / 저장 외부에 있지만 OpenCL은 액세스 권한이없는 하드웨어에서 실행 됨).

OpenGL은 추상화 뒤에 하드웨어가하는 일을 숨 깁니다. OpenCL은 무슨 일이 일어나고 있는지 거의 정확하게 보여줍니다.

OpenGL을 사용하여 임의의 계산을 수행 할 수 있습니다 . 하지만 당신은 원하지 . 완벽하게 실행 가능한 대안이있는 동안은 아닙니다. OpenGL의 컴퓨팅은 그래픽 파이프 라인을 서비스하기 위해 사용됩니다.

모든 종류의 렌더링되지 않는 컴퓨팅 작업에 OpenGL을 선택 하는 유일한 이유는 OpenCL을 실행할 수없는 하드웨어를 지원하기위한 것입니다. 현재 여기에는 많은 모바일 하드웨어가 포함됩니다.

한 가지 주목할만한 기능은 분산 된 쓰기이고 다른 하나는 "Windows 7 스마트 함"이 없다는 것입니다. 아시다시피 Windows 7은 OpenGL이 2 초 정도 플러시되지 않으면 디스플레이 드라이버를 종료합니다 (정확한 시간을 정하지는 마십시오.하지만 2 초라고 생각합니다). 긴 작업을하는 경우 이것은 성 가실 수 있습니다.

또한 OpenCL은 그래픽 카드보다 훨씬 더 다양한 하드웨어에서 작동하며 "인공적 제약"이있는 견고한 그래픽 지향 파이프 라인이 없습니다. 동시에 여러 명령 스트림을 실행하는 것이 더 쉽습니다 (사소한).

현재 OpenGL이 그래픽을위한 더 나은 선택이지만 영구적 인 것은 아닙니다.

OpenGL이 결국 OpenCL의 확장으로 병합하는 것이 실용적 일 수 있습니다. 두 플랫폼은 약 80 % 동일하지만 거의 동일한 하드웨어 구성 요소에 대해 구문 특성이 다르고 명명법이 다릅니다. 즉, 두 가지 언어를 배우고 두 가지 API를 알아 내야합니다. 그래픽 드라이버 개발자는 더 이상 두 개의 개별 플랫폼을 위해 개발할 필요가 없기 때문에 병합을 선호합니다. 이는 드라이버 디버깅에 더 많은 시간과 리소스를 남깁니다. ;)

고려해야 할 또 다른 점은 OpenGL과 OpenCL의 기원이 다르다는 것입니다. OpenGL은 네트워크를 통한 초기 고정 파이프 라인 시대에 시작되고 추진력을 얻었으며 기술이 발전함에 따라 천천히 추가되고 사용되지 않습니다. OpenCL을, 어떤 방법으로, 진화이다 의 OpenGL이 GPU의 (계획되지 않은) 유연성이 허용 된만큼 수치 처리에 사용되기 시작했다는 점에서 OpenGL . "그래픽 vs. 컴퓨팅"은 실제로 의미 론적 논쟁에 가깝습니다. 두 경우 모두 가능한 최고의 성능으로 수학 연산을 하드웨어에 매핑하려고 항상 노력하고 있습니다. vanilla CL이 사용하지 않는 GPU 하드웨어 부분이 있지만 별도의 확장을 사용하지 않습니다.

그렇다면 OpenGL은 CL에서 어떻게 작동할까요? 추측 적으로 삼각형 래스터 라이저는 특별한 CL 작업으로 대기열에 추가 될 수 있습니다. 특별한 GLSL 함수는 바닐라 OpenCL에서 구현 된 다음 커널 컴파일 중에 드라이버가 하드웨어 가속 명령으로 재정의 할 수 있습니다. 라이브러리 확장이 제공 될 때까지 OpenCL에서 셰이더를 작성하는 것은 전혀 고통스러운 경험처럼 들리지 않습니다.

하나를 다른 것보다 더 많은 기능을 갖도록 호출하는 것은 서로 다른 명명법 아래에서 둘 다 동일한 기능의 80 %를 얻으므로 의미가 없습니다. OpenCL이 컴퓨팅 용으로 설계 되었기 때문에 그래픽에 적합하지 않다고 주장하는 것은 그래픽 처리 가 컴퓨팅 이기 때문에 의미가 없습니다 .

또 다른 주요 이유는 OpenGL \ GLSL이 그래픽 카드에서만 지원된다는 것입니다. 멀티 코어 사용은 그래픽 하드웨어를 사용하여 시작되었지만 계산을 대상으로하는 멀티 코어 하드웨어 플랫폼에서 작업하는 많은 하드웨어 공급 업체가 있습니다. 예를 들어 Intels Knights Corner를 참조하십시오.

OpenGL \ GLSL을 사용하여 계산 용 코드를 개발하면 그래픽 카드가 아닌 하드웨어를 사용할 수 없습니다.

OpenGL 4.5뿐만 아니라 OpenCL 2.0에는 OpenGL 4.5에는없는 기능이 있습니다 (내가 말할 수있는 한) (OpenCL에는없는 OpenGL의 기능은 포함되지 않음).

이벤트

더 나은 원자

블록

작업 그룹 기능 : work_group_all 및 work_group_any work_group_broadcast : work_group_reduce work_group_inclusive / exclusive_scan

커널에서 커널 대기열에 추가

포인터 (GPU에서 실행중인 경우에는 문제가되지 않음)

OpenGL에없는 몇 가지 수학 함수 (OpenGL에서 직접 구성 할 수 있음)

공유 가상 메모리

(추가) 커널 용 컴파일러 옵션

특정 GPU (또는 기타)를 쉽게 선택

GPU가 없을 때 CPU에서 실행 가능

틈새 하드웨어 플랫폼 (예 : FGPA)에 대한 추가 지원

일부 (모두?) 플랫폼에서는 계산을 수행하는 데 창 (및 컨텍스트 바인딩)이 필요하지 않습니다.

OpenCL을 사용하면 계산 정밀도를 조금 더 제어 할 수 있습니다 (컴파일러 옵션을 통한 일부 포함).

위의 많은 것들은 대부분 더 나은 CPU를위한 것입니다-GPU 상호 작용 : 이벤트, 공유 가상 메모리, 포인터 (잠재적으로 다른 것들에도 도움이 될 수 있음).

OpenGL은 여기에 많은 다른 게시물이 작성 되었기 때문에 클라이언트 및 서버 메모리의 다른 영역으로 항목을 정렬하는 기능을 얻었습니다. OpenGL은 이제 더 나은 메모리 장벽과 원 자학 지원을 제공하며 GPU 내의 다른 레지스터에 사물을 할당 할 수 있습니다 (OpenCL과 거의 동일한 정도). 예를 들어 이제 OpenGL에서 로컬 컴퓨팅 그룹의 레지스터를 공유 할 수 있습니다 (AMD GPU LDS (로컬 데이터 공유)와 같은 것을 사용하여 (현재이 특정 기능은 OpenGL 컴퓨팅 셰이더에서만 작동 함)). OpenGL은 더 강력한 성능의 구현을 제공합니다. 일부 플랫폼 (예 : 오픈 소스 Linux 드라이버) OpenGL은 더 많은 고정 기능 하드웨어에 액세스 할 수 있습니다 (다른 답변에서 언급 한 것처럼). 때때로 고정 기능 하드웨어를 피할 수 있다는 것은 사실이지만 (예 : Crytek은 "소프트웨어"를 사용합니다.) 깊이 버퍼의 구현) 고정 기능 하드웨어는 메모리를 잘 관리 할 수 ​​있으며 (일반적으로 GPU 하드웨어 회사에서 일하지 않는 사람보다 훨씬 낫습니다) 대부분의 경우 훨씬 더 우수합니다. OpenCL이 주요 OpenGL 고정 기능 영역 중 하나 인 고정 기능 텍스처 지원이 꽤 우수하다는 것을 인정해야합니다.

나는 Intels Knights Corner가 스스로를 제어하는 ​​x86 GPU라고 주장합니다. 또한 텍스처 기능이있는 OpenCL 2.0 (실제로는 OpenCL의 더 낮은 버전에 있음)을 user2746401이 제안한 성능 수준과 거의 동일하게 사용할 수 있다고 주장합니다.

OpenCL (2.0 버전)은 시스템의 모든 구성 요소가 다른 시스템 구성 요소에 의해 생성 된 작업을 생성하고 소비 할 수있는 이기종 컴퓨팅 환경을 설명합니다. 더 이상 CPU, GPU (등) 개념이 더 이상 필요하지 않습니다. 호스트 및 장치 만 있으면됩니다.

반대로 OpenGL은 작업 생산자 인 CPU와 작업 소비자 인 GPU로 엄격하게 구분됩니다. 유연성이 떨어지면 성능이 향상되므로 나쁘지 않습니다. OpenGL은 더 좁은 범위의 도구입니다.

이미 존재하는 답변 외에도 OpenCL / CUDA는 계산 영역에 더 적합 할뿐만 아니라 기본 하드웨어를 너무 많이 추상화하지 않습니다. 이렇게하면 공유 메모리 또는 통합 된 메모리 액세스와 같은 것으로부터 더 많은 이익을 얻을 수 있습니다. 그렇지 않으면 셰이더의 실제 구현에 묻힐 수 있습니다 (원하는 경우 그 자체가 특별한 OpenCL / CUDA 커널에 지나지 않음).

이러한 것으로부터 이익을 얻으려면 커널이 실행될 특정 하드웨어에 대해 조금 더 알고 있어야하지만 셰이더를 사용하여 이러한 사항을 명시 적으로 고려하지 마십시오 (완전히 가능하더라도).

단순한 레벨 1 BLAS 루틴보다 더 복잡한 작업을 수행하면 OpenCL / CUDA의 유연성과 일반성을 확실히 인식하게 될 것입니다.

OpenCL은 범용 계산을 위해 설계된 "기능"인 반면 OpenGL은 그래픽 용입니다. GL에서 무엇이든 할 수 있지만 (튜링 완료) 드라이버의 손잡이를 망치로 사용하여 못을 박습니다.

또한 OpenCL은 GPU뿐만 아니라 CPU 및 다양한 전용 가속기에서도 실행할 수 있습니다.