4 ms·

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 h

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.
    - groovy2shoes 9y ago
      > For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? There is. It's called OpenGL ;) That said, I share your sentiment. Tossing aside the drivers and the general optimizations they offer seems to me to be akin to tossing aside your compiler because you can write more efficient assembly by hand. I think the ability to write such low-level code will always have its place, but I can't help but feel like we (as an industry) are going in the wrong direction with this. In trying to be optimistic about Vulkan and the like, it may be an opportunity for developers to experiment with different higher-level APIs until we manage to find abstractions that are as good as the ones we have for networking (and hopefully better, even). > it's like I am writing driver-level code, which is not my idea of fun. Luckily, that's somebody's idea of fun :)
    - munchbunny 9y ago
      Vulkan solves a different problem though, specifically one where performance is the primary consideration and simplicity is maintained to the extent that someone who writes engines gets all of the options they need. It's a bit hard to equate to assembly because the bulk of the complexity isn't so much "general purpose code" as "data processing pipeline." Additionally, graphics still has a very real "out of memory problem" that you can safely ignore for the most part in modern OSes and normal programming. The moment you hit "virtual graphics memory" your framerate tanks. If you're looking for sane defaults, the answer is to use things like Unity, Unreal, etc. You can actually get quite far with their defaults and very little code. That's why I usually tell people to skip OpenGL, DirectX, or Vulkan and just go use an engine. 3d also just has an inherent complexity that at every stage you're dealing with the limitations of processing 3d data using 2d buffers. That's why any fancy effect requires you to manipulate primitives (buffers and shades).

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.
  - groovy2shoes 9y ago
    > For printers, there is PostScript. Why there isn't a similar standardized 3D rendering protocol? There is. It's called OpenGL ;) That said, I share your sentiment. Tossing aside the drivers and the general optimizations they offer seems to me to be akin to tossing aside your compiler because you can write more efficient assembly by hand. I think the ability to write such low-level code will always have its place, but I can't help but feel like we (as an industry) are going in the wrong direction with this. In trying to be optimistic about Vulkan and the like, it may be an opportunity for developers to experiment with different higher-level APIs until we manage to find abstractions that are as good as the ones we have for networking (and hopefully better, even). > it's like I am writing driver-level code, which is not my idea of fun. Luckily, that's somebody's idea of fun :)
  - munchbunny 9y ago
    Vulkan solves a different problem though, specifically one where performance is the primary consideration and simplicity is maintained to the extent that someone who writes engines gets all of the options they need. It's a bit hard to equate to assembly because the bulk of the complexity isn't so much "general purpose code" as "data processing pipeline." Additionally, graphics still has a very real "out of memory problem" that you can safely ignore for the most part in modern OSes and normal programming. The moment you hit "virtual graphics memory" your framerate tanks. If you're looking for sane defaults, the answer is to use things like Unity, Unreal, etc. You can actually get quite far with their defaults and very little code. That's why I usually tell people to skip OpenGL, DirectX, or Vulkan and just go use an engine. 3d also just has an inherent complexity that at every stage you're dealing with the limitations of processing 3d data using 2d buffers. That's why any fancy effect requires you to manipulate primitives (buffers and shades).