Skip to content

Update Vulkan Memory Allocator to 3.2.1 #16923

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Xphalnos
Copy link
Contributor

  • Vulkan Memory Allocator Update from 2.3.0 (2019) to 3.2.1 (2025)
  • May provide better support for Vulkan 1.4
  • This may likely improve performance on less powerful machines

@Megamouse Megamouse requested a review from kd-11 March 25, 2025 22:03
@AniLeo
Copy link
Member

AniLeo commented Mar 26, 2025

The reason why it wasn't updated so far is because it requires more work than just updating the library and the API

Adding @kd-11

Copy link
Contributor

@kd-11 kd-11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We typically don't allow contributors outside core members to update source-only deps for obvious reasons.
Maybe we should make this a submodule instead.

Ftr - no performance or behavioural change is expected, with the exception of maybe worse performance. We tuned the previous version ourselves and upstreamed the optimizations which is why we're on some ancient version where behavior is guaranteed. All that would need to be re-vetted across multiple vendor hardware due to the differences in alignment constraints.

@Xphalnos
Copy link
Contributor Author

We typically don't allow contributors outside core members to update source-only deps for obvious reasons. Maybe we should make this a submodule instead.

Ftr - no performance or behavioural change is expected, with the exception of maybe worse performance. We tuned the previous version ourselves and upstreamed the optimizations which is why we're on some ancient version where behavior is guaranteed. All that would need to be re-vetted across multiple vendor hardware due to the differences in alignment constraints.

I applied the optimizations you made in this PR. Are there any other optimizations you made?

@AniLeo
Copy link
Member

AniLeo commented Mar 26, 2025

+1 for submodule instead of having the header directly here

@Megamouse
Copy link
Contributor

I'll make a submodule out of this (without updating)

@Megamouse
Copy link
Contributor

Otherwise this is not really maintainable

@Megamouse Megamouse added RSX Render: Vulkan Build and CI Anything related to the build process and continuous integration labels Mar 26, 2025
@Megamouse
Copy link
Contributor

This needs to be rebased since we now use a submodule

@digant73
Copy link
Contributor

digant73 commented Apr 2, 2025

this PR seems to be related to #13045

@digant73
Copy link
Contributor

digant73 commented Apr 5, 2025

if the optimizations made on the currently used customized Vulkan Memory Allocator (2.3.0) are only those provided in #9738 then they have been also merged on official repo https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator in 2021/02/16 and kd-11/rpcs3 added on project's white list.

image

I also tested the current master of vk. mem. alloc. 3.2.1 (minor changes compared to this PR (it is the tagged version)) and it seems properly working with rpcs3 at least as the currently used custom 2.3.0.
Of course the new 3.2.1 is different than the old 2.3.0 and the code optimized by kd-11 (in function VmaBlockMetadata_Generic::CheckAllocation()) has been reworked in deep.
Tested on games with high usage of RSX (90%-100%) such as Killzone, Resistance etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Build and CI Anything related to the build process and continuous integration Render: Vulkan RSX
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants