Dxvk: Memory Allocation - VulkanMemoryAllocator

[SicLuceatLux]

I'm not really into Vulkan Programming, but recently I've stumbled across

https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator

This Project was initiated by AMD. My Question would it make sense to implement this in DXVK?
They list up some pretty neat features

Functions that help to choose correct and optimal memory type based on intended usage of the memory.
    Required or preferred traits of the memory are expressed using higher-level description comparing to Vulkan flags.
Functions that allocate memory blocks, reserve and return parts of them (VkDeviceMemory + offset + size) to the user.
    Library keeps track of allocated memory blocks, used and unused ranges inside them, finds best matching unused ranges for new allocations, respects all the rules of alignment and buffer/image granularity.
Functions that can create an image/buffer, allocate memory for it and bind them together - all in one call.

You wouldn't have to take care of this in your code and I'm sure that their Devs will try to make it as performant as possible. It would be nice to here some of your thoughts to this topic.

regards

[doitsujin]

What exactly is the point though? DXVK has had its own memory allocator for almost a year now and it just works, so I don't really see why I would throw it out and replace it with something that is potentially harder to maintain and might even introduce new bugs or performance regressions.

[SicLuceatLux]

Thank you for your fast reply.
I'm aware that DXVK has already a stable Memory Allocator and in this context I want to highlight that your contribution to the Linux community deserves a lot of kudos. So this suggestion should not question the quality of your code.
You have listed up only the con sides of a different Memory Allocator. These are good and valid points, sure. But there are also the same arguments just with a flipped sign.
Maybe it is easier to maintain, might solve existing bugs, could increase performance.
I'm a scientist (physics) my intrinsic intention is to discuss an idea with potential drawbacks or potential gains and yes I'm not an expert on memory allocation.
But if a group of Vulkan experts are creating a Memory Allocator with the goal to make it performant, easy to implement, thread safe etc I would assume that it is worthwhile to think about a potential usage. In addition to this one could mention that they are also shipping some analytic/debug tools with it. Which could be really helpful to spot some bottlenecks or could be used to make some more specific code improvements. (analogous question: Why would someone use BLAS or MKL - it is just matrix operations?)
However with this suggestion I'm not gaining anything. My profession is elsewhere.
This is opensource I'm assuming that I could discuss ideas like I would do this in scientific fields.

[tingvarsson]

So there is a potential performance gain, but the way I see it @doitsujin probably have a lot on his plate already and as it seems he hasn't had much issues with the allocator so far. So it is neither low hanging fruit OR needed, so not high prio.

But if someone else wants to take a crack at it (as a test and do some benchmarking on it), I am pretty sure it can be a solid PR if it shows potential gains.

[doitsujin]

Why are you expecting gains, and what kind of gains? Is there any proof that the current allocator is a bottleneck?

If it ain't broke, don't fix it.

[tingvarsson]

Sorry, I was just reading into the potential gain from the statement:

But if a group of Vulkan experts are creating a Memory Allocator with the goal to make it performant, easy to implement, thread safe etc I would assume that it is worthwhile to think about a potential usage.

Generally I don't agree with "if it aint broke, dont fix it" when it comes to performance related applications (such as a translation layer). But rather "experiment with potential performance gains, and if successful look at how to upstream it".

But I don't think we are actually arguing against each other here.

[SveSop]

I can see that implementing something new could potentially introduce new problems, or for that matter take away loads of time without any gains. No problem.

"If it aint broke, dont fix it"? That kind of defeats the purpose of invention :) I mean.. is a single core cpu "broken"? Nah.. it works just fine... But someone thought of implementing a dual core to speed things up. That probably did cause some headaches on the way too, but having 4-6-8-10+++ core cpu's nowadays + the myriad of ppl overclocking said cpu's with watercooling and whatnot is all done for speed gains.

IF performance is to be gained from a different memory allocator, its 100% legit to go for such a route :) Just cos something works, does not automagically imply that it cant be improved upon :)

[doitsujin]

You can experiment with something when you can legitimately expect gains from it. And I just don't see why that would be the case for a memory allocator. Name me one single game where the allocation overhead is so high to justify this change. Actually, name me one game where the impact of the allocator is even measurable.

Allocating device memory is not something that happens thousands of time per frame, in fact, it is completely irrelevant and doesn't even show up in my profiling tools.

[tingvarsson]

Valuable info that could have been shared earlier I feel:

it is completely irrelevant and doesn't even show up in my profiling tools.

Makes it less relevant to even test, yes.

[SveSop]

@doitsujin
You should probably answer CochainComplex here https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-Mem-Allocator-2.1-Beta and tell him that its not likely :)

Joking aside, the idea of this memory allocator library sounded nice if it had benefits tho. If its just to ease programming and nothing more i will agree its a moot point for DXVK :)

[doitsujin]

Valuable info that could have been shared earlier I feel:

Yes, you're right.

Joking aside, the idea of this memory allocator library sounded nice if it had benefits tho.

I'm sure it's a good library if you don't need to or want to write your own allocator, but as discussed, we don't really need it.

[SicLuceatLux]

Thankyou @doitsujin - this was the answer i was hoping for in the first place.
Legit arguments.