|
4b356c39
|
2023-08-17T10:49:19
|
|
Vulkan: Drop support for VMA 2.0
Since ANGLE and Chromium were last updated to use VMA 3.0, there have
been no breaking issues so far.
* ANGLE update: https://crrev.com/c/4777337
* Chromium update: https://crrev.com/c/4911597
Therefore, the support for the old VMA (2.3) can now be removed.
* Removed ANGLE_VMA_VERSION from the build files, since they are
no longer required.
* Removed the VMA-related guards in the code as well.
* Removed the flags and thresholds for the buddy algorithm, which were
used in VMA 2.3.
* Share group buffer pools is no longer a map.
Bug: b/303290680
Change-Id: Ic2b29e8f95ca5c941b297b20442c5bad4b8f52e3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4791667
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
b4852ef9
|
2023-02-08T14:18:06
|
|
Vulkan: Drop support for Vulkan 1.0
Bug: angleproject:7959
Change-Id: Ib673679ea1a503af22b37092dbff1ee1fd34fba6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4233092
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
4963febf
|
2023-08-02T16:52:52
|
|
Vulkan: Remove type indices with host-visible bit
Currently, the memory type index for VMA image allocations are
selected and returned by the API. However, it could potentially
choose a type index with more flags than required or preferred,
and ignore the index with exactly the flags we want. For example,
it could pick a type index with the host-visible property flag,
even if is unnecessary and a type index with a device-local flag
would suffice.
Using memoryTypeBits during the allocation allows us to filter
the unwanted type indices out and use the other indices initially.
* Added a new function to RendererVk.cpp to try to remove the memory
type indices with the host-visible bit for VMA image allocations
if they should be device-local.
* GetMemoryTypeBitsExcludingHostVisible()
* It also removes the indices with the protected bit if it is not
required.
* If the allocation is unsuccessful, the fallback resets the field
for memoryTypeBits, allowing all available type indices to be used
for the allocation.
* Added memory type index to the pending allocation log during OOM.
Bug: b/294085818
Change-Id: Icc1b218df075170a6baa7ec57c837ed59cd4fa96
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4743604
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
a73e546c
|
2023-04-14T13:40:19
|
|
Vulkan: Add pending memory size for VMA images
* Added implementation for vma::FindMemoryTypeIndexForImageInfo().
* Add pending memory allocation tracking for VMA images using
the memory requirement from getMemoryRequirements() and the
memory type index from the function above.
Bug: b/218891184
Change-Id: I1c3d3a8f5f36eb57bd7a5a059aa3bf713b819831
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4428535
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
b58ef53a
|
2023-04-14T14:27:12
|
|
Vulkan: Add size limit for VMA image suballocation
* Added kImageSizeThresholdForDedicatedMemoryAllocation, currently set
to 4MB. Any image larger than this will have its own dedicated device
memory handle via the following flag:
* VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT
Bug: b/218891184
Change-Id: I00318188bf929cf6949d441e5048e9e9640fe5ca
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4428536
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
3a7904e1
|
2023-01-25T23:56:56
|
|
Vulkan: Use VMA suballocation for images
There is a maximum limit for device memory object allocation. On some
platforms, there can be an error regarding too many object allocations
when 4096 device memory handles have been allocated. Suballocation can
help mitigate this issue. In this CL, some images will be allocated
using VMA API calls, which use suballocation.
* Added a new feature (useVmaForImageSuballocation).
* Added VMA allocation for ImageHelper, which is used in initMemory().
* Suballocation is used for VMA image allocation.
* If enabled, mVmaAllocation will be initialized in the ImageHelper
object (instead of mDeviceMemory).
* It is currently used for all platforms.
* Minor change to the name of an arg in CreateBuffer() declaration.
* Added test to make sure we can allocate at least 4096 images on
supported platforms (8000 in the test).
* Skipped the test "NonZeroBaseEmulatedClear" when run on Linux/Intel
if this feature is enabled (due to output color mismatch).
* Skipped several tests for capture/replay on Windows.
Bug: b/218891184
Change-Id: Ibf80c9c8c485b301da7d23b5ba4bcbb1a8e3194f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4191202
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
4b9eb4ba
|
2022-06-03T09:22:41
|
|
Optionally support vulkan_memory_allocator 3.x
Incompatible API is guarded behind a new define, ANGLE_VMA_VERSION.
This allows a soft migration for Chromium and Fuchsia, while allowing
clients like Flutter to roll to a new version that is compatible with
its revision of Skia.
Bug: chromium:1332566
Change-Id: I68cafde13e50445aa8eea2f18203143659a1c627
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3688835
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Dan Field <dnfield@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
83a670ab
|
2021-10-29T09:12:26
|
|
Vulkan: Implement BufferPool using VMA's virtual allocator
VMA's allocation calls used to be sub-allocating a pool of memory. What
we really want is sub-allocate a VkBuffer object. VMA recently added
support to expose the underlying range allocation algorithm via APIs,
which user can use it to sub-allocate any object. This CL uses that new
virtual allocation API to sub-allocate from a pool of VkBuffers.
In this CL we only switched BufferVk::mBuffer to sub-allocate from the
BufferPool object.
Bug: b/205337962
Change-Id: Ia6ef00c22e58687e375b31bc12ac515fd89f3488
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3266146
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
421dbf20
|
2021-10-26T19:06:19
|
|
Revert "Vulkan: Use different strategy for buffer memory allocation"
This reverts commit 0dbe308d91a3526e28fecd9014d873c649f4ef71.
Reason for revert: crbug.com/1253325
Original change's description:
> Vulkan: Use different strategy for buffer memory allocation
>
> This CL uses different memory allocation strategy based on the requested
> size. If the requested size exceeds 1M, we use dedicated memory
> allocation to avoid memory waste associated with the sub-allocator.
> Otherwise we uses VMA's sub-allocator pool. This CL creates two sets of
> customized pool so that we uses different allocation strategy for each
> set of pool: the small pool uses buddy algorithm which favors speed over
> memory and large pool uses default algorithm that favors memory saving
> over speed. This CL also replaces vmaFindMemoryTypeIndexForBufferInfo
> with vmaFindMemoryTypeIndex to avoid create and destroy VkBuffer object
> just try to find memoryTypeIndex.
>
> Bug: b/195588159
> Change-Id: I2bddbfffd77ba2ce6b9389d83a31051c4b748c4d
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2939490
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Tim Van Patten <timvp@google.com>
Bug: b/195588159
Change-Id: I2c8fe8cb2930d16f5212570d32be68e7c6a6e5f3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3244258
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
0dbe308d
|
2021-07-16T14:26:20
|
|
Vulkan: Use different strategy for buffer memory allocation
This CL uses different memory allocation strategy based on the requested
size. If the requested size exceeds 1M, we use dedicated memory
allocation to avoid memory waste associated with the sub-allocator.
Otherwise we uses VMA's sub-allocator pool. This CL creates two sets of
customized pool so that we uses different allocation strategy for each
set of pool: the small pool uses buddy algorithm which favors speed over
memory and large pool uses default algorithm that favors memory saving
over speed. This CL also replaces vmaFindMemoryTypeIndexForBufferInfo
with vmaFindMemoryTypeIndex to avoid create and destroy VkBuffer object
just try to find memoryTypeIndex.
Bug: b/195588159
Change-Id: I2bddbfffd77ba2ce6b9389d83a31051c4b748c4d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2939490
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
8ef1b2a2
|
2021-07-15T15:27:15
|
|
Vulkan: Add BufferMemoryAllocator class
BufferMemoryAllocator class will be responsible for memory allocation
for vkBuffers. The original Allocator class remains the wrapper for
vmaAllocator.
Bug: b/195588159
Change-Id: I26d016e2f8d13ba459d0aa0bd4e1ebf4d0d48251
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3036256
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
1e435d07
|
2020-10-14T13:33:10
|
|
Vulkan: Support dumping VMA stats string
This CL adds support for dumping the VMA stats string, which can be
given to VmaDumpVis.py to visualize the allocations that the VMA has
performed.
To enable dumping the string, set:
RendererVk.cpp
rx::kOutputVmaStatsString = true
Copy the desired JSON output into a text file, and pass that to
VmaDumpVis.py:
python3 \
third_party/vulkan_memory_allocator/tools/VmaDumpVis/VmaDumpVis.py \
-o stats.png stats.txt
The legend for the visualization is available at:
https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator/tree/master/tools/VmaDumpVis
Bug: angleproject:2162
Test: Manual verification
Change-Id: Ic8c1002805dd57e594df724bcf1cdbc1d1599a3e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2472525
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
9a19a996
|
2020-08-26T09:00:50
|
|
Vulkan: Use 4 MB as preferredLargeHeapBlockSize for allocator.
This reduces preferredLargeHeapBlockSize from the default
value of 256 MB to 4 MB, which reduces the initial block
size from 32 MB to 512 KB.
4 MB is the same size as used by Chromium and Skia. It seems
to be a good compromise of not wasting unused allocated space
and not making too many small allocations.
This change is limited to non-Qualcomm GPUs as a number of
tests are failing on Qualcomm after this change and the
initial investigation indicates a potential driver bug. See
http://anglebug.com/4995 for more details.
Bug: chromium:1122718
Bug: fuchsia:58959
Change-Id: Ifdaf863ef38e72098a04ee57dec46ee71cab6ac3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2376891
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: David Reveman <reveman@chromium.org>
|
|
78d10017
|
2020-08-16T16:13:59
|
|
Vulkan: Enable VK_KHR_bind_memory2 extension
Don't assume support for VK_KHR_bind_memory2,
enable the extension, if supported, during device creation.
Also initialize all required extension functions for the
memory allocator.
Bug: angleproject:4966
Change-Id: I878939fb3324723675a2b7dec18ab453b2a9fc77
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2359529
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
4ad0f250
|
2020-07-14T21:22:35
|
|
Revert "Vulkan: Enable VK_KHR_get_memory_requirements2 extension"
This reverts commit d98afb787a24285eccd554daa6b8de197187a636.
Reason for revert: Suspected for angle_perftests failure. See issue.
Bug: chromium:1105609
Original change's description:
> Vulkan: Enable VK_KHR_get_memory_requirements2 extension
>
> 1. Don't assume support for VK_KHR_get_memory_requirements2.
> Enable the extension, if supported, during device creation.
> 2. Also let VMA fill in the function pointers for these commands
> based on Vulkan API version -
> 1. vkGetBufferMemoryRequirements2KHR
> 2. vkGetImageMemoryRequirements2KHR
>
> Bug: angleproject:4830
> Change-Id: Icd0b3baf56732b5f5f49f320c1feb996204169ed
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2293633
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
TBR=syoussefi@chromium.org,jmadill@chromium.org,m.maiya@samsung.com
Change-Id: Ida9a333f897d87e7608d4fafe9da9f1fad0221e4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: angleproject:4830
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2298146
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
d98afb78
|
2020-07-10T17:11:15
|
|
Vulkan: Enable VK_KHR_get_memory_requirements2 extension
1. Don't assume support for VK_KHR_get_memory_requirements2.
Enable the extension, if supported, during device creation.
2. Also let VMA fill in the function pointers for these commands
based on Vulkan API version -
1. vkGetBufferMemoryRequirements2KHR
2. vkGetImageMemoryRequirements2KHR
Bug: angleproject:4830
Change-Id: Icd0b3baf56732b5f5f49f320c1feb996204169ed
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2293633
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
17b4a877
|
2020-05-26T17:02:48
|
|
Vulkan: Pass API version to VMA.
This apparently can save on memory usage in the allocator.
Reported by penghuang@chromium.org.
Bug: angleproject:4685
Change-Id: I6f29280e3fe16f3388c4f8412e0acb09d7f16e58
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2216714
Reviewed-by: Tobin Ehlis <tobine@google.com>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
6c158164
|
2020-05-28T15:19:51
|
|
Vulkan: Fix XFB invalid accesses in buffer OOM.
This uses the "null" buffer in the Renderer to bind an empty
buffer handle so ANGLE can maintain a consistent state.
Bug: chromium:1086532
Change-Id: I1912a1d1cb64433a285fcfced80a675619690a0b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2219140
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
7e5d7dc3
|
2020-05-06T12:56:41
|
|
Vulkan: Initialize all members of VmaVulkanFunctions.
VmaVulkanFunctions was passed to vmaCreateAllocator without initializing
all members. This leads to potential reads of uninitialized variables.
BUG=chromium:1078652
Change-Id: Id349c8fbb2dd3a5a2c64c6a017add3d6f97b78fd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2185191
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
3cb9c4be
|
2020-03-13T13:56:47
|
|
Statically link vulkan-loader on Mac
Disable angle_shared_libvulkan on Mac since we are the only client.
Re-add codepaths to support this.
Bug: angleproject:4477
Change-Id: Ie128c83adaae741636541bbfd6105d160d874a8d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2102954
Commit-Queue: Jonah Ryan-Davis <jonahr@google.com>
Reviewed-by: Tobin Ehlis <tobine@google.com>
|
|
b7d6949b
|
2020-04-17T13:36:14
|
|
Vulkan: Enable persistently mapped buffer objects
The VMA allocator has a handy feature where during memory
allocation we can request persistently mapped memory.
This saves IOCTL overhead for apps that update buffers
frequently.
Bug: angleproject:2162
Change-Id: I870d880033beec343efae6de06f1c5935de4c2c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2155131
Reviewed-by: Tobin Ehlis <tobine@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Tobin Ehlis <tobine@google.com>
|
|
e5491253
|
2020-04-17T12:37:00
|
|
Don't redefine VMA_IMPLEMENTATION in build files and source
VMA_IMPLEMENTATION is defined in the build files, it doesn't need
to be redefined in vk_mem_alloc_wrapper.cpp.
BUG=angleproject:2162
Change-Id: Ie4eceedd2dd3051f8431c7c8c86403250e93f98b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2154538
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
6e0d718a
|
2020-03-31T18:41:57
|
|
Vulkan: Implement device memory sub-allocation
Use AMD Vulkan Memory Allocator for device memory sub-allocation.
We now have a mempool from which all glBuffer memory is allocated.
The CPU overhead involved in repeated IOCTL calls to the kernel is
reduced significantly.
Bug: angleproject:2162
Change-Id: Id7681ffe2ac3d2853141ebe34c7df7b7fdd0d55e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2124519
Reviewed-by: Tobin Ehlis <tobine@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
76d52be3
|
2020-04-07T09:14:29
|
|
Vulkan: Add VulkanMemoryAllocator to DEPS.
Bug: angleproject:2162
Change-Id: If91ae40c1fe818a59d775bb2fa066227dd52859d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2139992
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|