Skip to content

Add external memory support for vulkan on windows & linux #275

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 5 commits into
base: main
Choose a base branch
from

Conversation

SupaMaggie70Incorporated
Copy link

@SupaMaggie70Incorporated SupaMaggie70Incorporated commented Jun 20, 2025

This has been tested by my own project, though no in tree testing is there yet(not sure how I'd add that). Also, the testing is only for vulkan Linux but I suspect it would also work on Windows in its current state.

This short PR adds support for memory allocated for external use. The code probably can't be accepted in its current state. For example, it has a #[allow(clippy::too_many_arguments, clippy::fn_params_excessive_bools)] attribute you probably wouldn't want in production code.

Putting this out here for now and for review.

Based on discussion in #274, also going to ping @Jasper-Bekkers :)

Implementation details: the memory is only allocated with support for exporting it later. The user must manually export the memory later, though this isn't very difficult. Used as a reference was this article from vulkan docs.

@SupaMaggie70Incorporated
Copy link
Author

I've verified in a personal project that this code works. I'd like to get a review of it so we can hopefully get this merged! Going to ping @Jasper-Bekkers, hopefully this isn't too much of a hassle. No rush here just want to make sure you see it!

}

impl MemoryBlock {
#[allow(clippy::too_many_arguments, clippy::fn_params_excessive_bools)]
Copy link
Member

Choose a reason for hiding this comment

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

The refactor here should be to make a MemoryBlockCreateDesc that has these parameters.

Comment on lines +385 to +386
// On other platforms you can't create an external capable allocator, so this would be unreachable
#[cfg(any(windows, all(unix, not(target_vendor = "apple"))))]
Copy link
Member

Choose a reason for hiding this comment

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

I think on other platforms then we should fail with an error rather then silently failing to create an exportable texture.

Copy link
Author

@SupaMaggie70Incorporated SupaMaggie70Incorporated Jul 17, 2025

Choose a reason for hiding this comment

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

The error would occur elsewhere, see lines 843-845

Comment on lines +378 to +383
#[cfg(windows)]
let mut export_info = vk::ExportMemoryAllocateInfoKHR::default()
.handle_types(vk::ExternalMemoryHandleTypeFlags::OPAQUE_WIN32_KHR);
#[cfg(all(unix, not(target_vendor = "apple")))]
let mut export_info = vk::ExportMemoryAllocateInfoKHR::default()
.handle_types(vk::ExternalMemoryHandleTypeFlags::OPAQUE_FD_KHR);
Copy link
Member

Choose a reason for hiding this comment

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

Would you mind replacing these #[cfg] compilation guards with if cfg!()? None of this ash code is guarded behind conditional compilation, and that way all this code is modifiable and compile-testable even on platforms where that cfg!() expression evaluates to false.

Choose a reason for hiding this comment

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

Trouble here is that they are different types, and they must exist until the allocation is actually done. So I could switch to if cfg!(), but I think the code would look worse (probably you would end up having an option for each type). Let me know if you still want me to make the change

@SupaMaggie70Incorporated
Copy link
Author

I think I've addressed most comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants