Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -323,7 +323,7 @@ class, for example.

Note that there are many more ways to configure validation layer messages
and debug callbacks, but this is a good setup to get started with for this
tutorial. See the https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap50.html#VK_EXT_debug_utils[extension specification]
tutorial. See the https://docs.vulkan.org/spec/latest/chapters/debugging.html#VK_EXT_debug_utils[extension specification]
for more info about the possibilities.

We can now re-use this in the `createInstance` function:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -165,7 +165,7 @@ extension in the swap chain chapter.

Previous implementations of Vulkan made a distinction between instance and
device-specific validation layers, but this is
link:https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap40.html#extendingvulkan-layers-devicelayerdeprecation[no longer the case].
link:https://docs.vulkan.org/spec/latest/chapters/raytracing.html#extendingvulkan-layers-devicelayerdeprecation[no longer the case].
That means that the `enabledLayerCount` and `ppEnabledLayerNames` fields of
`VkDeviceCreateInfo` are ignored by up-to-date implementations.

Expand Down
2 changes: 1 addition & 1 deletion en/04_Vertex_buffers/01_Vertex_buffer_creation.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -221,7 +221,7 @@ We went for the first approach, which ensures that the mapped memory always matc
Do keep in mind that this may lead to slightly worse performance than explicit flushing, but we'll see why that doesn't matter in the next chapter.

Flushing memory ranges or using a coherent memory heap means that the driver will be aware of our writings to the buffer, but it doesn't mean that they are actually visible on the GPU yet.
The transfer of data to the GPU is an operation that happens in the background, and the specification simply https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#synchronization-submission-host-writes[tells us] that it is guaranteed to be complete as of the next call to `vkQueueSubmit`.
The transfer of data to the GPU is an operation that happens in the background, and the specification simply https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-submission-host-writes[tells us] that it is guaranteed to be complete as of the next call to `vkQueueSubmit`.

== Binding the vertex buffer

Expand Down
2 changes: 1 addition & 1 deletion en/05_Uniform_buffers/01_Descriptor_pool_and_sets.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -248,7 +248,7 @@ Vulkan expects the data in your structure to be aligned in memory in a specific
* A nested structure must be aligned by the base alignment of its members rounded up to a multiple of 16.
* A `float4x4` matrix must have the same alignment as a `float4`.

You can find the full list of alignment requirements in https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap15.html#interfaces-resources-layout[the specification].
You can find the full list of alignment requirements in https://docs.vulkan.org/spec/latest/chapters/interfaces.html#interfaces-resources-layout[the specification].

Our original shader with just three `mat4` fields already met the alignment requirements.
As each `mat4` is 4 x 4 x 4 = 64 bytes in size, `model` has an offset of `0`, `view` has an offset of 64 and `proj` has an offset of 128.
Expand Down
4 changes: 2 additions & 2 deletions en/06_Texture_mapping/00_Images.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -364,7 +364,7 @@ All types of pipeline barriers are submitted using the same function.
The first parameter after the command buffer specifies in which pipeline stage the operations occur that should happen before the barrier.
The second parameter specifies the pipeline stage in which operations will wait on the barrier.
The pipeline stages that you are allowed to specify before and after the barrier depend on how you use the resource before and after the barrier.
The allowed values are listed in https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#synchronization-access-types-supported[this table] of the specification.
The allowed values are listed in https://docs.vulkan.org/spec/latest/chapters/synchronization.html#synchronization-access-types-supported[this table] of the specification.
For example, if you're going to read from a uniform after the barrier, you would specify a usage of `VK_ACCESS_UNIFORM_READ_BIT` and the earliest shader that will read from the uniform as pipeline stage, for example `VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT`.
It would not make sense to specify a non-shader pipeline stage for this type of usage and the validation layers will warn you when you specify a pipeline stage that does not match the type of usage.

Expand Down Expand Up @@ -483,7 +483,7 @@ As you can see in the aforementioned table, transfer writes must occur in the pi
Since the writings don't have to wait on anything, you may specify an empty access mask and the earliest possible pipeline stage `VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT` for the pre-barrier operations.
It should be noted that `VK_PIPELINE_STAGE_TRANSFER_BIT` is not a _real_ stage within the graphics and compute pipelines.
It is more of a pseudo-stage where transfers happen.
See https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap7.html#VkPipelineStageFlagBits[the documentation] for more information and other examples of pseudo-stages.
See https://docs.vulkan.org/spec/latest/chapters/synchronization.html#VkPipelineStageFlagBits[the documentation] for more information and other examples of pseudo-stages.

The image will be written in the same pipeline stage and subsequently read by the fragment shader, which is why we specify shader reading access in the fragment shader pipeline stage.

Expand Down
2 changes: 1 addition & 1 deletion en/10_Multisampling.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -284,7 +284,7 @@ There are certain limitations of our current MSAA implementation that may impact
For example, we're currently not solving potential problems caused by shader aliasing, i.e.
MSAA only smoothens out the edges of geometry but not the interior filling.
This may lead to a situation when you get a smooth polygon rendered on screen, but the applied texture will still look aliased if it contains high contrasting colors.
One way to approach this problem is to enable https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/chap27.html#primsrast-sampleshading[Sample Shading] which will improve the image quality even further, though at an additional performance cost:
One way to approach this problem is to enable https://docs.vulkan.org/spec/latest/chapters/vertexpostproc.html#primsrast-sampleshading[Sample Shading] which will improve the image quality even further, though at an additional performance cost:

[,c++]
----
Expand Down
Loading