Jump to content
  • Advertisement
Sign in to follow this  
Vilem Otte

Vulkan Is OpenCL slowly dying?

This topic is 646 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've recently noticed that it looks like the support for OpenCL looks like being slowly dropped in favor of using Vulkan (although it might be only in game industry, as I assume OpenCL is still used in places where rendering is not going to be the thing),

 

In the end, they both (CL and compute on Vulkan) are compiled into SPIR-V as far as I know, so for vendors it is not really a big problem to support both.

 

Nevertheless, what are your opinions?

Share this post


Link to post
Share on other sites
Advertisement

I'm curious what leads you to believe that support for OpenCL is waning. From what I can figure, most graphics developers didn't care for CL much due to clumsy interop with GL, which is why compute was added directly to GL core in 4.5. It's much more useful to game/graphics developers in that format than CL is, and CL has moved to more scientific computing type uses. I don't think Vulkan plays in at all.

 

Yah, I've only seen OpenCL and the like used for simulation/neural network/etc. stuff. Graphics tend to stick with whatever's native as possible.

Share this post


Link to post
Share on other sites

Take into account also WebGL. WebGL is quite popular now. And I suppose that due to difficulties to implement Vulkan in browsers it will be so for a long time.

Share this post


Link to post
Share on other sites

I've recently noticed that it looks like the support for OpenCL looks like being slowly dropped in favor of using Vulkan (although it might be only in game industry, as I assume OpenCL is still used in places where rendering is not going to be the thing),

 

Agree, but even for non rendering tasks Compute Shader will be preferred because you can do both async if you use Graphics API for everything.

Also NVidias lack of support makes OpenCL inpractical because 1.2 has no indirect dispatch.

 

I do a large project in OpenCL and Vulkan (to get some profiler data - CodeXL does not work yet for Vulkan).

Ignoring the dispatch problem and looking only at GPU time and AMD, the performance varies about 20-30%. Sometimes VK wins, sometimes OpenCL.

Next Vulkan will have data sharing, so personally i'm still considering OpenCL as an alternative in extreme cases.

Share this post


Link to post
Share on other sites

The thing with OpenCL vs Vulkan is the former will prioritize accuracy while the latter will prioritize performance. Although some Vulkan implementations could provide strong IEEE and double support extensions, it doesn't change the fact it will be fancy add on whereas OpenCL it is a must-have and the core focus.

 

 

Take into account also WebGL. WebGL is quite popular now. And I suppose that due to difficulties to implement Vulkan in browsers it will be so for a long time.

There won't be a WebVulkan as Vulkan provides a degree of low level access that is a massive security nightmare that browser cannot afford to allow.

Edited by Matias Goldberg

Share this post


Link to post
Share on other sites
Don't think it's dying, though it's never been super popular in the games industry (it doesn't port to XBox, PlayStation, Windows+DirectX, etc.).

Remember that OpenCL is taking some new forms though. HSA uses are increasingly interested in variants of OpenCL, like the original SPIR work, that allows a C/C++/
whatever compiler to translate functions into kernels that can run on GPUs, FPGAs, and other compute-oriented coprocessors. On Linux particularly, which is the dominate platform for server and embedded work, OpenCL/SPIR is a primary part of that support.

As other compilers catch up to those language features they'll likely use whatever their platform's native compute SDK requires (DirectCompute, Vulkan/SPIR-V, CUDA/PTX, etc.)

Games have also downplayed compute because there's not really any spare GPU cycles on gamers' machines. Graphics uses every bit of GPU power, the integrated GPUs are usually disabled automatically when the discrete GPU is running on all but the newest chipsets, and using the integrated GPU will limit the CPU speed (thermal envelope constraints).

There probably could be more compute use on the server for games with dedicated hosts, but the games industry just didn't seem to have caught up to that idea yet. E.g. we want to experiment with it for some of our server-side processing, but our datacenters refuse to even give us the option of having GPU access (possibly exacerbated by VM technology).

Share this post


Link to post
Share on other sites
Games have also downplayed compute because there's not really any spare GPU cycles on gamers' machines. Graphics uses every bit of GPU power, the integrated GPUs are usually disabled automatically when the discrete GPU is running on all but the newest chipsets, and using the integrated GPU will limit the CPU speed (thermal envelope constraints).

 

I don't think that's true at all. Many games and engines now are leaning heavily on compute, both as part of the graphics pipeline itself and for physics. A lot of the destruction physics stuff gets off-loaded to GPU nowadays. And the Battlefield/Frostbite slides lay out a very effective vision for how compute can be very beneficial to a graphics pipeline.

Edited by Promit

Share this post


Link to post
Share on other sites

I don't think that's true at all. Many games and engines now are leaning heavily on compute, both as part of the graphics pipeline itself and for physics.
 

 

Graphics, yes, I guess I personally consider that a very different thing than compute, though - it's still graphics. Sorry I wasn't clearer about that distinction up front.

 

From a games' perspective, that basically means you get compute if you're doing a visual effect but not if you're doing e.g. an AI algorithm, typically anyways.

 

Physics compute usage (actually running on the GPU) is still quite rare, even with libraries like PhysX. The closest you really come is non-gameplay-relevant physics like particles, hair, or cloth simulation on the GPU; aka "effects physics" that are basically a render-quality feature that make the game _look_ more alive while having no effect on the game _feeling_ more alive. Some of the more popular physics libraries in games don't even provide the option of GPU-assisted gameplay physics.

Share this post


Link to post
Share on other sites

Thanks for the input.

 

What made me originally believe that the support for OpenCL is waning is the fact that there the updates for it are not that frequent (although on the other hand, with exceptions for new extensions, OpenGL 4.5 is like 2 years old standard too ... Vulkan updates are a different thing, but that is a fresh api).

 

Maybe it was just my feeling, as I haven't seen pretty much anyone working with it in last year or so (although I'm still keeping OpenCL code in my code base and using those kernels). Although as my requirements are not aiming for perfect precision, I might be better of going the compute shader way (with GLSL).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!