10 ms·

Quoted from the article: "OpenCL works fine on NVIDIA cards, but performance is reasonably slower (up to 2x slowdown) compared to CUDA, so it doesn't really wo

• jacquesm 10y ago
  > I wonder if that's intentional on NVIDIA's part. I highly doubt it, a normal resource allocation conflict would suffice. NVIDIA has everything to gain by being ahead on each and every metric and to purposefully hobble that would eventually come out and would make people decide to buy a non-NVIDIA product in the meantime. I think the reason is more that NVIDIA has been able to tailor CUDA to a much larger degree to match the architecture of their cards and by extension anybody that writes for CUDA automatically benefits from that. OpenCL is more general but that also immediately implies that it will be less efficient. And it doesn't take all that much in terms of missing optimizations (a single memory fetch penalty would do) to get a 2x penalty. GPU programming is much less forgiving when it comes to subtle mistakes than regular programming because it immediately gets multiplied by a very large factor rather than a single missed cycle. A nice example of the reverse: ATI cards dominated the bitcoin GPU mining scene because of their ability to do a particular operation in one clocktick instead of two on the NVIDIA cards.
  • thomastjeffery 10y ago
    The real issue is that NVIDIA does not care about OpenCL as long as CUDA is usable. Since their drivers are proprietary, no one else (who does care) can make better OpenCL support happen.
• robbies 10y ago
  "I wonder if that's intentional on NVIDIA's part." I think that's a reasonable guess. NVIDIA only supports OpenCL 1.2 (and it took them about 6 years to get there from 1.0, while other vendors were at 2.x). While I don't think NVIDIA ever outright stated OpenCL was on the back burner, their support clearly waned, which devs noticed (https://streamcomputing.eu/blog/2012-09-10/nvidias-industry-leading-support-for-opencl/ https://streamcomputing.eu/blog/2012-09-10/nvidias-industry-...). As for why...well, why should NVIDIA participate? They don't have anything to gain when they already have CUDA dominating the industry.
  • intoverflow2 10y ago
    > They don't have anything to gain when they already have CUDA dominating the industry Everyone working in it seems to agree there are good reasons for it dominating. Just easier to work with overall.
    • robert_foss 10y ago
      You're implying OpenCL being broken somehow. Is it broken in any way?
      • deleted 10y ago
        [deleted]
      • bostonpete 10y ago
        I don't see how "easier to work with" implies "broken".
        • apetresc 10y ago
          The GP was saying CUDA was "easier to work with", not OpenCL. OpenCL's broken-ness then presumably is that it's hard to work with.
    • dom0 10y ago
      In the long run every monopoly hurts badly. Puzzling that people think it's good for GPGU, with the x86 fiasco next door.
      • hvs 10y ago
        (Most) people don't make decisions based on overarching theories of what's good for everyone. They need to solve a problem as easy as possible and most people feel that CUDA is easier to use than OpenCL. Plus, NVidia has been a leader in this space. Also, this isn't a monopoly, OpenCL exists.
• pavanky 10y ago
  I don't think it has anything to do with the driver itself. At least in my experience, the custom code you write performs more or less the same across both CUDA and OpenCL. The issues arise when you are using the toolkit libraries (like BLAS and FFT). cuBLAS and cuFFT are much much tuned for NVIDIA hardware than any OpenCL versions available at the moment.
  • llukas 10y ago
    Are there any pain points for cuBLAS and cuFFT?
    • pavanky 10y ago
      Not really, but they are only supported in CUDA. For OpenCL you will have to use clBLAs and clFFT (written and maintained by AMD). This means they are not exactly tuned for other architectures.
      • dragandj 10y ago
        I prefer to use OpenCL, but I think the second key factor why Nvidia dominates (the first is they integrated tooling) is that cuBLAS, cuFFT, cuDNN et.al work out of the box when you install CUDA Toolkit. clBLAS and clFFT? Good luck using them even on AMD hardware, yet alone on someone else's. And, of course, there is no cuDNN equivalent (that is beyond experimental)...
  • AlphaSite 10y ago
    What about rocBLAS and rocFFT?
• opencl 10y ago
  Note that this is a wiki article, and that section in particular hasn't been updated in quite a while. Other parts of the article are talking about recent significant speedups in the OpenCL renderer so it makes me wonder how much they've closed the gap with CUDA on NVIDIA hardware. I would test myself but don't have an NVIDIA card handy.
• Athas 10y ago
  I have rarely observed that much difference between CUDA and OpenCL. I have, however, noticed that CUDA (at least by default) is more aggressive about picking faster but less accurate instructions for transcendental functions like inverse square root. You can ask for the same kind of stuff by passing extra OpenCL compiler flags, but it seems that CUDA optimises more aggressively by default (maybe analogous to the kind of stuff -ffast-math does).
  • jacobolus 10y ago
    Nitpick: inverse square root is not a transcendental function.
• Ono-Sendai 10y ago
  We produce one of the few pieces of commercial software (https://www.indigorenderer.com/ https://www.indigorenderer.com/) using OpenCL, and it works great on Nvidia cards. See https://www.indigorenderer.com/benchmark-results https://www.indigorenderer.com/benchmark-results for some benchmarks. All GPU results are using OpenCL. We used to have both an OpenCL and CUDA implementation in earlier versions. The CUDA version was slightly faster (10-15%?) on Nvidia cards, but not worth the effort of maintaining both implementations.
• deepnotderp 10y ago
  Yeah, Nvidia cripples OpenCL on their own cards. From a rational monopolist's perspective, it makes total sense.
  • jjtheblunt 10y ago
    Evidence of that assertion?
    • deepnotderp 10y ago
      Compare simple instructions on shader assembly, cuda and OpenCL
      • dogma1138 10y ago
        This only really holds true if you are running OpenCL 1.2 under CUDA. If you run native OpneCL 2.0 on NVIDIA GPUs you aren't getting a major penalty, there will still be things that CUDA is going to be faster at but that has nothing to do with intentional gimping.
• DRAGONERO 10y ago
  NVIDIA supports CL1.2 and it's intentionally slow so people will use CUDA. Plain CL2.0 shouldn't bring performance improvements unless the kernels used by Blender perform things like work_group functions. Also CL2.0 will require people to specify if a WG is uniform, otherwise they must assume it's not uniform and that's taxing in some cases. SPIR-V on the other hand should be interesting to see.