Announcement

Collapse
No announcement yet.

OpenCL Image Support For Gallium3D's Clover

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

  • #11
    Originally posted by schmidtbag View Post
    The major advantage of Vulkan (besides easier implementation) is lowering CPU usage, but for most cases that still use OpenCL, that's not really a requirement. Unlike graphics, I don't think most OpenCL tasks require realtime processing, so CPU overhead is pretty much a non-issue. Basically, you just give the GPU some complicated thing to process and then it takes care of the rest by itself; it isn't constrained to accomplishing the task within a certain time frame and it doesn't do as much back-and-forth communication to the CPU (compared to graphics). I figure that's why there's that FirePro GPU out there with it's own SSD controller - it effectively allows the GPU to work independently.
    Sound may require real-time processing. What about real-time decoding-encoding of audio and video? I'm sure there may be many scientific stuff that requires real-time processing, like a supossed oscilloscope and network analyzer software powered by the GPU and powerful I/O.

    You just provide excuses about not necessary because current usage, but that might change as the technology allows it.

    GPUs can provide the advantages of FPGAs if both APIs and the GPU evolve itself. It's a shame FPGAs are so expensive and yet lack many stuff like Open Standards and the power of a GPU, but they are still better for their low latency and programmability. Intel bought Altera, so this is another monopoly again.

    Why make OpenCL so limited instead more universal and part of Vulkan?

    Comment


    • #12
      Originally posted by bridgman View Post

      Clover is not dead in the water (unless everyone in the community decides that it should be), it's just that our efforts shifted a year or so ago from clover to rebuilding our proprietary OpenCL stack on top of ROCM and open sourcing the remaining closed-source bits.

      The first step along the way was replacing the proprietary/third-party C-language parser with clang (done); remaining tasks include:

      (a) modifying OpenCL to run over ROCM rather than the current back-end (which is based on the proprietary OpenGL driver), and

      (b) using the LLVM-based native compiler (also used in ROCM/HCC and the open source Mesa drivers) rather than the proprietary shader compiler.

      We are aiming to have a developer preview of the modified OpenCL stack (still closed source runtime but using a lot more open source code) around mid-December.
      WHY?

      Why not work together in a common project for it? I don't undertand how AMD uses Gallium3D for GPUs but aims at another piece of code for OpenCL, Intel has their own stuff for graphics but uses Gallium3D for OpenCL

      Are you both companies full of insane people or what? To me, both sucks and I'm against this messy way. It may corporate policy, so your corporate policies sucks. Sorry, but I just see lots of promises and very strange switchings..

      Comment


      • #13
        Originally posted by timofonic View Post

        WHY?

        Why not work together in a common project for it? I don't undertand how AMD uses Gallium3D for GPUs but aims at another piece of code for OpenCL, Intel has their own stuff for graphics but uses Gallium3D for OpenCL
        Since when did Intel use Gallium3D for OpenCL? Beignet that they use for GPU OpenCL isn't Gallium3D-based or Clover.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #14
          Originally posted by timofonic View Post
          Sound may require real-time processing. What about real-time decoding-encoding of audio and video? I'm sure there may be many scientific stuff that requires real-time processing, like a supossed oscilloscope and network analyzer software powered by the GPU and powerful I/O.
          Of course, there are situations where real-time processing is needed, but my point is most cases don't require it. If someone really demands it, nothing is stopping them from using Vulkan. But you questioned the need for OpenCL, and I'm telling you that OpenCL generally isn't obsoleted by Vulkan in the same way that OpenGL is. And even then, Vulkan (and DX12 for that matter) don't always yield better results in games. It sure can take a lot of effort to port something if you don't even see a 1% gain. If you're creating a new engine from scratch then sure, going Vulkan is a no-brainer. But most GPGPU related tasks use OpenCL or CUDA.

          As for your examples:
          There are relatively cheap ARM systems that can handle 4K decoding and game consoles that can handle HD encoding while playing the game, so I don't see Vulkan being a high priority. If you intend to do 4K live encoding, there's a good chance the API will not be the bottleneck.
          I have never heard of an oscilloscope that is massively parallel (doesn't mean one doesn't exist, but I don't know of one that warrants a GPU) so I don't think even OpenCL is a necessity. I welcome being proven wrong.
          Unless you're trying to locate a hacker or malware, a GPU API is the least of your worries when trying to efficiently analyze a large network at a high frequency. If the network isn't large then again, not even OpenCL is necessary.
          You just provide excuses about not necessary because current usage, but that might change as the technology allows it.
          If technology expands enough to need Vulkan then developers will use it. I don't see what your point is - nothing is stopping anybody from using Vulkan, but if your entire platform is already based on OpenCL and runs efficiently, it makes more sense to just stick with it. There is no problem here.
          Why make OpenCL so limited instead more universal and part of Vulkan?
          What makes OpenCL so limited? It's an open standard alternative to CUDA and works on any platform you compile it on - what makes it not universal? From what I recall, it's even compatible with some ASICs. To my understanding, Vulkan is technically already capable of handling non-graphics workloads, but there is no official support. Khronos will eventually focus more on it.

          https://www.khronos.org/vulkan/faq#khronos-apis-opencl

          Comment


          • #15
            Originally posted by timofonic View Post
            Why not work together in a common project for it? I don't undertand how AMD uses Gallium3D for GPUs but aims at another piece of code for OpenCL, Intel has their own stuff for graphics but uses Gallium3D for OpenCL

            Are you both companies full of insane people or what? To me, both sucks and I'm against this messy way. It may corporate policy, so your corporate policies sucks. Sorry, but I just see lots of promises and very strange switchings..
            I don't think Intel uses Gallium3D for OpenCL either.

            Reworded a bit, your question is basically "Why not write a new OpenCL implementation from scratch in clover/mesa instead of open sourcing the implementation you already have ?".

            When we started work on clover the amount of work required to open source our existing implementation was too high to be practical and HSA/ROC work was just starting, so going with clover and hoping other vendors would do the same made sense (although the "other vendors" part didn't really happen).

            Today, on the other hand, we have an open source compute stack (ROC) and open source native compiler so going the rest of the way to an open source OpenCL stack built on ROC and the associated compiler work is manageable. It's still a lot of work but less than re-implementing in clover... and even if we did take the clover approach we would still have to plumb clover back into the rest of our compute stack in order to avoid a lot of duplicated effort going forward.
            Last edited by bridgman; 11-22-2016, 02:54 PM.

            Comment


            • #16
              Originally posted by timofonic View Post

              WHY?

              Why not work together in a common project for it? I don't undertand how AMD uses Gallium3D for GPUs but aims at another piece of code for OpenCL, Intel has their own stuff for graphics but uses Gallium3D for OpenCL

              Are you both companies full of insane people or what? To me, both sucks and I'm against this messy way. It may corporate policy, so your corporate policies sucks. Sorry, but I just see lots of promises and very strange switchings..
              Nobody else uses clover except for nouveau, and they're barely using/supporting it. No more than AMD is, really.

              Intel has shown no desire to work on a shared OpenCL codebase, and obviously NVidia won't either.

              So, if AMD has to go it alone anyway... They might as well share their code where they can, which is internally with the PRO/Windows driver. They're still using the LLVM compiler pieces they have for GL and Clover as well.

              Comment


              • #17
                I think Nouveau want to support OpenCL, they just have bigger problems to work on right now.

                Comment


                • #18
                  I look forward to ROC and having that OpenCL stack.

                  Comment


                  • #19
                    Originally posted by bridgman View Post
                    so going with clover and hoping other vendors would do the same made sense (although the "other vendors" part didn't really happen)
                    As AMD are focusing efforts on ROCm, can nouveau use it or they will have to do the whole plumbing/working on clover to have OpenCL?

                    Comment


                    • #20
                      The reason OpenCL is to stay, and not being replaced by Vulkan is that there are lots of libraries built on OpenCL.
                      Those are tested to have the right outputs (accuracy matters) and good enough performance for the different vendors.

                      The complete rewrite of all libraries to Vulkan code is just not interesting (Although there could be gains by removing some weird OpenCL issues... For example on AMD catalyst apparently if you set the parameters for the call on a given kernel whereas another kernel with same name is running, then it will wait for the gpu to complete the previous work.... That makes OpenCV much slower than it could be (all basic arithmetic operations use a kernel named identical) ... I've seen some complaints about that in their forums, and that totally explains what I see when debugging openCV with GPUPerfStudio)

                      Comment

                      Working...
                      X