1. 16
  1.  

  2. 3

    The website doesn’t provide much context for what problem Vulkan is trying to address. Is it a replacement for OpenGL?

    1. 8

      OpenGL was written to mirror the functionality of GPUs of the 1990s. The hardware has evolved quite significantly, but OpenGL’s API has not, so modern graphics drivers spend a lot of effort shoehorning everything into place. The lack of visibility into what is really going on, and the fact that not all driver code paths are optimised equally, can also make it difficult to reason about OpenGL performance.

      Vulkan is a new graphics API built to fit modern hardware. It’s (much) more low level than OpenGL (e.g. 650 lines of code to draw a triangle), but you can get better performance out of it.

      1. 1

        That triangle.cpp example is quite something. I assume the intended usage is that most people would be writing through some kind of higher-level library, and only the designers of really performance-critical parts of libraries/engines would write this sort of code directly?

        1. 3

          Correct. I’ve not implemented it myself, but I expect a typical design would look like this:

          • The rendering subsystem has some logic to pick one of OpenGL/DX/Vulkan depending on what is available, and provides an abstraction layer which lets you copy things to VRAM and draw them.
          • The assets subsystem provides an interface for reading those vertex lists/matrices/etc (which may be combined to form higher level primitives like models) from disk to RAM/VRAM.
          • The game engine provides high level interfaces like “I want this model and I want it here”, which coordinates (zing) the assets and rendering subsystems behind the scenes.