<p>OpenCL isn't really a drawing API, it's designed for doing compute workloads across different devices, not necessarily GPUs. You can certainly write a kernel that renders to a texture in OpenCL, and have this texture be available to Open GL or D3D. AFAIK, though, you wouldn't have access to the fixed-function hardware like rasterization, attribute interpolation, and fragment blending, so you'd have to implement it yourself (unless you're writing a ray tracer). You'd also likely have to use one of the drawing APIs to present your texture to the screen, by rasterizing a full screen quad and sampling your texture at each pixel. This carries a synchronization penalty - although OpenGL and D3D can interoperate with OpenCL, they can't access the same memory at the same time, so you need to wait for control to transfer from one API to the other.</p>

<p>Using compute on an already rendered buffer for screenspace effects is a good idea, since you save the fillrate of rasterizing a full screen quad every time you apply a new effect compared to the fragment shader approach. These days though, OpenGL and D3D have compute shaders built-in to handle this kind of use case. Why do you want to use OpenCL exactly? Seems to me you'd be better off using one of the rendering APIs.</p>

CC BY-SA 3.0
2018-03-15T09:55:17.970Z
I want to use OpenCL mainly for reasons of familiarity and portability.
barneypitt
CC BY-SA 3.0
2018-03-15T10:03:54.343Z
Familiarity, fair enough. As for portability, you can run OpenGL anywhere you can run OpenCL (although Apple's version is pretty badly out of date). Still worth learning GLSL though, it's pretty easy if you already know any of the C-variant languages.
russ
CC BY-SA 3.0
2018-03-15T10:05:26.770Z
By portability I meant portable to DirectX.

I certainly don't want to do my own rasterisation! Your answer is very elucidating and I think I'm beginning to understand what OpenCL should and shouldn't be used for in a graphics pipeline.

One thing I would like to do is manipulate textures and potentially generate textures before they are used in the pipeline - am I right in thinking this would be something OpenCL would be suitable for? It seems I can use a shared GL texture/surface in OpenCL and write to it, and don't see any reason this wouldn't be possible.
barneypitt
CC BY-SA 3.0
2018-03-15T10:59:36.140Z
Yeah, for asset creation and manipulation it's fine. I've even seen a paper where they were doing Marching Cubes in OpenCL to generate a vertex buffer each frame then rendering it with OpenGL - but the cost of syncing between APIs was eating a significant chunk of frame time.
russ
CC BY-SA 3.0
2018-03-15T02:59:23.777Z
2018-03-15T02:59:23.777Z
russ
<p>I want to write (fragment) shaders in OpenCL rather than GLSL. Is there a standard mechanism for this (from OpenGL, and ideally also from DirectX)? Are there any drawbacks to doing this?</p>

<p>I also want to write screenspace effects in OpenCL. Is the mechanism the same? Are there any drawbacks?</p>

<p>Thanks</p>

<shader><opencl>
Writing OpenCL Shaders
barneypitt
# Writing OpenCL Shaders

(Asked by: username_0 on 2018-03-14)

I want to write (fragment) shaders in OpenCL rather than GLSL. Is there a standard mechanism for this (from OpenGL, and ideally also from DirectX)? Are there any drawbacks to doing this?

I also want to write screenspace effects in OpenCL. Is the mechanism the same? Are there any drawbacks?

Thanks

**Tags:** shader, opencl


---

## 1 answers

### Answer by username_1 on 2018-03-15. Score: 2

OpenCL isn't really a drawing API, it's designed for doing compute workloads across different devices, not necessarily GPUs. You can certainly write a kernel that renders to a texture in OpenCL, and have this texture be available to Open GL or D3D. AFAIK, though, you wouldn't have access to the fixed-function hardware like rasterization, attribute interpolation, and fragment blending, so you'd have to implement it yourself (unless you're writing a ray tracer). You'd also likely have to use one of the drawing APIs to present your texture to the screen, by rasterizing a full screen quad and sampling your texture at each pixel. This carries a synchronization penalty - although OpenGL and D3D can interoperate with OpenCL, they can't access the same memory at the same time, so you need to wait for control to transfer from one API to the other.

Using compute on an already rendered buffer for screenspace effects is a good idea, since you save the fillrate of rasterizing a full screen quad every time you apply a new effect compared to the fragment shader approach. These days though, OpenGL and D3D have compute shaders built-in to handle this kind of use case. Why do you want to use OpenCL exactly? Seems to me you'd be better off using one of the rendering APIs.

> **Comments:**
> **username_0**: I want to use OpenCL mainly for reasons of familiarity and portability.  
> **username_1**: Familiarity, fair enough. As for portability, you can run OpenGL anywhere you can run OpenCL (although Apple's version is pretty badly out of date). Still worth learning GLSL though, it's pretty easy if you already know any of the C-variant languages.  
> **username_0**: By portability I meant portable to DirectX.  I certainly don't want to do my own rasterisation! Your answer is very elucidating and I think I'm beginning to understand what OpenCL should and shouldn't be used for in a graphics pipeline.  One thing I would like to do is manipulate textures and potentially generate textures before they are used in the pipeline - am I right in thinking this would be something OpenCL would be suitable for? It seems I can use a shared GL texture/surface in OpenCL and write to it, and don't see any reason this wouldn't be possible.  
> **username_1**: Yeah, for asset creation and manipulation it's fine. I've even seen a paper where they were doing Marching Cubes in OpenCL to generate a vertex buffer each frame then rendering it with OpenGL - but the cost of syncing between APIs was eating a significant chunk of frame time.  

---

