vulknyan_learning/notes.md

`VkInstance` - application and extensions
 - `VkPhysicalDevice` - selected based on properties and capabilities

 - `VkDevice` (also known as a logical device), describes which `VkPhysicalDeviceFeatures` will be used, which queue families
  - `VkQueue`, allocated from queue families, examples of families are graphics, compute, and memory transfer

 - `VkSurfaceKHR`, a window surface, it's an extension that provides ways to interact with the window manager,
   in our case GLFW will handle the specific details.

 - `VkSwapchainKHR`, a swap chain, it's a collection of targets for rendering. its first purpose is ensuring that the image
   that is being rendered is not the same one that is on the screen, the most common ways to use one are double and triple
   buffering, swapchains provide images.

 - On some platforms there are extensions (`VK_KHR_display`, `VK_KHR_display_swapchain`) that allow one to draw to the entire
   screen.

 - Once an image is obtained from the swapchain it has to be wrapped into:
   - `VkImageView`, an image view references a specific part of an image to be used
   - `VkFramebuffer`, a framebuffer references images that are used for color, depth, and stencil targets.
     in these examples the image views and framebuffers for each image in the swapchain will be created
     ahead of time.

 - Render passes describe the type of images that are used during rendering, their usage, and how their
   content will be treated, to draw a simple triangle we can tell vulkan that there will be a single image
   that's a color target and that it needs to be cleared to a solid color before drawing.
   Note: a render pass describes the type of images, a `VkFramebuffer` binds specific images to slots.
   Render passes have subpasses, while a render pass describes which images are going to be used the subpasses
   describe which ones will be used for what.

 - `VkPipeline`, describes the configuration of the graphics card, like viewport size, depth buffer operations,
   the programmable state is specified using `VkShaderModule` objects, which are created from shader bytecode.
   The driver also needs to know which render targets are going to be used in the pipeline.
   All of the settings are configured in advance, and changing them requires creating a new `VkPipeline`.
   Each pipeline is bound to a compatible render pass to it, at a specific subpass of it, the reason for this
   is twofold: things such as fragment shaders will end up writing to the attachments, so it makes sense that
   a pipeline, which among other things holds shaders, should know which ones and how, secondarily this allows
   for optimizations on tiled gpus, which are sometimes able to merge subpasses.
   Another important details is that as of later versions of vulkan render passes are not required when enabling
   an extension (`VK_KHR_dynamic_rendering`), this simplifies the code at the potential cost of performance on some
   hardware.

 - Commands are recorded into a `VkCommandBuffer`, the buffers are allocated out of a `VkCommandPool` associated
   with a queue family, in order to do some simple drawing we need to do the following:
   - being a pass
   - bind the pipeline
   - draw 3 vertices
   - end the pass
   Since the image depends on which specific image the swap chain is going to give us, a command buffer for each
   possible image will have to be recorded and the right one will be selected at draw time.
   Recording every frame is also an option but it would be less performant.

 - Application main loop
  - acquire image via `vkAcquireNextImageKHR`
  - `vkAcquireNextImageKHR` to acquire an image
  - select appropriate command buffer for the image
  - execute the command buffer with `vkQueueSubmit`
  - return the image to the swapchain for presentation with `vkQueuePresentKHR`