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

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에는없는 기능은 다루지 않습니다).

이벤트

더 나은 원자

블록

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

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

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

A few math functions that OpenGL doesn't have (though you could construct them yourself in OpenGL)

Shared Virtual Memory

(More) Compiler Options for Kernels

Easy to select a particular GPU (or otherwise)

Can run on the CPU when no GPU

More support for those niche hardware platforms (e.g. FGPAs)

On some (all?) platforms you do not need a window (and its context binding) to do calculations.

OpenCL allows just a bit more control over precision of calculations (including some through those compiler options).

A lot of the above are mostly for better CPU - GPU interaction: Events, Shared Virtual Memory, Pointers (although these could potentially benefit other stuff too).

OpenGL has gained the ability to sort things into different areas of Client and Server memory since a lot of the other posts here have been made. OpenGL has better memory barrier and atomics support now and allows you to allocate things to different registers within the GPU (to about the same degree OpenCL can). For example you can share registers in the local compute group now in OpenGL (using something like the AMD GPUs LDS (local data share) (though this particular feature only works with OpenGL compute shaders at this time). OpenGL has stronger more performing implementations on some platforms (such as Open Source Linux drivers). OpenGL has access to more fixed function hardware (like other answers have said). While it is true that sometimes fixed function hardware can be avoided (e.g. Crytek uses a "software" implementation of a depth buffer) fixed function hardware can manage memory just fine (and usually a lot better than someone who isn't working for a GPU hardware company could) and is just vastly superior in most cases. I must admit OpenCL has pretty good fixed function texture support which is one of the major OpenGL fixed function areas.

I would argue that Intels Knights Corner is a x86 GPU that controls itself. I would also argue that OpenCL 2.0 with its texture functions (which are actually in lesser versions of OpenCL) can be used to much the same performance degree user2746401 suggested.

---

OpenCL (in 2.0 version) describes heterogeneous computational environment, where every component of system can both produce & consume tasks, generated by other system components. No more CPU, GPU (etc) notions are longer needed - you have just Host & Device(s).

OpenGL, in opposite, has strict division to CPU, which is task producer & GPU, which is task consumer. That's not bad, as less flexibility ensures greater performance. OpenGL is just more narrow-scope instrument.

---

In addition to the already existing answers, OpenCL/CUDA not only fits more to the computational domain, but also doesn't abstract away the underlying hardware too much. This way you can profit from things like shared memory or coalesced memory access more directly, which would otherwise be burried in the actual implementation of the shader (which itself is nothing more than a special OpenCL/CUDA kernel, if you want).

Though to profit from such things you also need to be a bit more aware of the specific hardware your kernel will run on, but don't try to explicitly take those things into account using a shader (if even completely possible).

Once you do something more complex than simple level 1 BLAS routines, you will surely appreciate the flexibility and genericity of OpenCL/CUDA.

---

The "feature" that OpenCL is designed for general-purpose computation, while OpenGL is for graphics. You can do anything in GL (it is Turing-complete) but then you are driving in a nail using the handle of the screwdriver as a hammer.

Also, OpenCL can run not just on GPUs, but also on CPUs and various dedicated accelerators.

참고URL : https://stackoverflow.com/questions/7907510/opengl-vs-opencl-which-to-choose-and-why