Announcement

Collapse
No announcement yet.

OpenCL 3.0.7 Released With New Extensions

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

  • #11
    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.

    Comment


    • #12
      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.

      Comment


      • #13
        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:

        A simple Vulkan compute sample. GitHub Gist: instantly share code, notes, and snippets.

        (610 lines!)

        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)

        Comment


        • #14
          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.

          Comment


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

            Comment

            Working...
            X