6 ms·

> I consider Vulkan to have redone the same design by committee mistakes from OpenGL Which are? (I'm genuinely interested)

by adwn 5y ago

pjmlp 5y ago
Extension spaghetti for starters, https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes,.... Now there is LunarG SDK, which still only offers a subset of these kind of features. If it wasn't for NVidia's early C++ efforts, Vulkan would still be C only. Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground, otherwise Khronos would most likely still be arguining how OpenGL vNext was supposed to look like. Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.
- nixpulvis 5y ago
  > Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend. Isn't this why Vulkan was designed the way it was. It's lower level, giving more control to things like memory. In this way I view it somewhat like the ASM of the GPU (even though though there are lower levels still). I'm curious if anyone with a lot of experience writing graphics "middleware engine" backends agrees.
  - skohan 5y ago
    Yeah exactly. Vulkan is meant to be the lowest level interface possible to the hardware. It's for programmers who hitting a wall in terms of optimization because of the overhead imposed by OpenGL or DX11. It's not intended for everyday programmers, and it would not make sense to make concessions in performance to accommodate usability concerns.
    - flohofwoe 5y ago
      But the thing is that Vulkan isn't the lowest possible hardware interface, it's still built on top of a virtual GPU abstraction which matches some GPUs better than others. There's a ton of compromises to accomodate mobile GPUs for instance. The only realistic way to achieve the goal of an actually low-level API is to have one API per major GPU architecture, and to create new APIs when new GPU architectures emerge. Attempts to abstract over radically different GPU architectures will never result in an actually explicit low-level API.
      - skohan 5y ago
        Ok yeah that's technically true, but there's always going to be a balance point. You can't expect graphics programmers to write a separate renderer for each possible hardware target. That kind of works in the console space, but in the PC space you have to account for a wide variety of hardware. There's always going to be a balance point, and Vulkan's priority is much more about getting as low-level as possible within the constraints than it is about being approachable for developers.
      - fctorial 5y ago
        > it's still built on top of a virtual GPU abstraction which matches some GPUs better than others. Doesn't khronos contain people from a bunch of different corps (amd, nvidia, intel, qualcom) for this exact reason.
        flohofwoe 5y ago
        Yeah, but that doesn't seem to have helped much to keep the Vulkan API small and tidy, instead there are dozens (or maybe hundreds by now?) of vendor-specific extensions.
        skohan 5y ago
        I think this is vastly overstated. I've done quite a bit of work for Vulkan, and have done just fine without reaching for extensions. And how else do you propose accessing hardware features which are vendor specific?
  - flohofwoe 5y ago
    The idea was probably "built it and they will come" (the library authors who provide the easier to use wrapper libraries). The problem is that these libraries are hobbyist/volunteer work (with the notable exception of native WebGPU implementations), which on its own isn't a bad thing, but hobbyist can't afford a testing lab running hundreds of GPU/driver/OS combinations to make sure that their libraries are as robust as expected. The companies who have these resources (for instance the GPU vendors), chickened out by designing Vulkan and thus offloading those QA tasks to the API users (simplified, but that's what it is in the end). Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users, which in turn are not enough to test Vulkan implementations, because just a handful API users isn't enough to cover all the dusty corners (same situation as back in the bad old days with MiniGL).
    - MegaDeKay 5y ago
      > Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users ??? For example, there are a substantial number of emulators that have already implemented or are in the middle of implementing a Vulkan backend: RPCS3, Dolphin, Yuzu, Cemu, Ryujinx, PPSSPP... these emulators are developed by small teams but often push the hardware hard, bringing bugs to light in the process.
      - gpderetta 5y ago
        Also DXVK and VK3D.
- zajio1am 5y ago
  > Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes, That seems to me like a reasonable decision that graphics API does not try to encompass and duplicate many other unrelated APIs and stays focused on graphics.
- codefreakxff 5y ago
  I completely agree. I recently decided to try learning Vulkan. I built an sdl window framework and got an OpenGL triangle in maybe 6 lines of OpenGL code. For vulkan you literally cannot draw anything until your reimplement an entire rendering engine from probing hardware, to figuring out queuing strategies, and resource management, etc. you are forced to focus your on HOW rather than WHAT to draw. I think they set the barrier of entry way too high. From a newbie perspective I’d rather have the library make smart decisions by default so I can just init and draw. But if I wanted to do more I could.
  - slavik81 5y ago
    It takes dozens of lines of code to draw a triangle in modern OpenGL. You were presumably using immediate mode, which is ancient and deprecated because it has horrible performance on modern hardware. Given that the whole point of an API for hardware accelerated graphics is better performance, that's a big problem. Immediate mode OpenGL not even a particularly friendly API, either. I found its implicit global mutable state for things like the matrix stack to be deeply confusing. There's much better drawing libraries out there if what you're looking for is ease-of-use.
    - tl 5y ago
      The removal of immediate mode from OpenGL is one of many examples of modern OpenGL's stupidity, partially responsible for creating the mess we're in: https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-...
      - slavik81 5y ago
        Immediate mode still exists and is usable to this day. The compatibility profile never went away. JWZ implemented old-school OpenGL in a library on top of a more modern API, and I would entirely agree that's a good approach to compatibility. I'd have advocated for doing the same thing, just without calling everyone idiots.
      - skohan 5y ago
- infogulch 5y ago
  > Extension spaghetti for starters Extensions are a PITA to deal with, but they generally represent real disparate hardware features offered by individual GPUs which varies by manufacturer, model, and date. This reminds me of CPU features like SSE2, AVX, AES, etc, etc which general-purpose binary programs are forced to query for at runtime to either take advantage of or fall back to a software implementation. But GPUs have even more architectural change velocity than CPUs. It seems like a hard problem in general. How do you think this could be done better?
  - skohan 5y ago
    Yeah exactly. How else can you support the wide range of hardware features out there without being stuck with a lowest-common-denominator?
    - pjmlp 5y ago
      Apple, Microsoft, Sony and Nintendo have such a hard time delivering high quality graphics with their proprietary APIs, pity them.
      - skohan 5y ago
        How does DX12 do feature discovery for things like ray tracing which are supported on only some hardware?
        pjmlp 5y ago
        By requiring DX12 Ultimate support, done.
        skohan 5y ago
        This is a very low-quality argument. Game developers quite clearly cannot only target DX12 Ultimate and have their product only work for a small percentage of users on PC. If you want to target PC, you have to deal with hardware fragmentation. You can pretend this is a Vulkan issue, but it's just a reality of the platform.
- adwn 5y ago
  > so each newbie Vulkan isn't for newbies. Really, if you're new to 3D graphics then you're not Vulkan's target audience; pretending otherwise only results in pain. That's like complaining that a modern CPU's privileged instructions are too complicated for people new to assembly – yes, they are, and no, that's not a design flaw. > Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground That's maybe a point against Khronos, not against Vulkan. > Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend. Which is exactly what people should be doing. And those middleware engines can be written using Vulkan, because it is designed the way it is.
  - pjmlp 5y ago
    My degree thesis was porting a particle engine framework from NeXTSTEP/OpenGL/Objective-C into Windows/OpenGL/C++ with MFC. Yet that doesn't mean I don't care about newbies in 2021, specially when Khronos says OpenGL isn't going to move beyond version 4.6, thus everyone new in the field feels like Vulkan is what they should learn instead.

> I consider Vulkan to have redone the same design by committee mistakes from OpenGL Which are? (I'm genuinely interested)

by adwn 5y ago

> I consider Vulkan to have redone the same design by committee mistakes from OpenGL Which are? (I'm genuinely interested)

pjmlp 5y ago

Extension spaghetti for starters, https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes,.... Now there is LunarG SDK, which still only offers a subset of these kind of features. If it wasn't for NVidia's early C++ efforts, Vulkan would still be C only. Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground, otherwise Khronos would most likely still be arguining how OpenGL vNext was supposed to look like. Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.

nixpulvis 5y ago
> Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend. Isn't this why Vulkan was designed the way it was. It's lower level, giving more control to things like memory. In this way I view it somewhat like the ASM of the GPU (even though though there are lower levels still). I'm curious if anyone with a lot of experience writing graphics "middleware engine" backends agrees.
- skohan 5y ago
  Yeah exactly. Vulkan is meant to be the lowest level interface possible to the hardware. It's for programmers who hitting a wall in terms of optimization because of the overhead imposed by OpenGL or DX11. It's not intended for everyday programmers, and it would not make sense to make concessions in performance to accommodate usability concerns.
  - flohofwoe 5y ago
    But the thing is that Vulkan isn't the lowest possible hardware interface, it's still built on top of a virtual GPU abstraction which matches some GPUs better than others. There's a ton of compromises to accomodate mobile GPUs for instance. The only realistic way to achieve the goal of an actually low-level API is to have one API per major GPU architecture, and to create new APIs when new GPU architectures emerge. Attempts to abstract over radically different GPU architectures will never result in an actually explicit low-level API.
    - skohan 5y ago
      Ok yeah that's technically true, but there's always going to be a balance point. You can't expect graphics programmers to write a separate renderer for each possible hardware target. That kind of works in the console space, but in the PC space you have to account for a wide variety of hardware. There's always going to be a balance point, and Vulkan's priority is much more about getting as low-level as possible within the constraints than it is about being approachable for developers.
    - fctorial 5y ago
      > it's still built on top of a virtual GPU abstraction which matches some GPUs better than others. Doesn't khronos contain people from a bunch of different corps (amd, nvidia, intel, qualcom) for this exact reason.
      - flohofwoe 5y ago
        Yeah, but that doesn't seem to have helped much to keep the Vulkan API small and tidy, instead there are dozens (or maybe hundreds by now?) of vendor-specific extensions.
        skohan 5y ago
        I think this is vastly overstated. I've done quite a bit of work for Vulkan, and have done just fine without reaching for extensions. And how else do you propose accessing hardware features which are vendor specific?
- flohofwoe 5y ago
  The idea was probably "built it and they will come" (the library authors who provide the easier to use wrapper libraries). The problem is that these libraries are hobbyist/volunteer work (with the notable exception of native WebGPU implementations), which on its own isn't a bad thing, but hobbyist can't afford a testing lab running hundreds of GPU/driver/OS combinations to make sure that their libraries are as robust as expected. The companies who have these resources (for instance the GPU vendors), chickened out by designing Vulkan and thus offloading those QA tasks to the API users (simplified, but that's what it is in the end). Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users, which in turn are not enough to test Vulkan implementations, because just a handful API users isn't enough to cover all the dusty corners (same situation as back in the bad old days with MiniGL).
  - MegaDeKay 5y ago
    > Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users ??? For example, there are a substantial number of emulators that have already implemented or are in the middle of implementing a Vulkan backend: RPCS3, Dolphin, Yuzu, Cemu, Ryujinx, PPSSPP... these emulators are developed by small teams but often push the hardware hard, bringing bugs to light in the process.
    - gpderetta 5y ago
      Also DXVK and VK3D.
zajio1am 5y ago
> Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes, That seems to me like a reasonable decision that graphics API does not try to encompass and duplicate many other unrelated APIs and stays focused on graphics.
codefreakxff 5y ago
I completely agree. I recently decided to try learning Vulkan. I built an sdl window framework and got an OpenGL triangle in maybe 6 lines of OpenGL code. For vulkan you literally cannot draw anything until your reimplement an entire rendering engine from probing hardware, to figuring out queuing strategies, and resource management, etc. you are forced to focus your on HOW rather than WHAT to draw. I think they set the barrier of entry way too high. From a newbie perspective I’d rather have the library make smart decisions by default so I can just init and draw. But if I wanted to do more I could.
- slavik81 5y ago
  It takes dozens of lines of code to draw a triangle in modern OpenGL. You were presumably using immediate mode, which is ancient and deprecated because it has horrible performance on modern hardware. Given that the whole point of an API for hardware accelerated graphics is better performance, that's a big problem. Immediate mode OpenGL not even a particularly friendly API, either. I found its implicit global mutable state for things like the matrix stack to be deeply confusing. There's much better drawing libraries out there if what you're looking for is ease-of-use.
  - tl 5y ago
    The removal of immediate mode from OpenGL is one of many examples of modern OpenGL's stupidity, partially responsible for creating the mess we're in: https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ https://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-...
    - slavik81 5y ago
      Immediate mode still exists and is usable to this day. The compatibility profile never went away. JWZ implemented old-school OpenGL in a library on top of a more modern API, and I would entirely agree that's a good approach to compatibility. I'd have advocated for doing the same thing, just without calling everyone idiots.
    - skohan 5y ago
infogulch 5y ago
> Extension spaghetti for starters Extensions are a PITA to deal with, but they generally represent real disparate hardware features offered by individual GPUs which varies by manufacturer, model, and date. This reminds me of CPU features like SSE2, AVX, AES, etc, etc which general-purpose binary programs are forced to query for at runtime to either take advantage of or fall back to a software implementation. But GPUs have even more architectural change velocity than CPUs. It seems like a hard problem in general. How do you think this could be done better?
- skohan 5y ago
  Yeah exactly. How else can you support the wide range of hardware features out there without being stuck with a lowest-common-denominator?
  - pjmlp 5y ago
    Apple, Microsoft, Sony and Nintendo have such a hard time delivering high quality graphics with their proprietary APIs, pity them.
    - skohan 5y ago
      How does DX12 do feature discovery for things like ray tracing which are supported on only some hardware?
      - pjmlp 5y ago
        By requiring DX12 Ultimate support, done.
        skohan 5y ago
        This is a very low-quality argument. Game developers quite clearly cannot only target DX12 Ultimate and have their product only work for a small percentage of users on PC. If you want to target PC, you have to deal with hardware fragmentation. You can pretend this is a Vulkan issue, but it's just a reality of the platform.
adwn 5y ago
> so each newbie Vulkan isn't for newbies. Really, if you're new to 3D graphics then you're not Vulkan's target audience; pretending otherwise only results in pain. That's like complaining that a modern CPU's privileged instructions are too complicated for people new to assembly – yes, they are, and no, that's not a design flaw. > Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground That's maybe a point against Khronos, not against Vulkan. > Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend. Which is exactly what people should be doing. And those middleware engines can be written using Vulkan, because it is designed the way it is.
- pjmlp 5y ago
  My degree thesis was porting a particle engine framework from NeXTSTEP/OpenGL/Objective-C into Windows/OpenGL/C++ with MFC. Yet that doesn't mean I don't care about newbies in 2021, specially when Khronos says OpenGL isn't going to move beyond version 4.6, thus everyone new in the field feels like Vulkan is what they should learn instead.