3 ms·

I can't stand Vulkan for exactly the reason specified: "Vulkan is the government office telling you, you still don't have all the necessary forms to proceed." I

I can't stand Vulkan for exactly the reason specified: "Vulkan is the government office telling you, you still don't have all the necessary forms to proceed." I wonder how anyone can find this description attractive, but apparently the author does. If there is a personal hell for me somewhere, this is the definition of it. Perhaps as a compiler target, it could be usable. But on its own... not a chance.

munchbunny 9y ago
To be fair to Vulkan, it was designed to be used by somebody who knew what they were doing, under the philosophy that since developers were using all sorts of hacks to get efficient inner loops in the rendering pipeline anyway, you might as well make the API explicit about those optimization mechanisms. In that vein, OpenGL or DirectX is probably a better starting option specifically because it abstracts more of the sausage-making in a way that is conceptually cleaner, especially for beginners. It won't take long to get to a point where you'll appreciate Vulkan, but it's a shallower learning curve that is still conceptually sound.
- atemerev 9y ago
  Being low-level is fine. However, the hallmark of good API design is to provide a good ramp-up and sane defaults. E.g. x86 assembly language is low-level, but I can start learning it quite easily. Writing "Hello world!" (either in BIOS or with system calls) is easy. Simple calculations and loops are easy. Assembly is approachable. On the other hand, Vulkan is as explicit and intimidating as you could imagine in the worst case, and then some. Two pages of code for drawing a triangle!
  - munchbunny 9y ago
    Only two pages? Honestly, that's pretty good. People who haven't done 3d graphics programming seriously underestimate the number of stages in even a basic rendering pipeline.
    - atemerev 9y ago
      I have successfully rendered a triangle with Vulkan :) There are also good high-level APIs, like three.js. What is missing is some middle ground between them.
  - SolarNet 9y ago
    The problem is that graphics doesn't really have a ramp up. Without bloating drivers that are already half a GB or larger, there isn't really a fix for that. Because you have to with any rendering framework: * Open a hardware context in the window manager. * Describe to the window manager / operating system how to configure that context. (SDL/GLFW helps with this) * Collect the functions and features (provided by different vendors based on OS, and hence this step is required) you require from that context. (GLEW helps with this) * Write and load shaders. Including setting up that toolchain, writing boiler plate, choosing a language to use, choosing an IDE, etc. * Describe a 3d object. Whether by loading, or directly in memory. Decide now about future steps. * Load that object onto the hardware. Assuming there is enough room, etc. * Describe to the hardware how that data is organized (in a different language of attributes, since the hardware cares about different things) that agrees with the shader. * Describe how you would like to draw things if they aren't the "sane" defaults (often from 1990). * Clear the screen (including describing how to clear the screen the way you want). * Choose a shader (and describe how it should be used). * Draw the object, based on how you configured everything earlier and the shader is written. * Inform the window manager you are done with the hardware context and ask it to display the screen. * Repeat the last 4 steps 60 times a second. And that is for a zero features system. No dynamic movement, no lighting, no textures. Just a triangle or a cube sitting there. If you want easy ramp up, use a library that makes decisions about all of those things for you. In light of your assembly analogy, it's like you are trying to write an assembly program that prints hello world to a printer over the network, using it's assembly language so that it can optimize how many times a second it can print hello world locally. It's hard, because the goal is not "hello world" it's some complex structure that allows us to display "hello world" in a complex way (3d) in real time. The difference is OpenGL when used incorrectly, does nothing. Vulkan comes back with an error and says "you forgot step 7a of describing how the memory you gave me was organized".
    - atemerev 9y ago
      The difference is that with networking, I don't need to bother myself with data being aligned to physical layer boundaries, or similar level small details that belong to network drivers or OS stack layer — and still get gigabytes per second throughput, because of good abstractions. And with OpenGL/Vulkan — it's like I am writing driver-level code, which is not my idea of fun. For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? Additionally, what you have described is still 10-15 lines of code. Vulkan is still more demanding.

munchbunny 9y ago

To be fair to Vulkan, it was designed to be used by somebody who knew what they were doing, under the philosophy that since developers were using all sorts of hacks to get efficient inner loops in the rendering pipeline anyway, you might as well make the API explicit about those optimization mechanisms. In that vein, OpenGL or DirectX is probably a better starting option specifically because it abstracts more of the sausage-making in a way that is conceptually cleaner, especially for beginners. It won't take long to get to a point where you'll appreciate Vulkan, but it's a shallower learning curve that is still conceptually sound.

atemerev 9y ago
Being low-level is fine. However, the hallmark of good API design is to provide a good ramp-up and sane defaults. E.g. x86 assembly language is low-level, but I can start learning it quite easily. Writing "Hello world!" (either in BIOS or with system calls) is easy. Simple calculations and loops are easy. Assembly is approachable. On the other hand, Vulkan is as explicit and intimidating as you could imagine in the worst case, and then some. Two pages of code for drawing a triangle!
- munchbunny 9y ago
  Only two pages? Honestly, that's pretty good. People who haven't done 3d graphics programming seriously underestimate the number of stages in even a basic rendering pipeline.
  - atemerev 9y ago
    I have successfully rendered a triangle with Vulkan :) There are also good high-level APIs, like three.js. What is missing is some middle ground between them.
- SolarNet 9y ago
  The problem is that graphics doesn't really have a ramp up. Without bloating drivers that are already half a GB or larger, there isn't really a fix for that. Because you have to with any rendering framework: * Open a hardware context in the window manager. * Describe to the window manager / operating system how to configure that context. (SDL/GLFW helps with this) * Collect the functions and features (provided by different vendors based on OS, and hence this step is required) you require from that context. (GLEW helps with this) * Write and load shaders. Including setting up that toolchain, writing boiler plate, choosing a language to use, choosing an IDE, etc. * Describe a 3d object. Whether by loading, or directly in memory. Decide now about future steps. * Load that object onto the hardware. Assuming there is enough room, etc. * Describe to the hardware how that data is organized (in a different language of attributes, since the hardware cares about different things) that agrees with the shader. * Describe how you would like to draw things if they aren't the "sane" defaults (often from 1990). * Clear the screen (including describing how to clear the screen the way you want). * Choose a shader (and describe how it should be used). * Draw the object, based on how you configured everything earlier and the shader is written. * Inform the window manager you are done with the hardware context and ask it to display the screen. * Repeat the last 4 steps 60 times a second. And that is for a zero features system. No dynamic movement, no lighting, no textures. Just a triangle or a cube sitting there. If you want easy ramp up, use a library that makes decisions about all of those things for you. In light of your assembly analogy, it's like you are trying to write an assembly program that prints hello world to a printer over the network, using it's assembly language so that it can optimize how many times a second it can print hello world locally. It's hard, because the goal is not "hello world" it's some complex structure that allows us to display "hello world" in a complex way (3d) in real time. The difference is OpenGL when used incorrectly, does nothing. Vulkan comes back with an error and says "you forgot step 7a of describing how the memory you gave me was organized".
  - atemerev 9y ago
    The difference is that with networking, I don't need to bother myself with data being aligned to physical layer boundaries, or similar level small details that belong to network drivers or OS stack layer — and still get gigabytes per second throughput, because of good abstractions. And with OpenGL/Vulkan — it's like I am writing driver-level code, which is not my idea of fun. For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? Additionally, what you have described is still 10-15 lines of code. Vulkan is still more demanding.