Announcement

Collapse
No announcement yet.

OpenCL 3.0.7 Released With New Extensions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • lumks
    replied
    We still need good, and in the best case open, OpenCL driver on linux.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by tildearrow View Post

    It is harder to code a game engine in OpenCL (as you don't have access to the geometry hardware and stuff), but it is easier to code a compute application on Vulkan.

    Vulkan driver installation is easy; for OpenCL it is a mess.
    Sometimes compute is important, even for small applications (office suites).

    See waifu2x-ncnn-vulkan for a big example.
    Well yeah, thats a problem with general usability rather than using the software for its intended purpose.

    I mean its like arguing that you want to use Java to code a kernel because its easier to use, thats completely missing the point.

    Also I really doubt that in general Vulkan is easier for compute than OpenCL at least from my very rudimentary exploration of it some years ago.

    Leave a comment:


  • coder
    replied
    Originally posted by piotrj3 View Post
    Compute Vulkan is quite significantly easier maybe not OpenCL tier but most of OpenCL example you provided follows same principle, just Vulkan is a bit more verbose, https://www.duskborn.com/posts/a-sim...mpute-example/
    Here's the full source of that, excluding shader code:

    And, unlike the OpenCL API, Vulkan has no built-in support for compiling a shader. So, you're on your own with that.


    Originally posted by piotrj3 View Post
    Still a lot of vulkan manual work is initiating device create command pool etc.
    That example doesn't even touch on the concept of device memory hierarchies. OpenCL neatly handles that for you, but it seems Vulkan just hands you the pieces and then the rest is up to you.


    Originally posted by piotrj3 View Post
    Vulkan has that wierd idea of writing hello world is hard.
    Not only hello world! In Vulkan, everything is an order of magnitude more complex! You get a lot less support from the runtime, meaning you have to bring your own solutions for things like resource management & scheduling. Vulkan is really for game engines that want to do that sort of thing themselves, anyhow.

    What you're still glossing over is the precision issue. First, your device & runtime had better support SignedZeroInfNanPreserve, which provides the sort of behavior most serious compute users will expect. I don't know how common that is, but it's the sort of detail that gets lost when people hear the message that "Vulkan runs everywhere".

    The other concern I have about Vulkan compute is that the precision requirements seem based on OpenGL 4.5. In some cases, this is much worse than what OpenCL requires. For instance, Vulkan[1] only requires atan() be accurate to within 4096 ULP, whereas OpenCL 1.2[2] requires <= 5!

    References:
    1. https://www.khronos.org/registry/vul...sion-operation
    2. https://www.khronos.org/registry/Ope...opencl-1.2.pdf (see Section 7.4)

    Leave a comment:


  • piotrj3
    replied
    Originally posted by coder View Post
    Are you serious, right now? What the heck are you using as data points??

    Here's a Vulkan program that draws a triangle, written by the author of vulkan-tutorial.com:


    Here's a fairly simple OpenCL example:



    Again, WTF? I think you're confused.

    I am using OpenCL in a product on Intel and the install works like no-fuckin-problem! Same for Nvidia, actually.

    It's just AMD's ROCm that's been the epic cluster fuck of open source GPU driver stacks (though most of that is behind us, from what I've read).
    Compute Vulkan is quite significantly easier maybe not OpenCL tier but most of OpenCL example you provided follows same principle, just Vulkan is a bit more verbose, https://www.duskborn.com/posts/a-sim...mpute-example/

    Still a lot of vulkan manual work is initiating device create command pool etc. but Vulkan also has some performance benefits because of its architecture, adding next operations/computer shaders/kernels is not big diffrence. Vulkan has that wierd idea of writing hello world is hard.
    Last edited by piotrj3; 26 April 2021, 08:07 PM.

    Leave a comment:


  • coder
    replied
    Originally posted by tildearrow View Post
    it is easier to code a compute application on Vulkan.
    Are you serious, right now? What the heck are you using as data points??

    Here's a Vulkan program that draws a triangle, written by the author of vulkan-tutorial.com:



    Here's a fairly simple OpenCL example:



    Originally posted by tildearrow View Post
    Vulkan driver installation is easy; for OpenCL it is a mess.
    Again, WTF? I think you're confused.

    I am using OpenCL in a product on Intel and the install works like no-fuckin-problem! Same for Nvidia, actually.

    It's just AMD's ROCm that's been the epic cluster fuck of open source GPU driver stacks (though most of that is behind us, from what I've read).
    Last edited by coder; 26 April 2021, 06:46 PM.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by mdedetrich View Post

    Why do people keep on bringing up Vulkan as a replacement for OpenCL, they have completely different design goals. OpenCL is for general compute on GPU's, Vulkan is for rendering. Yes there is overlap, but you are not going to code your game engine in OpenCL and you are not going to be doing scientific math HPC calculations in Vulkan.
    It is harder to code a game engine in OpenCL (as you don't have access to the geometry hardware and stuff), but it is easier to code a compute application on Vulkan.

    Vulkan driver installation is easy; for OpenCL it is a mess.
    Sometimes compute is important, even for small applications (office suites).

    See waifu2x-ncnn-vulkan for a big example.
    Last edited by tildearrow; 26 April 2021, 05:51 PM.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by tildearrow View Post

    What's more appealing?

    - the extensions
    - Vulkan

    Not saying OpenCL is bad though...
    Why do people keep on bringing up Vulkan as a replacement for OpenCL, they have completely different design goals. OpenCL is for general compute on GPU's, Vulkan is for rendering. Yes there is overlap, but you are not going to code your game engine in OpenCL and you are not going to be doing scientific math HPC calculations in Vulkan.

    Leave a comment:


  • coder
    replied
    Originally posted by tildearrow View Post
    What's more appealing?

    - the extensions
    - Vulkan
    Depends on what you're doing. Vulkan isn't supported on FPGAs, for one thing. More importantly, I believe it lacks OpenCL's accuracy guarantees (I expect Vulkan-compute differs, in that regard).

    As for the extensions, one of them is:

    "cl_khr_vk_sharing for associating an OpenCL context with a Vulkan physical device"

    ...which should tell you there are people using Vulkan who still want/need OpenCL.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by kieffer View Post

    I would say: just a few additional extensions. But some of them are appealing.
    What's more appealing?

    - the extensions
    - Vulkan

    Not saying OpenCL is bad though...

    Leave a comment:


  • kieffer
    replied
    Originally posted by tildearrow View Post
    Another OpenCL version? :<
    I would say: just a few additional extensions. But some of them are appealing.

    Leave a comment:

Working...
X