hal: dedicated buffer/image memory

[kvark]

Fixes #2511
Closes #2513

The idea is that backends can implement this more efficiently than the default implementation.

PR checklist:

• make succeeds (on *nix)
• make reftests succeeds
• tested examples with the following backends:
• rustfmt run on changed code

[msiglreith]

should be removed

[kvark]

It's there for future work on the topic ;)

…

On Jul 31, 2019, at 03:15, msiglreith ***@***.***> wrote: @msiglreith approved this pull request. In src/backend/vulkan/Cargo.toml: > @@ -29,6 +29,7 @@ ash = "0.29.0" gfx-hal = { path = "../../hal", version = "0.2" } smallvec = "0.6" winit = { version = "0.19", optional = true } +#vk-mem = { version = "0.1", optional = true } should be removed — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[zakarumych]

To actually do that more efficiently, the function must return a view into memory with offset and size.

[kvark]

The user is expected to still call get_buffer_requirements before doing this, so the size is known. And the offset is known to be zero. Is this not enough?

[zakarumych]

Oh, so this will work only for dedicated allocations?

[zakarumych]

I thought we want to integrate vma into vulkan backend this way

[kvark]

I think what we can do with VMA is:

1. make it a compile time optional dependency
2. turn Memory into an enum, with one variant for normal allocations and another - for VMA-owned ones. The code dealing with memory would need to match the enum, but I don't think it's a problem.
3. the user is then expected to treat the Memory as dedicated allocation

Does that sound reasonable?

[kvark]

So the memory type exposed by the Vulkan backend would be:

enum Memory {
  Physical(vk::Memory),
  SubAllocated(vma::Allocation),
}

Mapping a Memory::SubAllocated will go though VMA and just give out a pointer without really doing any more Vulkan mapping, if I understand correctly, much like with Rendy-memory.

[zakarumych]

If VMA has no limitations here. Rendy has to map all non-dedicated mappable memory persistently to allow this, which is not optimal. I wonder how VMA does that.

[kvark]

which is not optimal

Is it, really? My understanding is that it's both optimal and recommended for CPU-visible memory.

[zakarumych]

It's not a problem when RAM is abundant, like on typical modern PC. But in other cases it may be not the best approach.

[kvark]

Looks like it doesn't map memory by default on creation, unless there is a specific flag provided. Relevant docs - https://gpuopen-librariesandsdks.github.io/VulkanMemoryAllocator/html/memory_mapping.html
It confirms that VMA acts roughly like rendy-memory, and the approach this PR is taking should work.

[kvark]

I suppose I can integrate VMA in this PR as a validation of the API.