Using VMA for rendy

(Thomas Schaller) #1
  • rendy - future rendering engine of Amethyst
  • VMA - Vulkan Memory Allocator (library)

Discussion so far:

(from Discord)

@omni-viral Today at 12:47 PM

It seems that we would want to use VMA

But we can’t use VMA

gfx-hal doesn’t permit us to use libraries written for Vulkan. Which is …

@torkleyy Today at 1:09 PM

What’s VMA?

@omni-viral Today at 1:20 PM

It’s state of the art vulkan memory allocator developed by amd.

Much better and feature rich than what I cooked for rendy

@torkleyy Today at 1:32 PM

Okay, but it’s not available for other backends?

@omni-viral Today at 2:19 PM

It would be available if gfx would have ffi safe api

@Xuh Today at 2:21 PM

I think it would need to go right in gfx-backend-vulkan - looking over the code now

basically bind_*_memory, allocate_memory, etc… calls would go away, and the existing vk create_buffer call would be replaced by the one in vk-mem

i.e. https://github.com/gfx-rs/gfx/blob/master/src/backend/vulkan/src/device.rs#L1006

@omni-viral Today at 2:22 PM

It could. But it will defeat the idea of gfx-hal

Being Vulkan adapter for other backends

“MoltenVK written in rust”

@Xuh Today at 2:25 PM

MoltenVK still uses the vulkan API, and then that ICD routes to Metal, so it should still be fine (I actually made sure vk-mem works with MoltenVK, which is nice)

I think gfx-hal is exposing a bit too much low level API to the high level, looking at it

it’s probably mappable still, just annoying

@omni-viral Today at 2:25 PM

We’d better discuss it here https://gitter.im/gfx-rs/gfx

gfx-rs/gfx

So gfx team would participate

> MoltenVK still uses the vulkan API There is gfx-portability lib that exposes real vulkan C API wrapping gfx-hal API

But going ash -> gfx-portability -> gfx-hal -> gfx-backend-* seems unreasonable

@Xuh Today at 2:33 PM

that’s… weird

though isn’t it more like gfx-portability -> gfx-hal -> gfx-backend-vulkan -> ash in this case?

@Viral Today at 2:46 PM

If you write in rust it is either gfx-hal -> gfx-backend* -> backend-specific-lib or, if you want real Vulkan API, then ash -> gfx-portability -> gfx-hal -> gfx-backend-(not vulkan) and just ash for Vulkan backend. Because ash -> gfx-portability -> gfx-hal -> gfx-backend-vulkan -> ash is too recursive for my taste.All in all gfx-hal kinda forces you to use its own API. Or you would have to use the long chain that goes from Rust to C and back, like some hobbit adventurer

@Xuh Today at 2:50 PM

yeah, though vk-mem should plugin to gfx-backend-vulkan fine

since vk-mem just calls normal vulkan function pointers just like gfx-backend-vulkan is doing

i.e. allocate_memory, create_buffer, etc…

@omni-viral Today at 2:53 PM

Yeah. But user doesn’t know which backend he uses

So you’d have to extend gfx-hal API surface

@Xuh Today at 2:53 PM

does it matter though? if it ends up using backend-vulkan it would use vk-mem, if it was dx12 it wouldn’t, etc…

@omni-viral Today at 2:53 PM

And implement it for all backends

@Xuh Today at 2:53 PM

but that’s correct

vk-mem is vulkan only

the hal can map stuff like gpu only, cpu only, gpu to cpu, cpu to gpu access requests to the backends, and then vk-mem can allocate the right type of memory for that

@Viral Today at 2:54 PM

That’s what old gfx was doing

Except it was implemented for opengl only


(from Gitter)

Zakarum
@omni-viral
13:04

How to use library written for Vulkan with gfx?

Dzmitry Malyshau
@kvark
14:50

Needs backend-specific entry points to allow third party work and contain side effects. Effectively, ‘unsafe{}’ for graphics :wink:

Zakarum
@omni-viral
14:51

But I want to use it for all backends

Graham Wihlidal
@gwihlidal
14:59

yeah, that makes sense. Basically I would really like gfx-backend-vulkan to use my vk-mem crate (AMD’s vulkan memory allocator). I made the public API use ash vk handles and loader function pointers
vk-mem basically replaces the raw ash create_buffer, allocatememory, bind*_memory calls with a single create_buffer \ destroy_buffer call, and internally handles tons of stuff like persistent host mapping, sub allocations, defrag, etc…

Graham Wihlidal
@gwihlidal
15:12

@Toasterthegamer you mean vulkan -> moltenvk validation layers? that does work, but you need the right env var configuration
i.e. I use:
export SDK_PATH=/path/to/vulkansdk-macos-1.1.92.0
export DYLD_LIBRARY_PATH=$SDK_PATH/macOS/lib
export VK_ICD_FILENAMES=$SDK_PATH/macOS/etc/vulkan/icd.d/MoltenVK_icd.json
export VK_LAYER_PATH=$SDK_PATH/macOS/etc/vulkan/explicit_layer.d

Zakarum
@omni-viral
15:13

@gwihlidal I bet he use gfx-hal -> gfx-backend-metal

Graham Wihlidal
@gwihlidal
15:13

oh raw metal, then he’s on his own :slight_smile:

Dzmitry Malyshau
@kvark
15:17

@omni-viral I don’t understand. You want a library not integrated with gfx-rs to magically work with gfx-rs on all backends?

Zakarum
@omni-viral
15:17

@kvark Yeap :slight_smile:

Dzmitry Malyshau
@kvark
15:17

I know it’s Christmas and all, but we need to keep the magic at reasonable levels

Thomas Schaller
@torkleyy
15:17

Just creating a forum post, this discussion was started on Discord and everybody will lose track otherwise.

Zakarum
@omni-viral
15:18

I wont to be able to write a binding/wrapper/something to that library that will be posiible to utilize with gfx
Without rewriting whole library

Graham Wihlidal
@gwihlidal
15:18

vk-mem won’t work with metal or dx12 of course, it should just plug in to the direct vk code in gfx-rs

Dzmitry Malyshau
@kvark
15:18

You can use the vulkan-focused libraries (that don’t integrate with gfx-rs directly) with gfx-portability.

Graham Wihlidal
@gwihlidal
15:19

yeah, anything that intercepts vulkan calls and maps them to something else (i.e. molten vk) can of course use vk-mem
in fact, I made sure vk-mem works with molten vk (it does)

Zakarum
@omni-viral
15:19

@kvark Since I’m writing in Rust I don’t want to use gfx-portability

Thomas Herzog
@karroffel
15:19

So basically I guess he wants a gfx-portability that you can conditionally use to hook into vulkan calls so that vulkan libraries are usable?
I don’t think that would be possible without quite some effort, I’d rather focus on making gfx libs :sunglasses:

Graham Wihlidal
@gwihlidal
15:20

does gfx-portability end up using gfx-backend-vulkan?

Zakarum
@omni-viral
15:20

No. I basically want gfx-hal to implement vulkan C ffi-compatible API :wink:

Thomas Herzog
@karroffel
15:21

Isn’t that exactly what gfx-potability is? implementing the Vulkan API using gfx

Zakarum
@omni-viral
15:21

Ofc

Thomas Herzog
@karroffel
15:21

does gfx-portability end up using gfx-backend-vulkan?

It can AFAIK, but it can use all the gfx-hal backends available

Graham Wihlidal
@gwihlidal
15:22

it should work fine to just use vk-mem in gfx-backend-vulkan, then gfx-portability would benefit from it (if the selected backend under the hook is mvk or vk), and also if someone is using gfx-hal or gfx-backend-vulkan directly, no?

Zakarum
@omni-viral
15:24

@gwihlidal it’s vice versa. User wants to use rust API. User picks gfx-hal. gfx-hal doesn’t provide allocators (same as Vulkan), user must provide his own. User wants to use VMA. User can’t. User is sad :frowning:

Graham Wihlidal
@gwihlidal
15:28

right, but I’m saying the vulkan backend for official gfx-rs should ALWAYS use vk-mem
not make the app implement it with a plugin

2 Likes

#2

@gwihlidal Aren’t you saing MoltenVK should always use metal specific allocator?

0 Likes

(Graham Wihlidal) #3

MoltenVK will still require the app to use vulkan API calls (like vkAllocateMemory, vkBindBufferMemory, etc…) like it currently does, so MoltenVK already maps those calls from VK -> Metal. Using vk-mem (VMA) sitting above MoltenVK, the same API calls end up being made by vk-mem, so nothing downstream needs to change there. Metal will end up with similar efficiency using vk-mem to a normal Vulkan app using vk-mem (fewer allocations, sub-object allocation, etc…)

0 Likes

#4

So. Since gfx-hal is essentially MoltenVK alternative that is written in Rust and aims to support more backends, I believe it must be treated the same. And user of gfx-hal should use VMA to drive allocations.

0 Likes

(Graham Wihlidal) #5

VMA is vulkan only though (it’s very specific to vulkan memory requirements\restrictions\etc. and wouldn’t map to other APIs). By the Vulkan gfx render backend using vma, all apps using gfx-hal (when vulkan is used) would benefit without needing to worry about the allocation specifics (which is currently the case). i.e. doing a create_buffer would still look the same, but under the hood a more efficient allocation strategy is being performed (i.e. sub-object allocations).

I don’t think the app should have this expose to it, because it doesn’t make sense with a 1:1 mapping that is backend agnostic.

0 Likes

#6

This isn’t really the case:

  • gfx-portability is a MoltenVK alternative, and libraries like VMA should already work with it (just like it would for MoltenVK).
  • gfx-portability is built on top of gfx-hal.
  • gfx-hal exposes a Rust API so you can interact with backends more directly (i.e. instead of having to interact with them using raw pointers like gfx-portability). The downside is that you can’t use libraries built on top of Vulkan, because the API is necessarily different.
1 Like

#7

@groves

You got this right.
The problem is that there are many libraries aimed to help you write app using Vulkan backend.
For example VMA is great memory management tool. I wouldn’t be able to write one like this in Rust for gfx-hal. gfx-hal users are left with limiting choice of libraries they can use. Unless they decide to use gfx-portability API instead.

2 Likes

(Gray Olson) #8

I think it’s somewhat unreasonable to expect that hal should be able to interop easily with any tool made for Vulkan, but for something like VMA I think it could be reasonable that an exception could be made in that it could be “blessed” by hal, as @kvark and @gwihlidal were talking about on gitter I believe. Basically, integrating VMA functionality into hal’s rust-frontend interface, while also leaving the lower level “raw” vulkan-esque functions for those that want to use them as well.

Of course this would require supporting those functions for the other backends as well, but it seemed like the VMA interface already mapped fairly well to DX12; not sure about the story with metal.

0 Likes