4 ms·

Why would Apple care about how DirectX is doing? They support 'Standards' and 'Open Source' to the extent that it benefits them and that's it. Vulkan is not de

by morio 7y ago

Why would Apple care about how DirectX is doing? They support 'Standards' and 'Open Source' to the extent that it benefits them and that's it. Vulkan is not designed to be used by game developers directly but rather as a basis for games engines like Unreal or Unity. So I don't see how game developers would benefit from its widespread support as the majority of game developers will never have to deal with it directly. That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex.

johncolanduoni 7y ago
> Vulkan is not designed to be used by game developers directly but rather as a basis for games engines like Unreal or Unity. So I don't see how game developers would benefit from its widespread support as the majority of game developers will never have to deal with it directly. Vulkan has significant benefits even if you're not writing Unreal or Unity. One of the biggest is that it removes a lot of the heuristics and guesswork that OpenGL drivers do (e.g. with regards to when to move things in and out of GPU memory) that cause a lot of the bugs and incompatibilities on different IHVs/cards/platforms. Its validation layers also leave the halfhearted, vendor specific debugging extensions in the dust. > That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex. Metal overtly has statically checked memory safety via ARC, but the reality is that the IHV libraries will segfault in response to semantic mistakes, just like Vulkan. A big difference is that Vulkan has cross-IHV validation layers that catch most of these mistakes during development, and they're only getting more comprehensive. It's totally trivial to write a wrapper over Vulkan that fixes the type/memory safety of the C interface; it's not trivial to create a validation system of anywhere near the quality of Vulkan's for Metal.
- flohofwoe 7y ago
  From what I've seen so far, Metal's own validation layer also does very thorough checks, to a point where it almost replaces the documentation (as far as the quality of the validation error messages goes).
banachtarski 7y ago
> That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex. OK are you a graphics professional? Have you written renderers in Vulkan? Do you have any idea of what you're talking about? What "void*" pointers are you referring to? Are you aware that type-safety is very much a design goal of the API? Are you aware that the spec ships with a formal memory model which is a godsend for graphics engineers that had to deal with implicit guarantees in other APIs for years? I'm not someone that authored the original spec, but reading your comment is somewhat rage-inducing given how off-base it is.

by morio 7y ago

johncolanduoni 7y ago

> Vulkan is not designed to be used by game developers directly but rather as a basis for games engines like Unreal or Unity. So I don't see how game developers would benefit from its widespread support as the majority of game developers will never have to deal with it directly. Vulkan has significant benefits even if you're not writing Unreal or Unity. One of the biggest is that it removes a lot of the heuristics and guesswork that OpenGL drivers do (e.g. with regards to when to move things in and out of GPU memory) that cause a lot of the bugs and incompatibilities on different IHVs/cards/platforms. Its validation layers also leave the halfhearted, vendor specific debugging extensions in the dust. > That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex. Metal overtly has statically checked memory safety via ARC, but the reality is that the IHV libraries will segfault in response to semantic mistakes, just like Vulkan. A big difference is that Vulkan has cross-IHV validation layers that catch most of these mistakes during development, and they're only getting more comprehensive. It's totally trivial to write a wrapper over Vulkan that fixes the type/memory safety of the C interface; it's not trivial to create a validation system of anywhere near the quality of Vulkan's for Metal.

flohofwoe 7y ago
From what I've seen so far, Metal's own validation layer also does very thorough checks, to a point where it almost replaces the documentation (as far as the quality of the validation error messages goes).

banachtarski 7y ago

> That said Vulkan is an unmitigated disaster, though less so than classic OpenGL. Any API which fiddles with void* in 2019 should be put right back in a box. Security is mentioned exactly twice in the entire spec. Type-safety is mentioned twice also. And that is in a spec which is 900 pages long and incredibly complex. OK are you a graphics professional? Have you written renderers in Vulkan? Do you have any idea of what you're talking about? What "void*" pointers are you referring to? Are you aware that type-safety is very much a design goal of the API? Are you aware that the spec ships with a formal memory model which is a godsend for graphics engineers that had to deal with implicit guarantees in other APIs for years? I'm not someone that authored the original spec, but reading your comment is somewhat rage-inducing given how off-base it is.