8

Support for OpenCL on Macs is going to end in macOS 10.15, so people invested in PyOpenCL+OpenCL as a means for doing general-purpose GPU (+CPU) compute will soon start to lose a key platform.

So my questions are:

  1. Are there any viable multiplatform GPGPU-compute alternatives to PyOpenCL+OpenCL on the horizon?
  2. Would Vulkan with a Python wrapper be a possibility?
Colin Stark
  • 301
  • 1
  • 10
  • "*Meanwhile, Khronos have signaled (if I interpret prognostications correctly) that Vulkan will soonish replace OpenCL as the framework for GPU compute*" It should be noted that that was said over a year ago, and little apparent movement has been made towards that end. The Vulkan 1.1 release did pretty much nothing to bridge the gap between Vulkan compute shaders and OpenCL. – Nicol Bolas Jul 09 '18 at 13:37
  • In their [press release](https://www.khronos.org/news/press/khronos-group-releases-vulkan-1-1) re 1.1 back in March, there was no mention of OpenCL at all. – Colin Stark Jul 09 '18 at 23:49
  • 1
    My point is that, in order for Vulkan to *replace* OpenCL, it has to be able to do everything (or at least most things) that OpenCL does. That means being able to have the same precision requirements. Being able to work in non-logical addressing modes with SPIR-V. And so forth. Vulkan 1.0 doesn't meet those requirements. Vulkan 1.1 does not add anything towards meeting those requirements. If Vulkan is going to "replace" OpenCL, it won't be happening in the near future. – Nicol Bolas Jul 10 '18 at 00:23
  • Agreed. My question is _predicated_ on the assumption that Khronos can be trusted to act on their (very scantily expressed) promise. If they can, then the issue of wrappers and compute strategies is worth raising, yes? If not, the fight moves to figuring out what the hell to do with no OpenCL support on a key platform. – Colin Stark Jul 10 '18 at 03:08
  • I fear this question to be closed as off-topic or primarily opinion based. I do have the same question though... – Dschoni Aug 01 '18 at 14:16
  • @nicol-bolas: What exactly is the issue with precision requirements? Often hear it (mosly from your comments :)) but never understood what exactly is different between the two with respect to precision. – Slava Aug 03 '18 at 09:59
  • @Slava: That sounds like good material for an SO question. – Nicol Bolas Aug 03 '18 at 13:17
  • 1
    @Dschoni : To address your concern, I modded the detailed questions into a more neutral form. The headline question, however, is not IMO opinion-based - it's a mildly provocative phrasing of a question inevitably posed by information released by Apple. – Colin Stark Aug 06 '18 at 07:48
  • @ColinStark your question is absolutely opinion based even if your title technically isn't. – Krupip Dec 18 '18 at 20:17
  • @opa: I'm pretty new to posting on SO, so please excuse any transgressions. I have drastically slimmed the question down and cut all of the opinion content (as far as I can see). Some context here: I have been developing PyOpenCL/GPU-compute code intended to support academic publications and to be shared with and used by colleagues, only to find that my favorite platform is going to end support for these tools, leaving me in a bind. I cannot be alone in this. – Colin Stark Dec 21 '18 at 07:47
  • @ColinStark You definitely aren't alone in this, but you should go for the software recommendations stack exchange for the question "Is there an alternative to OpenCL" but that question may have already been asked https://softwarerecs.stackexchange.com/. the question "can Vulkan replace OpenCL" may be too broad and opinion based. I would instead ask "What makes vulkan 1.1.92 not a replacement for OpenCL right now?" or something along those lines, and make that a new question, and say something like "I'm looking for a replacement for OpenCL and I'm wondering if I can use vulkan for that." – Krupip Dec 21 '18 at 15:12
  • 1
    I appreciate your input, but no, I think the question is fine as it is. – Colin Stark Dec 22 '18 at 04:49

1 Answers1

2

(This answer contains some practical suggestions laced with opinion and personal guesses. I'm happy to edit this answer based on comments received if some of this is considered improper here.)

My view is that the CL implementations available on macOS have always been nearly useless by how buggy they were. CL as a low-level compute abstraction on the other hand is fine IMO--its concepts still represent what happens in the hardware fairly well. I.e. whatever the next abstraction is that comes along, a subset of CL can probably be mapped to it. For example, POCL is already a more competent CPU CL implementation on macOS than Apple's ever was. (See here for installation instructions.) For GPUs, POCL has a CUDA backend that's not immensely great just yet, but with a little help, it could be what's need so that the GPU compute world can stop worrying about API churn and get back to solving actual problems.

Andreas Klöckner
  • 1,086
  • 8
  • 11
  • First of all, thanks so much for _writing_ POCL. It has been for me an immensely helpful tool, first when delving into GPU compute, and now that I'm more familiar with it. Second, thanks for responding to my oft-modded and much-critiqued question. Your final sentence re API churn is extremely apt. – Colin Stark Dec 24 '18 at 23:10