4 ms·

FWIW there have been one or two (apparent) Apple employees on here who seemed sincerely convinced that Vulkan was a mess compared to Metal. I have no idea how t

by leoc 7y ago

FWIW there have been one or two (apparent) Apple employees on here who seemed sincerely convinced that Vulkan was a mess compared to Metal. I have no idea how true that is or how much difference it actually makes, but there it is.

pjmlp 7y ago
Metal, nice OOP based tooling with several frameworks to support handling textures, fonts, materials, GPU live shader debugging, code completion on Xcode with static analysis, C++14 based shaders. Vulkan, plain old C style API, full of extensions just like OpenGL, leading to several code paths, just the bare bones pixel drawing, go fish for random libraries for anything else, try your luck with RenderDoc or GPU specific debuggers, enjoy Notepad++ + UNIX shell style tooling support.
- bilbo0s 7y ago
  I believe this is a deliberate misrepresentation of the current state of affairs on Vulkan. Likely for the purposes of spreading disinformation about a specification that legions of smart, dedicated, hardworking engineers came up with after countless hours of debate and consensus. I mean be real... there is no way that any programmer who actually used Vulkan would find it as pleasant to work with as you imply in your comment.
  - pjmlp 7y ago
    Here is the list of Vulkan extensions with device coverage. https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php Clicking a bit around, gives the Vulkan support version per device, which on Android is a mess, unless one only cares about flagship devices. https://vulkan.gpuinfo.org/listdevices.php?platform=android https://vulkan.gpuinfo.org/listdevices.php?platform=android Now regarding the tooling, since I am spreading disinformation, can you please provide us with the SDK tooling that matches the offerings from Apple, Sony, Nintendo and Microsoft, regarding their own APIs? Because what LunarG offers is pretty bare bones, and the OEM SDKs pretty much just provide the basic stuff as well, with C samples. I guess that someone that rather goes hunting for glm, uses sbt for textures, writes their own font rendering engine, compiles shaders from the command line, only knows about RenderDoc is capable of,... will feel very uncomfortable with the available set of Metal tooling and Frameworks. And this is one of the best tutorials available for Vulkan beginners, https://vulkan-tutorial.com https://vulkan-tutorial.com
    - leoc 7y ago
      (whoosh?)
    - johncolanduoni 7y ago
      Most of the extensions are for what are currently pre-production or fringe features, and the WG showed they're not afraid of pulling important (and even not so important) extensions into minor version releases much faster than OpenGL has put things in core with Vulkan 1.1 (I was glad but honestly surprised that the cross-process resource sharing made the cut). You're definitely right about significant parts of the toolchain being weaker. In particular sorting out how glslang -> Vulkan works in practice is pretty trial-and-error, and if you want to use HLSL it's even more poorly documented. You have to expect to be going through the Vulkan spec (which I will say is much easier than directly using the OpenGL spec). However the Vulkan validation layers are incredible, and leave the equivalents for Metal, DirectX, and especially OpenGL in the dust.
    - bilbo0s 7y ago
      I think you missed the joke.
    - nothrabannosir 7y ago
      It was a joke. Read the comment to the end.
  - johncolanduoni 7y ago
    I think the supposition that pjmlp is knowing mischaracterizing Vulkan is both likely to be false and excessively uncharitable (and I say that as a big fan of Vulkan). I think it's just a matter of not having had much experience with it. It is natural to look at the shape of the API and have PTSD about wrestling with OpenGL for the past few decades.
    - mrec 7y ago
      I'm pretty sure the comment you're responding to is just a switcharoo-format joke. Unless the last sentence is missing an "un" before "pleasant".
      - johncolanduoni 7y ago
        Yeah I assumed that was the omission but that makes a lot more sense lol
- derefr 7y ago
  Okay, but none of that was true in 2014. If Apple had been building an ecosystem of Vulkan tooling instead of an ecosystem of Metal tooling, presumably Vulkan would have the frameworks, the Xcode support, and (maybe) some of the debuggability (since Apple could have their drivers' Vulkan shader pipeline target LLVM IR, and then do LLVM-internal stuff from there to enable debuggability.) So what made Metal a better technical choice than Vulkan, back when the options were "Metal without Apple's support built yet" and "Vulkan without Apple's support built yet"?
  - pjmlp 7y ago
    Being almost two years older than Vulkan.
- Reelin 7y ago
  My understanding is that Vulkan is specifically supposed to be as low level as possible in order to facilitate device manufacturers creating new hardware and to give developers fine grained control over things if they want it. I believe the stated strategy is to let third party middleware handle the higher level abstractions so that different approaches that appeal to different people can coexist. This also theoretically reduces driver complexity and thus (hopefully) bugs. I have absolutely no idea if this is actually a good idea, or if it's working out in practice. In case anyone wants to poke around the ecosystem: (https://github.com/vinjn/awesome-vulkan https://github.com/vinjn/awesome-vulkan).
daenz 7y ago
>seemed sincerely convinced that Vulkan was a mess compared to Metal Oh god I hope not. I come from the API mess that was OpenGL over 3 major versions, and I was hoping all the lessons learned from that were applied to Vulkan.
- thrower123 7y ago
  I think the lessons learned are being applied, but those are the lessons on how to maximize fragmentation. Graphics APIs are not good when designed by committee.

by leoc 7y ago

pjmlp 7y ago

Metal, nice OOP based tooling with several frameworks to support handling textures, fonts, materials, GPU live shader debugging, code completion on Xcode with static analysis, C++14 based shaders. Vulkan, plain old C style API, full of extensions just like OpenGL, leading to several code paths, just the bare bones pixel drawing, go fish for random libraries for anything else, try your luck with RenderDoc or GPU specific debuggers, enjoy Notepad++ + UNIX shell style tooling support.

bilbo0s 7y ago
I believe this is a deliberate misrepresentation of the current state of affairs on Vulkan. Likely for the purposes of spreading disinformation about a specification that legions of smart, dedicated, hardworking engineers came up with after countless hours of debate and consensus. I mean be real... there is no way that any programmer who actually used Vulkan would find it as pleasant to work with as you imply in your comment.
- pjmlp 7y ago
  Here is the list of Vulkan extensions with device coverage. https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php Clicking a bit around, gives the Vulkan support version per device, which on Android is a mess, unless one only cares about flagship devices. https://vulkan.gpuinfo.org/listdevices.php?platform=android https://vulkan.gpuinfo.org/listdevices.php?platform=android Now regarding the tooling, since I am spreading disinformation, can you please provide us with the SDK tooling that matches the offerings from Apple, Sony, Nintendo and Microsoft, regarding their own APIs? Because what LunarG offers is pretty bare bones, and the OEM SDKs pretty much just provide the basic stuff as well, with C samples. I guess that someone that rather goes hunting for glm, uses sbt for textures, writes their own font rendering engine, compiles shaders from the command line, only knows about RenderDoc is capable of,... will feel very uncomfortable with the available set of Metal tooling and Frameworks. And this is one of the best tutorials available for Vulkan beginners, https://vulkan-tutorial.com https://vulkan-tutorial.com
  - leoc 7y ago
    (whoosh?)
  - johncolanduoni 7y ago
    Most of the extensions are for what are currently pre-production or fringe features, and the WG showed they're not afraid of pulling important (and even not so important) extensions into minor version releases much faster than OpenGL has put things in core with Vulkan 1.1 (I was glad but honestly surprised that the cross-process resource sharing made the cut). You're definitely right about significant parts of the toolchain being weaker. In particular sorting out how glslang -> Vulkan works in practice is pretty trial-and-error, and if you want to use HLSL it's even more poorly documented. You have to expect to be going through the Vulkan spec (which I will say is much easier than directly using the OpenGL spec). However the Vulkan validation layers are incredible, and leave the equivalents for Metal, DirectX, and especially OpenGL in the dust.
  - bilbo0s 7y ago
    I think you missed the joke.
  - nothrabannosir 7y ago
    It was a joke. Read the comment to the end.
- johncolanduoni 7y ago
  I think the supposition that pjmlp is knowing mischaracterizing Vulkan is both likely to be false and excessively uncharitable (and I say that as a big fan of Vulkan). I think it's just a matter of not having had much experience with it. It is natural to look at the shape of the API and have PTSD about wrestling with OpenGL for the past few decades.
  - mrec 7y ago
    I'm pretty sure the comment you're responding to is just a switcharoo-format joke. Unless the last sentence is missing an "un" before "pleasant".
    - johncolanduoni 7y ago
      Yeah I assumed that was the omission but that makes a lot more sense lol
derefr 7y ago
Okay, but none of that was true in 2014. If Apple had been building an ecosystem of Vulkan tooling instead of an ecosystem of Metal tooling, presumably Vulkan would have the frameworks, the Xcode support, and (maybe) some of the debuggability (since Apple could have their drivers' Vulkan shader pipeline target LLVM IR, and then do LLVM-internal stuff from there to enable debuggability.) So what made Metal a better technical choice than Vulkan, back when the options were "Metal without Apple's support built yet" and "Vulkan without Apple's support built yet"?
- pjmlp 7y ago
  Being almost two years older than Vulkan.
Reelin 7y ago
My understanding is that Vulkan is specifically supposed to be as low level as possible in order to facilitate device manufacturers creating new hardware and to give developers fine grained control over things if they want it. I believe the stated strategy is to let third party middleware handle the higher level abstractions so that different approaches that appeal to different people can coexist. This also theoretically reduces driver complexity and thus (hopefully) bugs. I have absolutely no idea if this is actually a good idea, or if it's working out in practice. In case anyone wants to poke around the ecosystem: (https://github.com/vinjn/awesome-vulkan https://github.com/vinjn/awesome-vulkan).

daenz 7y ago

>seemed sincerely convinced that Vulkan was a mess compared to Metal Oh god I hope not. I come from the API mess that was OpenGL over 3 major versions, and I was hoping all the lessons learned from that were applied to Vulkan.

thrower123 7y ago
I think the lessons learned are being applied, but those are the lessons on how to maximize fragmentation. Graphics APIs are not good when designed by committee.