3 ms·

> is so low level that differences between AMD and nVidia GPUs are exposed. I interpreted it quite differently, the author writes: > there's just less knobs i

> is so low level that differences between AMD and nVidia GPUs are exposed. I interpreted it quite differently, the author writes: > there's just less knobs in general. Almost all the magic you want to do is done with shaders. Since these GPU APIs have a little programming language of their own, the GPU API itself doesn't have to be super powerful. It can be small, designed to exactly how one would control the hardware efficiently, and the programmer has tons of freedom, because they can get buck-wild in a shader with almost no limits. Which to me implies the Vulkan API is so simple, and close to metal, that it doesn't differ between implementations.

asdftway1 5y ago
> Which to me implies the Vulkan API is so simple, and close to metal, that it doesn't differ between implementations As someone with 20 years 3D programming experience including paid work in DirectX and OpenGL ES 2.0, I attempted vulkantutorial.com but gave up because it is too hard. It really is 1000 lines of C/C++ to even get a flat shaded triangle on screen. Vulkan has validation layers to help with writing conformant portable code, but the validation layers are written by your GPU manufacturer and so you can get things that pass on an Intel GPU but fail on nVidia. If you've ever tried porting your "portable" ISO C++ code that works with GCC over to Visual C++ and dealt with 1000s of lines of compiler errors it's kinda the same thing. Vulkan has shaders that precompile to "portable" bytecode but I also noticed that the time delay of loading these "precompiled" bytecode shaders was instant on one Intel GPU but took about 5 seconds on an nVidia GPU. The nVidia driver then cached the results (I know not where) so that subsequent runs were faster, but the cache can be invalidated by either a driver update or a shader update, so your game level loader will need an "ifShaderLoadingSlowerThanMolasses() {...}" code path to deal with your users experiencing slow load times after a video card driver update, etc. Summary: in ages past it was possible for mere mortals to write visualizations and simple games directly in OpenGL/DirectX, but with Vulkan most of us will need a middleware layer on top of it to get anything done within a deadline. If you want an open source portable solution I instead recommend Godot. If you want to make a 3D game that makes millions of dollars with less than 3 years of development and can deploy to Nintendos and Playstations with a button click I recommend Unreal Engine or Unity.
- krapp 5y ago
  The funny thing is (mentioned briefly in the article) SDL just released a geometry API so pushing geometry to the renderer is easy now. Dear ImGui already updated their SDL renderer for it.
  - krapp 5y ago
    ... apparently I was mistaken, this hasn't been released yet, it will be out with 2.0.18[0] [0]https://github.com/libsdl-org/SDL/milestone/2 https://github.com/libsdl-org/SDL/milestone/2
- danudey 5y ago
  I'm not a 3D person or whatever, but is it possible to (asynchronously?) pre-compile shaders before you use them? Like, to run shader compilation behind the scenes while the user is playing the tutorial or whatever?
  - asdftway1 5y ago
    So there are two separate "pre-compile" steps with Vulkan: #1. Compiling shader source code to SPIR-V bytecode; #2. compiling SPIR-V bytecode to native GPU shader instructions. #2 is always done at runtime (though the vendor driver may silently use a cached previous run result), and yes, it is possible to do it async. But like you speculated, you have to figure out something for the user to do while this async compilation happens. In an open world 3D game this adds considerable complexity. If your hero is approaching the Ice Cave of Wonders you need to smoothly preload your fancy ice shaders before the cave mouth is in sight and this preload shouldn't make the current framerate drop. In simpler times past with simpler shaders (like OpenGL 2.1 / ES 2.0 GLSL) you could compile shaders from source in perhaps a single 1/60th second frame. It's funny how 1980s Nintendo cartridges loaded instantly but now that we have hardware at least 10 million times faster we have long load times for games.
    - eproxus 5y ago
      Couldn’t #2 shaders be compiled once and shared between users? A game could compile them on first run, submit them to a server with a unique hash of the OS, driver and shader version (and what else). Then other users could download the already compiled shaders if there’s a network connection. If not, you simply compile them anyway. If security is an issue (can a shaders be dangerous?) you could wait until you have X copies of the same hash and verify that they all have compiled to the same code before adding it to the online cache. Developers could even pre-compute such shaders for popular GPUs that they have access to.
sounds 5y ago
The Vulkan API does not change between Intel, AMD, NVidia and MoltenVK (iOS/macos) GPUs. What the grandparent is saying though is "that differences between AMD and nVidia GPUs are exposed." Vulkan is so low-level that your application needs to implement workarounds for each GPU's quirks. OpenGL was high level enough that if you didn't care too much about raw speed, the only place you got into the weeds of GPU quirks was writing your shaders. With Vulkan, the weeds of GPU quirks pop up everywhere.
- pjmlp 5y ago
  It surely does, because the Vulkan API is a bare bones loader for extension spaghetti, where the first thing an application is supposed to do is to load the extensions required for the application.

asdftway1 5y ago

> Which to me implies the Vulkan API is so simple, and close to metal, that it doesn't differ between implementations As someone with 20 years 3D programming experience including paid work in DirectX and OpenGL ES 2.0, I attempted vulkantutorial.com but gave up because it is too hard. It really is 1000 lines of C/C++ to even get a flat shaded triangle on screen. Vulkan has validation layers to help with writing conformant portable code, but the validation layers are written by your GPU manufacturer and so you can get things that pass on an Intel GPU but fail on nVidia. If you've ever tried porting your "portable" ISO C++ code that works with GCC over to Visual C++ and dealt with 1000s of lines of compiler errors it's kinda the same thing. Vulkan has shaders that precompile to "portable" bytecode but I also noticed that the time delay of loading these "precompiled" bytecode shaders was instant on one Intel GPU but took about 5 seconds on an nVidia GPU. The nVidia driver then cached the results (I know not where) so that subsequent runs were faster, but the cache can be invalidated by either a driver update or a shader update, so your game level loader will need an "ifShaderLoadingSlowerThanMolasses() {...}" code path to deal with your users experiencing slow load times after a video card driver update, etc. Summary: in ages past it was possible for mere mortals to write visualizations and simple games directly in OpenGL/DirectX, but with Vulkan most of us will need a middleware layer on top of it to get anything done within a deadline. If you want an open source portable solution I instead recommend Godot. If you want to make a 3D game that makes millions of dollars with less than 3 years of development and can deploy to Nintendos and Playstations with a button click I recommend Unreal Engine or Unity.

krapp 5y ago
The funny thing is (mentioned briefly in the article) SDL just released a geometry API so pushing geometry to the renderer is easy now. Dear ImGui already updated their SDL renderer for it.
- krapp 5y ago
  ... apparently I was mistaken, this hasn't been released yet, it will be out with 2.0.18[0] [0]https://github.com/libsdl-org/SDL/milestone/2 https://github.com/libsdl-org/SDL/milestone/2
danudey 5y ago
I'm not a 3D person or whatever, but is it possible to (asynchronously?) pre-compile shaders before you use them? Like, to run shader compilation behind the scenes while the user is playing the tutorial or whatever?
- asdftway1 5y ago
  So there are two separate "pre-compile" steps with Vulkan: #1. Compiling shader source code to SPIR-V bytecode; #2. compiling SPIR-V bytecode to native GPU shader instructions. #2 is always done at runtime (though the vendor driver may silently use a cached previous run result), and yes, it is possible to do it async. But like you speculated, you have to figure out something for the user to do while this async compilation happens. In an open world 3D game this adds considerable complexity. If your hero is approaching the Ice Cave of Wonders you need to smoothly preload your fancy ice shaders before the cave mouth is in sight and this preload shouldn't make the current framerate drop. In simpler times past with simpler shaders (like OpenGL 2.1 / ES 2.0 GLSL) you could compile shaders from source in perhaps a single 1/60th second frame. It's funny how 1980s Nintendo cartridges loaded instantly but now that we have hardware at least 10 million times faster we have long load times for games.
  - eproxus 5y ago
    Couldn’t #2 shaders be compiled once and shared between users? A game could compile them on first run, submit them to a server with a unique hash of the OS, driver and shader version (and what else). Then other users could download the already compiled shaders if there’s a network connection. If not, you simply compile them anyway. If security is an issue (can a shaders be dangerous?) you could wait until you have X copies of the same hash and verify that they all have compiled to the same code before adding it to the online cache. Developers could even pre-compute such shaders for popular GPUs that they have access to.

sounds 5y ago

The Vulkan API does not change between Intel, AMD, NVidia and MoltenVK (iOS/macos) GPUs. What the grandparent is saying though is "that differences between AMD and nVidia GPUs are exposed." Vulkan is so low-level that your application needs to implement workarounds for each GPU's quirks. OpenGL was high level enough that if you didn't care too much about raw speed, the only place you got into the weeds of GPU quirks was writing your shaders. With Vulkan, the weeds of GPU quirks pop up everywhere.

pjmlp 5y ago
It surely does, because the Vulkan API is a bare bones loader for extension spaghetti, where the first thing an application is supposed to do is to load the extensions required for the application.