4 ms·

I think they're referring to https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

jsheard 2y ago
I know that's what they're referring to. If you're concerned about Microsoft gaining undue influence over Vulkan/SPIR-V then rest assured they already effectively controlled the desktop graphics landscape, however they define DirectX becomes the template for hardware vendors to follow, and Vulkan then has to follow their lead. The pattern is especially obvious with big new features like raytracing, which was added to DirectX first and then some time later added to Vulkan with an API which almost exactly mirrors how DirectX abstracts it. There are even Vulkan extensions which exist specifically to make emulating DirectX semantics easier.
- chucke1992 2y ago
  That's understandable. Control over standards has the immense value. Just like look at Nvidia's CUDA.
  - pjmlp 2y ago
    CUDA success has much to thank Intel and AMD for never providing anything with OpenCL that could be a proper alternative in developer experience, graphical debugging, libraries and stable drivers. Even OpenCL 2.x C++ standard was largely ignored or badly supported by their toolchains.
    - talldayo 2y ago
      cough cough Remind me who owns the OpenCL trademark, again? Intel and AMD weren't the ones that abandoned it. Speaking in no uncertain terms, there was a sole stakeholder that can be held responsible for letting the project die and preventing the proliferation of Open GPGPU standards. A company that has everything to gain from killing Open standards in the cradle and replacing them with proprietary alternatives. Someone with a well-known grudge against Khronos who's willing to throw an oversized wrench into the plans as long as it hurts their opponents.
      - google234123 2y ago
        Would you be willing to share the deal with Apple/Khronos relations?
        troupo 2y ago
        Apple didn't like OpenGL, rightfully, and came up with their own Metal which they released two years before first version of Vulkan was released. Now people pretend that Apple is bad because it never adopted Vulkan and never implemented the "good modern OpenGL" (which never really existed).
        jsheard 2y ago
        It runs deeper than that, during the development of WebGPU it came to light that Apple was vetoing the use of any Khronos IP whatsoever, due to a private legal dispute between them. That led to WebGPU having to re-invent the wheel with a brand new shader language because Apples lawyers wouldn't sign off on using GLSL or SPIR-V under any circumstances. The actual details of the dispute never came out, so we don't know if it has been resolved or not.
        binary132 2y ago
        Apple, refusing to use open standards, and instead demanding everyone else do things their way? Say it’s not so!
        jsheard 2y ago
        The bizarre thing is that Apple did used to cooperate with Khronos, they were involved with OpenGL and even donated the initial version of the OpenCL spec to them. Something dramatic happened behind the scenes at some point.
        pjmlp 2y ago
        Most likely related to how Khronos managed OpenCL after getting hold of it.
    - dragontamer 2y ago
      OpenCL 2.x was a major failure across the board. OpenGL and Vulkan were good though. Gotta take the wins where they exist.
      - pjmlp 2y ago
        Thanks to Intel and AMD.
        dragontamer 2y ago
        NVidia never even implemented OpenCL 2.0 AMD had a buggy version. Intel had no dGPIs so no one cared how well an iGPU ran OpenCL (be it 1.3 or 2.0) -------- AMD was clearly pushing C++ AMP at the time with Microsoft. And IMO, it worked great!! Alas, no one uses it so that died.
        pjmlp 2y ago
        Don't blame NVidia for Intel and AMD failures to support OpenCL.
        talldayo 2y ago
        Olympics-tier mental gymnastics, considering Apple treated both Intel and AMD as manufacturing partners at the time.
    - winwang 2y ago
      Isn't the point of OpenCL to be... open? Not only did Intel and AMD not provide enough value, but neither did the community. CUDA... is kind of annoying. And yet, it's the best experience (for GPGPU), as far as I can tell. I feel like it says something that CUDA sets a standard for GPGPU (i.e. its visible runtime API) but others still fail to catch up.
      - cogman10 2y ago
        The problem is the OpenCL development model is just garbage. Compare the hello world of OpenCL [1] vs CUDA [2]. So much boilerplate and low level complexity for doing OpenCL whereas the CUDA example is just a few simple lines using the cuda compiler. And what really sucks is it's pretty hard to get away from that complexity the way OpenCL is structured. You simply have to know WAY too much about the hardware of the machine you are running on, which means having the intel/amd/nvidia routes in your application logic when trying to make an OpenCL app. Meanwhile, CUDA, because it's unapologetically just for nVidia cards, completely does away with that complexity in the happy path. For something to be competitive with CUDA, the standard needs something like a platform agnostic bytecode to target so a common accelerated platform can scoop up the bytecode and run it on a given platform. [1] https://github.com/intel/compute-samples/blob/master/compute_samples/applications/usm_hello_world/src/usm_hello_world.cpp https://github.com/intel/compute-samples/blob/master/compute... [2] https://github.com/premprakashp/cuda-hello-world https://github.com/premprakashp/cuda-hello-world
        winwang 2y ago
        Yeah, not just OpenCL, but even "newer" standards like WebGPU. I considered making a blog post where I just put the two hello worlds side-by-side and say nothing else. I was severely disappointed after seeing people praise WebGPU (I believe for being better than OpenGL). As for the platform-agnostic bytecode, that's where something like MLIR would work too (kind of). But we could also simply just start with transpiling that bytecode into CUDA/PTX. Better UX with wider platform compatibility: CuPy, Triton.
plorkyeran 2y ago
Yes, obviously. It is an incredibly tiresome comment which is brought up every single time that Microsoft adopts any sort of open standard and it's never done with any particular insight into if this is one of the times that it'll be relevant.
- saurik 2y ago
  Has it ever not ended up being relevant? Like, I would agree that it is kind of redundant--and thereby maybe doesn't need to be said--but if there are people who actually think "maybe this time will be different", arguably the comment should be pinned to the top of the thread as a reminder?

jsheard 2y ago

I know that's what they're referring to. If you're concerned about Microsoft gaining undue influence over Vulkan/SPIR-V then rest assured they already effectively controlled the desktop graphics landscape, however they define DirectX becomes the template for hardware vendors to follow, and Vulkan then has to follow their lead. The pattern is especially obvious with big new features like raytracing, which was added to DirectX first and then some time later added to Vulkan with an API which almost exactly mirrors how DirectX abstracts it. There are even Vulkan extensions which exist specifically to make emulating DirectX semantics easier.

chucke1992 2y ago
That's understandable. Control over standards has the immense value. Just like look at Nvidia's CUDA.
- pjmlp 2y ago
  CUDA success has much to thank Intel and AMD for never providing anything with OpenCL that could be a proper alternative in developer experience, graphical debugging, libraries and stable drivers. Even OpenCL 2.x C++ standard was largely ignored or badly supported by their toolchains.
  - talldayo 2y ago
    cough cough Remind me who owns the OpenCL trademark, again? Intel and AMD weren't the ones that abandoned it. Speaking in no uncertain terms, there was a sole stakeholder that can be held responsible for letting the project die and preventing the proliferation of Open GPGPU standards. A company that has everything to gain from killing Open standards in the cradle and replacing them with proprietary alternatives. Someone with a well-known grudge against Khronos who's willing to throw an oversized wrench into the plans as long as it hurts their opponents.
    - google234123 2y ago
      Would you be willing to share the deal with Apple/Khronos relations?
      - troupo 2y ago
        Apple didn't like OpenGL, rightfully, and came up with their own Metal which they released two years before first version of Vulkan was released. Now people pretend that Apple is bad because it never adopted Vulkan and never implemented the "good modern OpenGL" (which never really existed).
        jsheard 2y ago
        It runs deeper than that, during the development of WebGPU it came to light that Apple was vetoing the use of any Khronos IP whatsoever, due to a private legal dispute between them. That led to WebGPU having to re-invent the wheel with a brand new shader language because Apples lawyers wouldn't sign off on using GLSL or SPIR-V under any circumstances. The actual details of the dispute never came out, so we don't know if it has been resolved or not.
        binary132 2y ago
        Apple, refusing to use open standards, and instead demanding everyone else do things their way? Say it’s not so!
        jsheard 2y ago
        The bizarre thing is that Apple did used to cooperate with Khronos, they were involved with OpenGL and even donated the initial version of the OpenCL spec to them. Something dramatic happened behind the scenes at some point.
        pjmlp 2y ago
        Most likely related to how Khronos managed OpenCL after getting hold of it.
  - dragontamer 2y ago
    OpenCL 2.x was a major failure across the board. OpenGL and Vulkan were good though. Gotta take the wins where they exist.
    - pjmlp 2y ago
      Thanks to Intel and AMD.
      - dragontamer 2y ago
        NVidia never even implemented OpenCL 2.0 AMD had a buggy version. Intel had no dGPIs so no one cared how well an iGPU ran OpenCL (be it 1.3 or 2.0) -------- AMD was clearly pushing C++ AMP at the time with Microsoft. And IMO, it worked great!! Alas, no one uses it so that died.
        pjmlp 2y ago
        Don't blame NVidia for Intel and AMD failures to support OpenCL.
        talldayo 2y ago
        Olympics-tier mental gymnastics, considering Apple treated both Intel and AMD as manufacturing partners at the time.
  - winwang 2y ago
    Isn't the point of OpenCL to be... open? Not only did Intel and AMD not provide enough value, but neither did the community. CUDA... is kind of annoying. And yet, it's the best experience (for GPGPU), as far as I can tell. I feel like it says something that CUDA sets a standard for GPGPU (i.e. its visible runtime API) but others still fail to catch up.
    - cogman10 2y ago
      The problem is the OpenCL development model is just garbage. Compare the hello world of OpenCL [1] vs CUDA [2]. So much boilerplate and low level complexity for doing OpenCL whereas the CUDA example is just a few simple lines using the cuda compiler. And what really sucks is it's pretty hard to get away from that complexity the way OpenCL is structured. You simply have to know WAY too much about the hardware of the machine you are running on, which means having the intel/amd/nvidia routes in your application logic when trying to make an OpenCL app. Meanwhile, CUDA, because it's unapologetically just for nVidia cards, completely does away with that complexity in the happy path. For something to be competitive with CUDA, the standard needs something like a platform agnostic bytecode to target so a common accelerated platform can scoop up the bytecode and run it on a given platform. [1] https://github.com/intel/compute-samples/blob/master/compute_samples/applications/usm_hello_world/src/usm_hello_world.cpp https://github.com/intel/compute-samples/blob/master/compute... [2] https://github.com/premprakashp/cuda-hello-world https://github.com/premprakashp/cuda-hello-world
      - winwang 2y ago
        Yeah, not just OpenCL, but even "newer" standards like WebGPU. I considered making a blog post where I just put the two hello worlds side-by-side and say nothing else. I was severely disappointed after seeing people praise WebGPU (I believe for being better than OpenGL). As for the platform-agnostic bytecode, that's where something like MLIR would work too (kind of). But we could also simply just start with transpiling that bytecode into CUDA/PTX. Better UX with wider platform compatibility: CuPy, Triton.

plorkyeran 2y ago

Yes, obviously. It is an incredibly tiresome comment which is brought up every single time that Microsoft adopts any sort of open standard and it's never done with any particular insight into if this is one of the times that it'll be relevant.

saurik 2y ago
Has it ever not ended up being relevant? Like, I would agree that it is kind of redundant--and thereby maybe doesn't need to be said--but if there are people who actually think "maybe this time will be different", arguably the comment should be pinned to the top of the thread as a reminder?