Skip to content
Open
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
18 changes: 8 additions & 10 deletions en/04_Vertex_buffers/01_Vertex_buffer_creation.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -41,24 +41,22 @@ Creating a buffer requires us to fill a `VkBufferCreateInfo` structure.

[,c++]
----
vk::BufferCreateInfo bufferInfo({}, sizeof(vertices[0]) * vertices.size(), vk::BufferUsageFlagBits::eVertexBuffer, vk::SharingMode::eExclusive);
vk::BufferCreateInfo bufferInfo{ .size = sizeof(vertices[0]) * vertices.size(), .usage = vk::BufferUsageFlagBits::eVertexBuffer, .sharingMode = vk::SharingMode::eExclusive };
----

The first field of the constructor is the flags, used to configure sparse buffer memory, which is not relevant right now.
We'll leave it at the default value of `0`.
Next is `size`, which specifies the size of the buffer in bytes. Calculating
The `size` field specifies the size of the buffer in bytes. Calculating
the byte size of the vertex data is straightforward with `sizeof`.

The third field is `usage`, which indicates for which purposes the data in the
The `usage` field indicates for which purposes the data in the
buffer is going to be used. It is possible to specify multiple purposes using
a bitwise or. Our use case will be a vertex buffer, we'll look at other
types of usage in future chapters.

Just like the images in the swap chain, buffers can also be owned by a specific queue family or be shared between multiple at the same time.
The buffer will only be used from the graphics queue, so we can stick to exclusive access.

The `flags` parameter is used to configure sparse buffer memory, which is not relevant right now.
We'll leave it at the default value of `0`.
There is also a `flags` field, which is used to configure sparse buffer memory. It's not relevant right now, so
we'll leave it at the default value of `0`.

We can now create the buffer with `vkCreateBuffer`.
Define a class member to hold the buffer handle and call it `vertexBuffer`.
Expand Down Expand Up @@ -110,7 +108,7 @@ First we need to query info about the available types of memory using `vkGetPhys

[,c++]
----
vk::PhysicalDeviceMemoryProperties memProperties = physicalDevice->getMemoryProperties();
vk::PhysicalDeviceMemoryProperties memProperties = physicalDevice.getMemoryProperties();
----

The `VkPhysicalDeviceMemoryProperties` structure has two arrays `memoryTypes` and `memoryHeaps`.
Expand Down Expand Up @@ -162,7 +160,7 @@ We now have a way to determine the right memory type, so we can actually allocat

[,c++]
----
vk::MemoryAllocateInfo memoryAllocateInfo( memRequirements.size, findMemoryType(memRequirements.memoryTypeBits, vk::MemoryPropertyFlagBits::eHostVisible | vk::MemoryPropertyFlagBits::eHostCoherent) );
vk::MemoryAllocateInfo memoryAllocateInfo{ .allocationSize = memRequirements.size, .memoryTypeIndex = findMemoryType(memRequirements.memoryTypeBits, vk::MemoryPropertyFlagBits::eHostVisible | vk::MemoryPropertyFlagBits::eHostCoherent) };
----

Memory allocation is now as simple as specifying the size and type, both of which are derived from the memory requirements of the vertex buffer and the desired property.
Expand All @@ -185,7 +183,7 @@ If memory allocation was successful, then we can now associate this memory with
vertexBuffer.bindMemory( *vertexBufferMemory, 0 );
----

The first three parameters are self-explanatory, and the fourth parameter is the offset within the region of memory.
The first parameter is self-explanatory, and the second parameter is the offset within the region of memory.
Since this memory is allocated specifically for this the vertex buffer, the offset is simply `0`.
If the offset is non-zero, then it is required to be divisible by `memRequirements.alignment`.

Expand Down
Loading