6 ms·

Vulkan and OpenCL will merge into a single API

147 points by mattiemass 9y ago

happycube 9y ago
I figure there were good reasons why not to, but this really should've been done for Vulcan 1.0.
- Svenstaro 9y ago
  They had to get it out of the door at some point. The industry support they received was tremendous as it was and I imagine more waiting would have made some people there very nervous. I think it turned out well as it did.
- Keyframe 9y ago
  I guess it would have if it could have. It's also about politics. Strong support for Vulcan, after it came out, made this possible.
SoapSeller 9y ago
Great, we may finally see good(as in performant) OpenCL support from Nvidia.
- roel_v 9y ago
  OpenCL performance isn't the problem on NVidia, it's the lack of suppport for OpenCL 2.x.
  - robert_foss 9y ago
    I would say that both parts are pretty bad. NVidia has no interest in competing with its own propietary compute language, CUDA.
- ioquatix 9y ago
  Building OpenCL into Vulkan to try and force NVidia's hand probably isn't going to work out well.
protomyth 9y ago
I wonder what the means for Apple and their desire for Metal over Vulkan?
- infinisil 9y ago
  I really hope they'll catch that train, it may be their last chance to get onto tomorrows graphics stack
  - deleted 9y ago
    [deleted]
  - MBCook 9y ago
    I think Apple has made it abundantly clear they don't care. They've never released terribly good or performant open GL drivers on OS X. My understanding is they've always been quite behind on features. Apple has an API they make that will be nice and fast and do everything they want and they can update anytime they want. And because it's the same one it's going to be used on iOS and other places it will have support and people use it. There will be tooling for it. They tried open CL and lost, along with their approach on the Mac Pro, I don't really see them going forward with it. It seems pretty clear that CUDA is what people really want right now, that's another proprietary API. I'm not sure what the big drive for having Vulcan on Apple platforms is other than to be on the "standard". That gives Apple some benefits but they don't seem to think it's worth it. I'm not entirely sure they're wrong, especially given that Apple can make an API that fits very well with their custom chip that they put in hundreds of millions of devices. The fact that Apple operates the whole stack lets them do some of the stuff they do faster than anyone else, using Vulcan wouldn't give them that.
    - pcwalton 9y ago
      > The fact that Apple operates the whole stack lets them do some of the stuff they do faster than anyone else, using Vulcan wouldn't give them that. There isn't anything I'm aware of that Metal can do faster than Vulkan can. The situation is simply that Apple doesn't care, since they're invested in Metal and see no reason to switch. Developers are forced to use Metal because it's the only thing Apple supports, and Apple sees no reason to make it easier to port applications to competing platforms. This decision may or may not be a conscious effort to create lock-in, but whether malicious or not, it hurts developers like me who have to develop modern cross-platform graphics applications.
eriknstr 9y ago
Great, maybe we'll finally get OpenCL support in the proprietary Nvidia driver for FreeBSD? And then maybe CUDA support in their driver also? One can hope/dream.
roel_v 9y ago
This is not true! The International Workshop on OpenCL was held this past week in Toronto (OpenCL 2.2 was announced there), and there was a session with several Khronos project leaders (including the chair). The future of OpenCL was a big topic and they explicitly said that this has not been decided yet. Yes, it probably makes sense to merge the Vulkan and OpenCL SPIR-V flavors more, but that's not 'Vulkan anf OpenCL will merge'. If anyone reading this was at the conference too and heard something different, please chime in - but if what this article says was said there, it must have been in a parallel conference with people saying the opposite things than what I heard.
- roel_v 9y ago
  A bit more context after having re-read the OP: consider the following diagrams: - https://www.khronos.org/assets/uploads/apis/2016-spir-10.jpg - https://streamhpc.com/wp-content/uploads/2015/05/khronos-SPIR-V-flowchart-550x323.png The core thing to understand is that (a bit simplified) both Vulkan and OpenCL (as of 2.2) run on SPIR-V IL. So in that context (with that common foundation for both API's in the near future - well, depending on your definition of 'near' I guess...), it makes sense that someone at Khronos might have said something about 'converging' - large parts of the ecosystem can be shared (compilers/transpilers, tools, ...), some parts of the API's might be 'aligned' more, ... But 'converging' is not 'OpenCL will be folded into the Vulkan API', which I think is an overhasty conclusion by the author of OP. If anything (at least, this was my impression from the conference), the big new things for OpenCL are on devices that are not GPU's (well, on FPGA's, to be more precise). This might require some specific support (for features) that don't have a place in Vulkan at all. That's not saying that the alluded to 'aligning' or 'converging' can't happen, but there is no One API To Rule Them All ('them' = graphics and compute). So, to conclude: I see why the author would draw the conclusion he did, and if what he cites really are literal citations then maybe the Khronos communication could have been a bit more clear, but I don't think this conclusion is correct.
  - ScottMichaud 9y ago
    Hello. I'm the author of the PC Perspective story that this post cites. https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-Merging-Roadmap-Vulkan https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-M... I am currently writing up another post, which is based on an interview I did with Tom Olson (Chairman of Vulkan) and Neil Trevett (President of Khronos Group) on Friday. While the implications of the announcement are smaller than I speculated (ex: the Khronos Group weren't concerned about Apple's ownership over OpenCL's trademarks and a few necessary patents) the announcement is correct. Neil: "Congratulations. You win the prize for finding the extra press release hidden in the quote." I'm still digesting the dense, ~40 minute discussion, but OpenCL's roadmap is to merge into Vulkan's. There's a bunch of reasons for it (ex: OpenCL pushes FP32 support onto hardware where it doesn't make sense, like DSPs and deep-learning applications) but I'll elaborate on that with the follow-up. Might take a few days though. Also, here's Neil's presentation from IWOCL: https://www.khronos.org/developers/library/2017-iwocl https://www.khronos.org/developers/library/2017-iwocl

147 points by mattiemass 9y ago

happycube 9y ago

I figure there were good reasons why not to, but this really should've been done for Vulcan 1.0.

Svenstaro 9y ago
They had to get it out of the door at some point. The industry support they received was tremendous as it was and I imagine more waiting would have made some people there very nervous. I think it turned out well as it did.
Keyframe 9y ago
I guess it would have if it could have. It's also about politics. Strong support for Vulcan, after it came out, made this possible.

SoapSeller 9y ago

Great, we may finally see good(as in performant) OpenCL support from Nvidia.

roel_v 9y ago
OpenCL performance isn't the problem on NVidia, it's the lack of suppport for OpenCL 2.x.
- robert_foss 9y ago
  I would say that both parts are pretty bad. NVidia has no interest in competing with its own propietary compute language, CUDA.
ioquatix 9y ago
Building OpenCL into Vulkan to try and force NVidia's hand probably isn't going to work out well.

protomyth 9y ago

I wonder what the means for Apple and their desire for Metal over Vulkan?

infinisil 9y ago
I really hope they'll catch that train, it may be their last chance to get onto tomorrows graphics stack
- deleted 9y ago
  [deleted]
- MBCook 9y ago
  I think Apple has made it abundantly clear they don't care. They've never released terribly good or performant open GL drivers on OS X. My understanding is they've always been quite behind on features. Apple has an API they make that will be nice and fast and do everything they want and they can update anytime they want. And because it's the same one it's going to be used on iOS and other places it will have support and people use it. There will be tooling for it. They tried open CL and lost, along with their approach on the Mac Pro, I don't really see them going forward with it. It seems pretty clear that CUDA is what people really want right now, that's another proprietary API. I'm not sure what the big drive for having Vulcan on Apple platforms is other than to be on the "standard". That gives Apple some benefits but they don't seem to think it's worth it. I'm not entirely sure they're wrong, especially given that Apple can make an API that fits very well with their custom chip that they put in hundreds of millions of devices. The fact that Apple operates the whole stack lets them do some of the stuff they do faster than anyone else, using Vulcan wouldn't give them that.
  - pcwalton 9y ago
    > The fact that Apple operates the whole stack lets them do some of the stuff they do faster than anyone else, using Vulcan wouldn't give them that. There isn't anything I'm aware of that Metal can do faster than Vulkan can. The situation is simply that Apple doesn't care, since they're invested in Metal and see no reason to switch. Developers are forced to use Metal because it's the only thing Apple supports, and Apple sees no reason to make it easier to port applications to competing platforms. This decision may or may not be a conscious effort to create lock-in, but whether malicious or not, it hurts developers like me who have to develop modern cross-platform graphics applications.

eriknstr 9y ago

Great, maybe we'll finally get OpenCL support in the proprietary Nvidia driver for FreeBSD? And then maybe CUDA support in their driver also? One can hope/dream.

roel_v 9y ago

This is not true! The International Workshop on OpenCL was held this past week in Toronto (OpenCL 2.2 was announced there), and there was a session with several Khronos project leaders (including the chair). The future of OpenCL was a big topic and they explicitly said that this has not been decided yet. Yes, it probably makes sense to merge the Vulkan and OpenCL SPIR-V flavors more, but that's not 'Vulkan anf OpenCL will merge'. If anyone reading this was at the conference too and heard something different, please chime in - but if what this article says was said there, it must have been in a parallel conference with people saying the opposite things than what I heard.

roel_v 9y ago
A bit more context after having re-read the OP: consider the following diagrams: - https://www.khronos.org/assets/uploads/apis/2016-spir-10.jpg - https://streamhpc.com/wp-content/uploads/2015/05/khronos-SPIR-V-flowchart-550x323.png The core thing to understand is that (a bit simplified) both Vulkan and OpenCL (as of 2.2) run on SPIR-V IL. So in that context (with that common foundation for both API's in the near future - well, depending on your definition of 'near' I guess...), it makes sense that someone at Khronos might have said something about 'converging' - large parts of the ecosystem can be shared (compilers/transpilers, tools, ...), some parts of the API's might be 'aligned' more, ... But 'converging' is not 'OpenCL will be folded into the Vulkan API', which I think is an overhasty conclusion by the author of OP. If anything (at least, this was my impression from the conference), the big new things for OpenCL are on devices that are not GPU's (well, on FPGA's, to be more precise). This might require some specific support (for features) that don't have a place in Vulkan at all. That's not saying that the alluded to 'aligning' or 'converging' can't happen, but there is no One API To Rule Them All ('them' = graphics and compute). So, to conclude: I see why the author would draw the conclusion he did, and if what he cites really are literal citations then maybe the Khronos communication could have been a bit more clear, but I don't think this conclusion is correct.
- ScottMichaud 9y ago
  Hello. I'm the author of the PC Perspective story that this post cites. https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-Merging-Roadmap-Vulkan https://www.pcper.com/reviews/General-Tech/Breaking-OpenCL-M... I am currently writing up another post, which is based on an interview I did with Tom Olson (Chairman of Vulkan) and Neil Trevett (President of Khronos Group) on Friday. While the implications of the announcement are smaller than I speculated (ex: the Khronos Group weren't concerned about Apple's ownership over OpenCL's trademarks and a few necessary patents) the announcement is correct. Neil: "Congratulations. You win the prize for finding the extra press release hidden in the quote." I'm still digesting the dense, ~40 minute discussion, but OpenCL's roadmap is to merge into Vulkan's. There's a bunch of reasons for it (ex: OpenCL pushes FP32 support onto hardware where it doesn't make sense, like DSPs and deep-learning applications) but I'll elaborate on that with the follow-up. Might take a few days though. Also, here's Neil's presentation from IWOCL: https://www.khronos.org/developers/library/2017-iwocl https://www.khronos.org/developers/library/2017-iwocl