01_Overview.adoc edits (#355)

Author: jeannekamikaze

en/01_Overview.adoc

@@ -74,12 +74,12 @@ An instance is created by describing your application and any API extensions
 === Step 2 - Logical device and queue families
 
 After selecting the right hardware device to use, you need to create a
-vk::Device (logical device), where you describe more specifically which
+`vk::Device` (logical device), where you describe more specifically which
 physical device features you will be using, like multi viewport rendering
 and 64-bit floats.
 You also need to specify which queue families you would like to use.
 Most operations performed with Vulkan, like draw commands and memory
-operations, are asynchronously executed by submitting them to a vk::Queue.
+operations, are asynchronously executed by submitting them to a `vk::Queue`.
 Queues are allocated from queue families, where each queue family supports a
  specific set of operations in its queues.
 For example, there could be separate queue families for graphics, compute
@@ -100,7 +100,7 @@ We will be using GLFW in this tutorial, but more about that in the next
 chapter.
 
 We need two more parts to actually render to a window: a window surface
- (vk::SurfaceKHR) and a swap chain (vk::SwapchainKHR).
+ (`vk::SurfaceKHR`) and a swap chain (`vk::SwapchainKHR`).
 Note the `KHR` postfix, which means that these objects are part of a Vulkan
 extension. The Vulkan API itself is completely platform-agnostic, which is
 why we need to use the standardized WSI (Window System Interface) extension
@@ -133,7 +133,7 @@ could be used to implement your own window manager, for example.
 === Step 4 - Image views and Dynamic Rendering
 
 To draw to an image acquired from the swap chain, we would typically wrap
-it into a vk::ImageView and vk::Framebuffer. An image view references a specific
+it into a `vk::ImageView` and `vk::Framebuffer`. An image view references a specific
 part of an image to be used, and a framebuffer references image views that are
 to be used for color, depth, and stencil targets.
 Because there could be many different images in the swap chain,
@@ -165,24 +165,24 @@ a single image as a color target and instruct Vulkan to clear it to a solid colo
 
 === Step 6 - Graphics pipeline
 
-The graphics pipeline in Vulkan is set up by creating a VkPipeline object.
+The graphics pipeline in Vulkan is set up by creating a `VkPipeline` object.
 It describes the configurable state of the graphics card, like the viewport
-size and depth buffer operation and the programmable state using vk::ShaderModule objects.
-The vk::ShaderModule objects are created from shader byte code.
+size and depth buffer operation and the programmable state using `vk::ShaderModule` objects.
+The `vk::ShaderModule` objects are created from shader byte code.
 The driver also needs to know which render targets will be used in the
 pipeline, which we specify by referencing the render pass.
 
-One of the most distinctive features of Vulkan compared to existing APIs, is
- that almost all configuration of the graphics pipeline needs to be set in
- advance.
+One of the most distinctive features of Vulkan compared to existing APIs is
+that almost all configuration of the graphics pipeline needs to be set in
+advance.
 That means that if you want to switch to a different shader or slightly
-change your vertex layout, then you need to entirely recreate the graphics
-pipeline.
-That means that you will have to create many vk::Pipeline objects in advance
-for all the different combinations you need for your rendering operations.
+change your vertex layout, then you need to recreate the graphics pipeline
+entirely.
+You will have to create many `vk::Pipeline` objects in advance for all of the
+different combinations you need for your rendering operations.
 Only some basic configuration, like viewport size and clear color, can be
 changed dynamically.
-All the states also need to be described explicitly; there is no default
+All states also need to be described explicitly; there is no default
 color blend state, for example.
 
 The good news is that because you're doing the equivalent of ahead-of-time
@@ -195,22 +195,22 @@ are made very explicit.
 
 As mentioned earlier, many of the operations in Vulkan that we want to
 execute, like drawing operations, need to be submitted to a queue.
-These operations first need to be recorded into a vk::CommandBuffer before
+These operations first need to be recorded into a `vk::CommandBuffer` before
 they can be submitted.
 These command buffers are allocated from a `vk::CommandPool` that is
 associated with a specific queue family.
-Traditionally, to draw a simple triangle, we need to record a command buffer with the
+To draw a triangle prior to dynamic rendering, we would need to record a command buffer with the
 following operations:
 
 * Begin the render pass
 * Bind the graphics pipeline
 * Draw three vertices
 * End the render pass
 
-However, with dynamic rendering, things change.
+However, dynamic rendering changes things.
 Instead of "beginning" and "ending" a render pass,
 you directly define the rendering attachments when you start
-rendering with vk::BeginRendering.
+rendering with `vk::BeginRendering`.
 
 This simplifies the process by allowing you to specify the necessary attachments on the fly,
 making it more adaptable to scenarios where the swap chain images are dynamically selected.
@@ -223,42 +223,42 @@ allowing Vulkan to be more flexible in handling rendering scenarios.
 
 Now that the drawing commands have been wrapped into a command buffer, the
 main loop is quite straightforward.
-We first acquire an image from the swap chain with device.acquireNextImageKHR.
+We first acquire an image from the swap chain with `device.acquireNextImageKHR`.
 We can then select the appropriate command buffer for that image and execute
- it with graphicsQueue.submit().
+it with `graphicsQueue.submit()`.
 Finally, we return the image to the swap chain for presentation to the
-screen with presentQueue.presentKHR(presentInfo).
+screen with `presentQueue.presentKHR(presentInfo)`.
 
 Operations that are submitted to queues are executed asynchronously.
 Therefore, we have to use synchronization objects like semaphores to ensure a
- correct order of execution.
+correct order of execution.
 Execution of the draw command buffer must be set up to wait on image
-acquisition to finish; otherwise it may occur that we start rendering to an
+acquisition to finish; otherwise, it may occur that we start rendering to an
 image that is still being read for presentation on the screen.
-The presentQueue.presentKHR(presentInfoKHR) call in turn needs to wait for rendering to be
+The `presentQueue.presentKHR(presentInfoKHR)` call in turn needs to wait for rendering to be
 finished, for which we'll use a second semaphore that is signaled after
 rendering completes.
 
 === Summary
 
 This whirlwind tour should give you a basic understanding of the work ahead
- of drawing the first triangle.
+of drawing the first triangle.
 A real-world program contains more steps, like allocating vertex buffers,
 creating uniform buffers and uploading texture images that will be covered
 in later chapters. However, we'll start simple because Vulkan has enough of
 a steep learning curve as it is.
 Note that we'll cheat a bit by initially embedding the vertex coordinates in
- the vertex shader instead of using a vertex buffer.
+the vertex shader instead of using a vertex buffer.
 That's because managing vertex buffers requires some familiarity with
 command buffers first.
 
 So in short, to draw the first triangle, we need to:
 
 * Create an Instance
-* Select a supported graphics card (PhysicalDevice)
-* Create a Device and Queue for drawing and presentation
+* Select a supported graphics card (`PhysicalDevice`)
+* Create a `Device` and `Queue` for drawing and presentation
 * Create a window, window surface and swap chain
-* Wrap the swap chain images into VkImageView
+* Wrap the swap chain images into `VkImageView`
 * Set up dynamic rendering
 * Set up the graphics pipeline
 * Allocate and record a command buffer with the draw commands for every
@@ -269,11 +269,11 @@ and returning the images to the swap chain
 It's a lot of steps, but the purpose of each step will be made
 basic and clear in the upcoming chapters.
 If you're confused about the relation of a single step compared to the whole
- program, you should refer back to this chapter.
+program, you should refer back to this chapter.
 
 == API concepts
 
-This chapter will conclude with a short overview of how the Vulkan API is
+This chapter concludes with a short overview of how the Vulkan API is
 structured at a lower level.
 
 For example, object creation generally follows this pattern:
@@ -301,24 +301,24 @@ Many structures in Vulkan require you to explicitly specify the type of
 structure in the `sType` member.
 The `pNext` member can point to an extension structure and will always be
 `nullptr` in this tutorial.
-Functions that create or destroy an object will have a VkAllocationCallbacks
- parameter that allows you to use a custom allocator for driver memory,
- which will also be left `nullptr` in this tutorial.
+Functions that create or destroy an object will have a `VkAllocationCallbacks`
+parameter that allows you to use a custom allocator for driver memory,
+which will also be left `nullptr` in this tutorial.
 
-Almost all functions return a vk::Result that is either `vk::result::eSuccess`
+Almost all functions return a `vk::Result` that is either `vk::result::eSuccess`
 or an error code.
 The specification describes which error codes each function can return and
 what they mean.
 
 Failure of such calls is reported by C++ exceptions. The exception will
-respond with more information about the error including the aforementioned
-vk::Result, this enables us to check multiple commands from one call and keep
-the command syntax clean.
+respond with more information about the error including a `vk::Result`.
+This enables us to check multiple commands from one call and keep the
+command syntax clean.
 
 === Validation layers
 
 As mentioned earlier, Vulkan is designed for high performance and low driver
- overhead.
+overhead.
 Therefore, it will include very limited error checking and debugging
 capabilities by default.
 The driver will often crash instead of returning an error code if you do
@@ -335,7 +335,7 @@ completely disable them when releasing your application for zero overhead.
 Anyone can write their own validation layers, but the Vulkan SDK by LunarG
 provides a standard set of validation layers that we'll be using in this tutorial.
 You also need to register a callback function to receive debug messages from
- the layers.
+the layers.
 
 Because Vulkan is so explicit about every operation and the validation
 layers are so extensive, it can actually be a lot easier to find out why