diff --git a/chapters/vertex_input_data_processing.adoc b/chapters/vertex_input_data_processing.adoc
index 6453ee3..1cbe4f0 100644
--- a/chapters/vertex_input_data_processing.adoc
+++ b/chapters/vertex_input_data_processing.adoc
@@ -349,3 +349,17 @@ layout(location = 1) in uvec4 inUV;
 ----
 
 image::{images}vertex_input_data_processing_fill_1.png[vertex_input_data_processing_fill_1]
+
+== Setting the stride
+
+Over time, the number of ways to set the stride of a vertex input binding has grown.
+
+Originally, when using `vkCmdBindVertexBuffers`, the stride value was defined within the pipeline via `VkVertexInputBindingDescription::stride`. At draw time, the combination of `vkCmdBindPipeline` and `vkCmdBindVertexBuffers` provided all the necessary state.
+
+Later, `VK_EXT_vertex_input_dynamic_state` was added. This introduced `VK_DYNAMIC_STATE_VERTEX_INPUT_EXT`, allowing applications to skip defining vertex input values in the pipeline. Instead, you call `vkCmdSetVertexInputEXT` inside the command buffer to set `VkVertexInputBindingDescription2EXT::stride`, along with all other vertex input values.
+
+Subsequently, `VK_EXT_extended_dynamic_state` introduced `VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE`. This allows the pipeline to skip the `VkVertexInputBindingDescription::stride` definition. Instead, the stride is set dynamically via `vkCmdBindVertexBuffers2`.
+
+An issue arose because the stride could be set by both `vkCmdSetVertexInputEXT` and `vkCmdBindVertexBuffers2` prior to a draw. It was determined that the last value set prior to the draw call is the one that will be used.
+
+When `vkCmdBindVertexBuffers3KHR` was added, it introduced `VkBindVertexBuffer3InfoKHR::setStride`. This allows the user to decide whether the function should update the stride value or leave it unchanged before a draw.