Minor fixes in the docs - language
diff --git a/include/vk_mem_alloc.h b/include/vk_mem_alloc.h
index 8c49c0d..ddbc0c8 100644
--- a/include/vk_mem_alloc.h
+++ b/include/vk_mem_alloc.h
@@ -334,7 +334,7 @@
/** \brief Enables usage of VK_KHR_dedicated_allocation extension.
The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion `== VK_API_VERSION_1_0`.
- When it's `VK_API_VERSION_1_1`, the flag is ignored because the extension has been promoted to Vulkan 1.1.
+ When it is `VK_API_VERSION_1_1`, the flag is ignored because the extension has been promoted to Vulkan 1.1.
Using this extension will automatically allocate dedicated blocks of memory for
some buffers and images instead of suballocating place for them out of bigger
@@ -360,7 +360,7 @@
Enables usage of VK_KHR_bind_memory2 extension.
The flag works only if VmaAllocatorCreateInfo::vulkanApiVersion `== VK_API_VERSION_1_0`.
- When it's `VK_API_VERSION_1_1`, the flag is ignored because the extension has been promoted to Vulkan 1.1.
+ When it is `VK_API_VERSION_1_1`, the flag is ignored because the extension has been promoted to Vulkan 1.1.
You may set this flag only if you found out that this device extension is supported,
you enabled it while creating Vulkan device passed as VmaAllocatorCreateInfo::device,
@@ -1525,7 +1525,7 @@
/** \brief Returns `VK_TRUE` if allocation is not lost and atomically marks it as used in current frame.
If the allocation has been created with #VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT flag,
-this function returns `VK_TRUE` if it's not in lost state, so it can still be used.
+this function returns `VK_TRUE` if it is not in lost state, so it can still be used.
It then also atomically "touches" the allocation - marks it as used in current frame,
so that you can be sure it won't become lost in current frame or next `frameInUseCount` frames.
@@ -2231,7 +2231,7 @@
#if __cplusplus >= 201703L
#define VMA_USE_STL_SHARED_MUTEX 1
// Visual studio defines __cplusplus properly only when passed additional parameter: /Zc:__cplusplus
- // Otherwise it's always 199711L, despite shared_mutex works since Visual Studio 2015 Update 2.
+ // Otherwise it is always 199711L, despite shared_mutex works since Visual Studio 2015 Update 2.
// See: https://blogs.msdn.microsoft.com/vcblog/2018/04/09/msvc-now-correctly-reports-__cplusplus/
#elif defined(_MSC_FULL_VER) && _MSC_FULL_VER >= 190023918 && __cplusplus == 199711L && _MSVC_LANG >= 201703L
#define VMA_USE_STL_SHARED_MUTEX 1
@@ -2297,7 +2297,7 @@
// // For C++14, usr/include/malloc/_malloc.h declares aligned_alloc()) only
// // with the MacOSX11.0 SDK in Xcode 12 (which is what adds
// // MAC_OS_X_VERSION_10_16), even though the function is marked
- // // availabe for 10.15. That's why the preprocessor checks for 10.16 but
+ // // availabe for 10.15. That is why the preprocessor checks for 10.16 but
// // the __builtin_available checks for 10.15.
// // People who use C++17 could call aligned_alloc with the 10.15 SDK already.
// if (__builtin_available(macOS 10.15, iOS 13, *))
@@ -5037,10 +5037,10 @@
// Returns iterator to new free suballocation at this place.
VmaSuballocationList::iterator FreeSuballocation(VmaSuballocationList::iterator suballocItem);
// Given free suballocation, it inserts it into sorted list of
- // m_FreeSuballocationsBySize if it's suitable.
+ // m_FreeSuballocationsBySize if it is suitable.
void RegisterFreeSuballocation(VmaSuballocationList::iterator item);
// Given free suballocation, it removes it from sorted list of
- // m_FreeSuballocationsBySize if it's suitable.
+ // m_FreeSuballocationsBySize if it is suitable.
void UnregisterFreeSuballocation(VmaSuballocationList::iterator item);
};
@@ -5458,7 +5458,7 @@
VkDeviceMemory m_hMemory;
/*
- Protects access to m_hMemory so it's not used by multiple threads simultaneously, e.g. vkMapMemory, vkBindBufferMemory.
+ Protects access to m_hMemory so it is not used by multiple threads simultaneously, e.g. vkMapMemory, vkBindBufferMemory.
Also protects m_MapCount, m_pMappedData.
Allocations, deallocations, any change in m_pMetadata is protected by parent's VmaBlockVector::m_Mutex.
*/
@@ -5641,7 +5641,7 @@
VkCommandBuffer commandBuffer);
/*
- Used during defragmentation. pDefragmentationStats is optional. It's in/out
+ Used during defragmentation. pDefragmentationStats is optional. It is in/out
- updated with new data.
*/
void FreeEmptyBlocks(VmaDefragmentationStats* pDefragmentationStats);
@@ -11293,7 +11293,7 @@
/*
Under certain condition, this whole section can be skipped for optimization, so
- we move on directly to trying to allocate with canMakeOtherLost. That's the case
+ we move on directly to trying to allocate with canMakeOtherLost. That is the case
e.g. for custom pools with linear algorithm.
*/
if(!canMakeOtherLost || canCreateNewBlock)
@@ -15380,7 +15380,7 @@
{
/*
Warning: This is a carefully designed algorithm.
- Do not modify unless you really know what you're doing :)
+ Do not modify unless you really know what you are doing :)
*/
const uint32_t localCurrFrameIndex = m_CurrentFrameIndex.load();
uint32_t localLastUseFrameIndex = hAllocation->GetLastUseFrameIndex();
@@ -18128,7 +18128,7 @@
\section choosing_memory_type_dedicated_allocations Dedicated allocations
Memory for allocations is reserved out of larger block of `VkDeviceMemory`
-allocated from Vulkan internally. That's the main feature of this whole library.
+allocated from Vulkan internally. That is the main feature of this whole library.
You can still request a separate memory block to be created for an allocation,
just like you would do in a trivial solution without using any allocator.
In that case, a buffer or image is always bound to that memory at offset 0.
@@ -18162,7 +18162,7 @@
They are safer and more convenient to use than standard Vulkan functions.
You can map an allocation multiple times simultaneously - mapping is reference-counted internally.
You can also map different allocations simultaneously regardless of whether they use the same `VkDeviceMemory` block.
-The way it's implemented is that the library always maps entire memory block, not just region of the allocation.
+The way it is implemented is that the library always maps entire memory block, not just region of the allocation.
For further details, see description of vmaMapMemory() function.
Example:
@@ -18330,7 +18330,7 @@
if(allocInfo.pMappedData != nullptr)
{
// Allocation ended up in mappable memory.
- // It's persistently mapped. You can access it directly.
+ // It is persistently mapped. You can access it directly.
memcpy(allocInfo.pMappedData, &constantBufferData, sizeof(constantBufferData));
}
else
@@ -18344,7 +18344,7 @@
\page staying_within_budget Staying within budget
When developing a graphics-intensive game or program, it is important to avoid allocating
-more GPU memory than it's physically available. When the memory is over-committed,
+more GPU memory than it is physically available. When the memory is over-committed,
various bad things can happen, depending on the specific GPU, graphics driver, and
operating system:
@@ -18702,7 +18702,7 @@
There is another allocation algorithm that can be used with custom pools, called
"buddy". Its internal data structure is based on a tree of blocks, each having
size that is a power of two and a half of its parent's size. When you want to
-allocate memory of certain size, a free node in the tree is located. If it's too
+allocate memory of certain size, a free node in the tree is located. If it is too
large, it is recursively split into two halves (called "buddies"). However, if
requested allocation size is not a power of two, the size of a tree node is
aligned up to the nearest power of two and the remaining space is wasted. When
@@ -18864,8 +18864,8 @@
defragInfo.allocationCount = allocCount;
defragInfo.pAllocations = allocations.data();
defragInfo.pAllocationsChanged = allocationsChanged.data();
-defragInfo.maxGpuBytesToMove = VK_WHOLE_SIZE; // Notice it's "GPU" this time.
-defragInfo.maxGpuAllocationsToMove = UINT32_MAX; // Notice it's "GPU" this time.
+defragInfo.maxGpuBytesToMove = VK_WHOLE_SIZE; // Notice it is "GPU" this time.
+defragInfo.maxGpuAllocationsToMove = UINT32_MAX; // Notice it is "GPU" this time.
defragInfo.commandBuffer = commandBuffer;
VmaDefragmentationContext defragCtx;
@@ -18942,7 +18942,7 @@
class `VmaDefragmentationAlgorithm` and implement your version of its pure virtual methods.
See definition and comments of this class for details.
-# Your code needs to interact with device memory block metadata.
- If you need more access to its data than it's provided by its public interface,
+ If you need more access to its data than it is provided by its public interface,
declare your new class as a friend class e.g. in class `VmaBlockMetadata_Generic`.
-# If you want to create a flag that would enable your algorithm or pass some additional
flags to configure it, add them to `VmaDefragmentationFlagBits` and use them in
@@ -18965,7 +18965,7 @@
To create an allocation that can become lost, include #VMA_ALLOCATION_CREATE_CAN_BECOME_LOST_BIT
flag in VmaAllocationCreateInfo::flags. Before using a buffer or image bound to
-such allocation in every new frame, you need to query it if it's not lost.
+such allocation in every new frame, you need to query it if it is not lost.
To check it, call vmaTouchAllocation().
If the allocation is lost, you should not use it or buffer/image bound to it.
You mustn't forget to destroy this allocation and this buffer/image.
@@ -18983,16 +18983,16 @@
up is planned for the future.
<b>Q: When interleaving creation of new allocations with usage of existing ones,
-how do you make sure that an allocation won't become lost while it's used in the
+how do you make sure that an allocation won't become lost while it is used in the
current frame?</b>
It is ensured because vmaTouchAllocation() / vmaGetAllocationInfo() not only returns allocation
-status/parameters and checks whether it's not lost, but when it's not, it also
+status/parameters and checks whether it is not lost, but when it is not, it also
atomically marks it as used in the current frame, which makes it impossible to
become lost in that frame. It uses lockless algorithm, so it works fast and
doesn't involve locking any internal mutex.
-<b>Q: What if my allocation may still be in use by the GPU when it's rendering a
+<b>Q: What if my allocation may still be in use by the GPU when it is rendering a
previous frame while I already submit new frame on the CPU?</b>
You can make sure that allocations "touched" by vmaTouchAllocation() / vmaGetAllocationInfo() will not
@@ -19024,7 +19024,7 @@
// Check if its allocation is not lost + mark it as used in current frame.
if(vmaTouchAllocation(allocator, m_Alloc))
{
- // It's all OK - safe to use m_Buf.
+ // It is all OK - safe to use m_Buf.
return;
}
}
@@ -19118,7 +19118,7 @@
You can annotate allocations with your own information, e.g. for debugging purposes.
To do that, fill VmaAllocationCreateInfo::pUserData field when creating
-an allocation. It's an opaque `void*` pointer. You can use it e.g. as a pointer,
+an allocation. It is an opaque `void*` pointer. You can use it e.g. as a pointer,
some handle, index, key, ordinal number or any other value that would associate
the allocation with your custom metadata.
@@ -19278,7 +19278,7 @@
Memory is automatically mapped and unmapped if necessary.
This number is validated automatically when the allocation is destroyed.
-If it's not equal to the expected value, `VMA_ASSERT()` is executed.
+If it is not equal to the expected value, `VMA_ASSERT()` is executed.
It clearly means that either CPU or GPU overwritten the memory outside of boundaries of the allocation,
which indicates a serious bug.
@@ -19329,7 +19329,7 @@
VmaReplay.exe MyRecording.csv
<b>Documentation of file format</b> can be found in file: "docs/Recording file format.md".
-It's a human-readable, text file in CSV format (Comma Separated Values).
+It is a human-readable, text file in CSV format (Comma Separated Values).
\section record_and_replay_additional_considerations Additional considerations
@@ -19653,7 +19653,7 @@
vmaCreateAllocator(&allocatorInfo, &allocator);
\endcode
-That's all. The extension will be automatically used whenever you create a
+That is all. The extension will be automatically used whenever you create a
buffer using vmaCreateBuffer() or image using vmaCreateImage().
When using the extension together with Vulkan Validation Layer, you will receive
@@ -19840,7 +19840,7 @@
higher-level library implemented on top of VMA.
- **Recreation of buffers and images.** Although the library has functions for
buffer and image creation (vmaCreateBuffer(), vmaCreateImage()), you need to
- recreate these objects yourself after defragmentation. That's because the big
+ recreate these objects yourself after defragmentation. That is because the big
structures `VkBufferCreateInfo`, `VkImageCreateInfo` are not stored in
#VmaAllocation object.
- **Handling CPU memory allocation failures.** When dynamically creating small C++
