4 ms·

I'd ask why wouldn't they. Not a fan of NIH and wheel reinvention proponents.

by shmerl 1y ago

departure4885 1y ago
Because if they write their own they get to own the political/bureaucratic portion of the problem. For better or worse, they don't have to deal with the Kronos Group. They get to optimize their APIs directly against their research with AMD.
- shmerl 1y ago
  That still doesn't make NIH a better approach. NIH is dinosaur idea really when it comes to technology like this.
  - MBCook 1y ago
    Why would Vulkan, as opposed to a custom solution designed to target that hardware and games specifically, be a better solution? If you’re making a PS game you’re already doing tons of bespoke PS stuff. If you don’t want to deal with it there are plenty of pieces of middleware out there to help. Honestly these “where’s Vulkan” posts on every bit of 3D capable hardware feel like a stupid meme at this point as opposed to a rational question. Maybe they should just ship DX12. That’s multi-platform too.
    - shmerl 1y ago
      Because it won't tax developers with the need to learn yet another NIH. Same reason any standard exists and makes things easier for those who use it. Honestly any idea that defends NIH like this belongs with dinosaurs. NIH is a stupid meme, not the opposite of it.
      - soulbadguy 1y ago
        And most of the standard we have now starts with something similar to NIH. Vulkan itself is an offshoot of mantel from AMD. There are valid reason to have a custom api. Especially in domain like game console with hardware with long release cycle, tight performance requirement and legacy (ps4) code to support.
        shmerl 1y ago
        Good, but if it's actually a standard - that's the benefit. If it's not - it's just NIH as in lock-in.
      - pjmlp 1y ago
        Vulkan is a mess as bad as OpenGL, to the point Khronos has been forced to public admit it didn't went out as planned, is yet again an extension spaghetti, and they are now trying to clean the house with the Vulkan Roadmap introduced at Vulkanised 2025. That is how good Khronos "design by commitee APIs" end up being.
        shmerl 1y ago
        This comment is just a bunch of bunk, but regardless, Vulkan is the only thing that's a collaborative effort, whether it's a mess or not. NIH proponents have nothing to offer as an alternative.
        pjmlp 1y ago
        Market and tooling, industry has usually ignored Khronos APIs when multiple APIs are available to chose from, e.g. Nintendo Switch.
        MindSpunk 1y ago
        Vulkan's extension story is a mess. Not surprising from the people that brought you OpenGL. However please don't undersell what they got right. Because what they got right, they got _very_ right. Barriers. Vulkan got barriers so absolutely right that every competing API has now adopted a clone of Vulkan's barrier API. The API is cumbersome but brutally unambiguous compared to DirectX's resource states or Metal's hazard tracking. DirectX has a rats nest of special cases in the resource state API because of how inexpressive it is, and just straight up forgot to consider COPY->COPY barriers. We also have SPIR-V. Again, D3D12 plans to dump DXIL and adopt SPIR-V. The fundamentals Vulkan got very right IMO. It's a shame it gets shackled to the extension mess.
        pjmlp 1y ago
        SPIR-V only exists to reaction of Khronos losing to CUDA and PTX, it is the evolution of SPIR, created when they realised industry didn't really want to write OpenCL in a textual form of C99 dialect, rather bytecode formats targeted by multiple compiler backends, including Fortran ignored by Khronos. Microsoft adopting SPIR-V as DXIL replacement is most likely a matter of convenience, the format got messy to maintain, is tied to an old fork of LLVM, and HLSL has gotten the industy weight, even favoured over GLSL for Vulkan (which Khronos acknowledge at Vulkanised 2024 not doing any work at all, zero, nada), so why redo DXIL from scratch, when they could capitalize on existing work to target SPIR-V from HLSL.
    - Keyframe 1y ago
      Why would Vulkan, as opposed to a custom solution designed to target that hardware and games specifically, be a better solution? Vulkan came to be as a low-overhead rendering API targeted at 3D video games made originally, as Mantle, by both AMD and DICE. If anything, I'd see any console or game people involved with this as a bad signal, considering what a travesty Vulkan came to be and that one originated from such a group.
MindSpunk 1y ago
Sony's low level APIs for PS4 and PS5 (it doesn't use GNM) is almost a direct mapping to the hardware with very little abstraction compared to Vulkan/DX12. Vulkan is still very high level compared to what's going on inside the driver. There's no point paying the cost of Vulkan's abstractions when half the point of a game console is to have a fixed hardware target, hence GNM.
- shmerl 1y ago
  It's basically same AMD GPU and you can compile SPIR-V into its machine code optimally without any kind of made up "I'm closer than close to the hardware" secrets. Compiler optimizations are done all the time (see Valve's aco and AMD's llvm based compiler). Vulkan is more than adequate to handle things for the hardware on the API side so I don't buy the claim that they are somehow "closer than close" to be better.

I'd ask why wouldn't they. Not a fan of NIH and wheel reinvention proponents.

by shmerl 1y ago

I'd ask why wouldn't they. Not a fan of NIH and wheel reinvention proponents.

Because if they write their own they get to own the political/bureaucratic portion of the problem. For better or worse, they don't have to deal with the Kronos Group. They get to optimize their APIs directly against their research with AMD.

shmerl 1y ago
That still doesn't make NIH a better approach. NIH is dinosaur idea really when it comes to technology like this.
- MBCook 1y ago
  Why would Vulkan, as opposed to a custom solution designed to target that hardware and games specifically, be a better solution? If you’re making a PS game you’re already doing tons of bespoke PS stuff. If you don’t want to deal with it there are plenty of pieces of middleware out there to help. Honestly these “where’s Vulkan” posts on every bit of 3D capable hardware feel like a stupid meme at this point as opposed to a rational question. Maybe they should just ship DX12. That’s multi-platform too.
  - shmerl 1y ago
    Because it won't tax developers with the need to learn yet another NIH. Same reason any standard exists and makes things easier for those who use it. Honestly any idea that defends NIH like this belongs with dinosaurs. NIH is a stupid meme, not the opposite of it.
    - soulbadguy 1y ago
      And most of the standard we have now starts with something similar to NIH. Vulkan itself is an offshoot of mantel from AMD. There are valid reason to have a custom api. Especially in domain like game console with hardware with long release cycle, tight performance requirement and legacy (ps4) code to support.
      - shmerl 1y ago
        Good, but if it's actually a standard - that's the benefit. If it's not - it's just NIH as in lock-in.
    - pjmlp 1y ago
      Vulkan is a mess as bad as OpenGL, to the point Khronos has been forced to public admit it didn't went out as planned, is yet again an extension spaghetti, and they are now trying to clean the house with the Vulkan Roadmap introduced at Vulkanised 2025. That is how good Khronos "design by commitee APIs" end up being.
      - shmerl 1y ago
        This comment is just a bunch of bunk, but regardless, Vulkan is the only thing that's a collaborative effort, whether it's a mess or not. NIH proponents have nothing to offer as an alternative.
        pjmlp 1y ago
        Market and tooling, industry has usually ignored Khronos APIs when multiple APIs are available to chose from, e.g. Nintendo Switch.
      - MindSpunk 1y ago
        Vulkan's extension story is a mess. Not surprising from the people that brought you OpenGL. However please don't undersell what they got right. Because what they got right, they got _very_ right. Barriers. Vulkan got barriers so absolutely right that every competing API has now adopted a clone of Vulkan's barrier API. The API is cumbersome but brutally unambiguous compared to DirectX's resource states or Metal's hazard tracking. DirectX has a rats nest of special cases in the resource state API because of how inexpressive it is, and just straight up forgot to consider COPY->COPY barriers. We also have SPIR-V. Again, D3D12 plans to dump DXIL and adopt SPIR-V. The fundamentals Vulkan got very right IMO. It's a shame it gets shackled to the extension mess.
        pjmlp 1y ago
        SPIR-V only exists to reaction of Khronos losing to CUDA and PTX, it is the evolution of SPIR, created when they realised industry didn't really want to write OpenCL in a textual form of C99 dialect, rather bytecode formats targeted by multiple compiler backends, including Fortran ignored by Khronos. Microsoft adopting SPIR-V as DXIL replacement is most likely a matter of convenience, the format got messy to maintain, is tied to an old fork of LLVM, and HLSL has gotten the industy weight, even favoured over GLSL for Vulkan (which Khronos acknowledge at Vulkanised 2024 not doing any work at all, zero, nada), so why redo DXIL from scratch, when they could capitalize on existing work to target SPIR-V from HLSL.
  - Keyframe 1y ago
    Why would Vulkan, as opposed to a custom solution designed to target that hardware and games specifically, be a better solution? Vulkan came to be as a low-overhead rendering API targeted at 3D video games made originally, as Mantle, by both AMD and DICE. If anything, I'd see any console or game people involved with this as a bad signal, considering what a travesty Vulkan came to be and that one originated from such a group.

MindSpunk 1y ago

Sony's low level APIs for PS4 and PS5 (it doesn't use GNM) is almost a direct mapping to the hardware with very little abstraction compared to Vulkan/DX12. Vulkan is still very high level compared to what's going on inside the driver. There's no point paying the cost of Vulkan's abstractions when half the point of a game console is to have a fixed hardware target, hence GNM.

shmerl 1y ago
It's basically same AMD GPU and you can compile SPIR-V into its machine code optimally without any kind of made up "I'm closer than close to the hardware" secrets. Compiler optimizations are done all the time (see Valve's aco and AMD's llvm based compiler). Vulkan is more than adequate to handle things for the hardware on the API side so I don't buy the claim that they are somehow "closer than close" to be better.