Apple’s WebKit team has just announced their proposal for WebGPU, which competes with WebGL to provide graphics and GPU compute to websites. Being from Apple, it is based on the Metal API, so it has a lot of potential, especially as a Web graphics API.
Okay, so I have mixed feelings about this announcement.
First, and most concerning, is that Apple has attempted to legally block open standards in the past. For instance, when The Khronos Group created WebCL based on OpenCL, which Apple owns the trademark and several patents to, Apple shut the door on extending their licensing agreement to the new standard. If the W3C considers Apple’s proposal, they should be really careful about what legal control they allow Apple to retain.
From a functionality standpoint, this is very interesting, though. With the aforementioned death of WebCL, as well as the sluggish progress of WebGL Compute Shaders, there’s a lot of room to use one (or more) GPUs in a system for high-end compute tasks. Even if you are not interested in gaming on a web browser, although many people are, especially if you count the market that Adobe Flash dominated for the last ten years, you might want to GPU-accelerate photo and video tasks. Having an API that allows for this would be very helpful going forward, although, as stated, others are working on it, like The Khronos Group with WebGL compute shaders. On the other-other hand, an API that allows explicit multi-GPU would be even more interesting.
Further, it sounds like they’re even intending to ingest byte-code, like what DirectX 12 and Vulkan are doing with DXIL and SPIR-V, respectively, but it currently accepts shader code as a string and compiles it in the driver. This is interesting from a security standpoint, because it obfuscates what GPU-executed code consists of, but that’s up to the graphics and browser vendors to figure out… for now.
So when will we see it? No idea! There’s an experimental WebKit patch, which requires the Metal API, and an API proposal… a couple blog posts… a tweet or two… and that’s about it.
So what do you think? Does the API sound interesting? Does Apple’s involvement scare you? Or does getting scared about Apple’s involvement annoy you? Comment away! : D
If Apple is blocking OpenCL
If Apple is blocking OpenCL in a non FRAND way after having it accepted by a standards body like Khronos then why is Khronos not devising a new standard around a different name that Apple does not own the rights to. OpenCL is converted into SPIR-V just like Vulkan uses so why not just go with a new standard the does not utilize any Apple trademarked/patented IP. Why is OpenCL part of any standard when Vulkan can be made to do both graphics and compute, and there are other high level languages that can be compiled into SPIR-V and ingested by the Vulkan API. I say they should create WebVulkan convert to the SPIR-V IL and send that to be ingested into the Vulkan graphics/compute abstraction level and be done with Apple for good.
AMD’s HSA foundation HSAIL is also going to be supported by some. Why is Apple’s technology for its closed ecosystem even accepted into any open standards organization’s code base/IP base in the first place.
Just cut Apple out of the loop and rename OpenCL to something different and expunge any Apple IP.
“it is based on the Metal API, so it has a lot of potential”, really it has even less potential than DX12 has for M$, as Metal is likewise restricted to Apple’s OS ecosystem. I’m all for going to Vulkan and having the widest install base across the most OSs and forget about any proprietary solutions that are only holding back true progress!
Apple claims it prevented
Apple claims it prevented 1984 from being like 1984. But 2017 is now fully like 1984 and with Apple in charge open solutions are being blocked. I just asked this question about their patent which blocked WebCL http://patents.stackexchange.com/questions/17372/isnt-this-patent-too-general