External memory feature for Vulkan backend

Uniformbuffer3 commented 3 years ago

Hi, i have implemented the external memory functions for the Vulkan backend. This is a work in progress and i would like to know your opinion about it, especially about the api. I have also written a test program (that it is not in the pr), that i use to test these functions. If you want i could upload it somewhere or introduce it as a reproducible test for this feature. As the tests will succeed, i will update the list below. Unfortunately i can test it only from a linux prospective.

Thanks for the dedicated time, Have a good day

Compile test:

[x] Linux
[x] Windows
[x] Android
[x] Wasm32
[ ] MacOS
[ ] iOS

Test application: https://github.com/Uniformbuffer3/gfx_external_memory_test The test application will try to:

Create external memory (will also be wrote some data inside)
Export that memory
Re-import that memory
Check if the data inside the re-imported memory is the same as the one wrote in the first phase

The test application will try to use a subgroup of this function if the system does not support the whole iteration.

Legend: :heavy_check_mark: : Passed :x: : Failed :fast_forward: : Skipped (due to previous failed test or because unsupported by the system)

Linux Intel Haswell Vulkan driver: OPAQUE_FD create_allocate_external_buffer: :heavy_check_mark: export_memory: :heavy_check_mark: import_external_buffer: :heavy_check_mark: data_check: :heavy_check_mark:

DMA_BUF create_allocate_external_buffer: :heavy_check_mark: export_memory: :heavy_check_mark: import_external_buffer: :heavy_check_mark: data_check: :heavy_check_mark:

HOST_ALLOCATION create_allocate_external_buffer::heavy_check_mark: export_memory::heavy_check_mark: import_external_buffer::heavy_check_mark: data_check::heavy_check_mark:

HOST_MAPPED_FOREIGN_MEMORY create_allocate_external_buffer: :fast_forward: export_memory: :fast_forward: import_external_buffer: :fast_forward: data_check: :fast_forward:

Linux Nvidia Maxwell (2° gen) Proprietary Vulkan driver: OPAQUE_FD create_allocate_external_buffer::heavy_check_mark: export_memory::heavy_check_mark: import_external_buffer::heavy_check_mark: data_check::heavy_check_mark:

DMA_BUF create_allocate_external_buffer::fast_forward: export_memory::fast_forward: import_external_buffer::fast_forward: data_check::fast_forward:

HOST_ALLOCATION create_allocate_external_buffer::heavy_check_mark: export_memory::heavy_check_mark: import_external_buffer::heavy_check_mark: data_check::heavy_check_mark:

HOST_MAPPED_FOREIGN_MEMORY create_allocate_external_buffer::fast_forward: export_memory::fast_forward: import_external_buffer::fast_forward: data_check::fast_forward:

kvark commented 3 years ago

What's the status of the PR now?

Uniformbuffer3 commented 3 years ago

I have to test the part of the functions related to exporting and importing an image with a drm format modifier and improve the documentation. Then it should be ready for review. To fit the drm format modifier feature i have slightly changed the api, but the general behaviour is the same.

Uniformbuffer3 commented 3 years ago

I have moved all the structures/enums that has some #[cfg(...)] fields but one: ExternalImageMemory. Unfortunately the DmaBuf variant contains the DrmFormatImageProperties structure. That structure is defined as:

/// Description of drm format properties used to create an image using drm format modifier.
#[derive(Debug, Clone, PartialEq, Eq, Hash)]
pub struct DrmFormatImageProperties {
    /// Drm format modifier
    pub drm_modifier: format::DrmModifier,
    /// Plane subresource layouts
    pub plane_layouts: Vec<SubresourceFootprint>,
}

The problem is that it use the SubresourceFootprint structure that is an already existing one. If i move both ExternalImageMemory and DrmFormatImageProperties to the auxiliary crate, SubresourceFootprint would not be available, so it does not compile. The only solutions that come in my mind are:

Move SubresourceFootprint too to an axiliary crate (not necessarily the external memory one)
Make a copy of SubresourceFootprint with a different name, so that everything can be moved the auxiliary crate. Can i ask you a suggestion about how could i solve this problem?

kvark commented 3 years ago

Thank you for raising this up! It appears to me that making a copy of SubresourceFootprint is a fine way to proceed here.

kvark commented 3 years ago

bors r+

bors[bot] commented 3 years ago

Build succeeded:

gfx-rs / gfx

External memory feature for Vulkan backend #3756