VMA support

[amerkoleci]

When working with vulkan memory is the main gap for new comes and every engine has to write vulkan memory allocator.
Port or bindings for VulkanMemoryAllocator would do the job.

Feel free to close the issue if not target of project.

[HurricanKai]

We may consider binding to VMA. But there is also this C# port that I've been using with success in my private projects.

[amerkoleci]

We may consider binding to VMA. But there is also this C# port that I've been using with success in my private projects.

Is it mature enought? How far from original and latest C++ version?
Anyway, thanks for link

[HurricanKai]

Not sure whether I'd rely on it in a production capacity. I believe it doesn't have some of the more advanced features. So depends on the use case. I'll keep this open to track what we will do about VMA in the future.

[Perksey]

The working group will meet with the maintainer of VMASharp in adapting VMASharp to be an official Silk.NET offering.

[Perksey]

We will be discussing this in the Working Group meeting on Thursday 5th August at 7pm BST in our Discord server. Feel free to come along and discuss with us.

[Perksey]

Discussed in Working Group meeting on Thursday 5th August 7pm-7:45pm BST:

• Presents a great solution to memory allocation problems
• We should be wary of scope drift if we've expanding our codebase to include more high-level utilities
• Codebase is already quite c#-y
  • how do we stay in-sync with the original VMA? likely won't 100%
  • we likely will never have 100% feature parity with our more-managed bindings
• Likely rename it to something not VMA as this can cause confusion when not being
• Will remain separate in its own package
• Like the idea of a "tools" namespace, but doesn't really work that well
  • really long namespaces can get unwieldy quickly.
• Where do we draw the line with high-level utilities?
  • Wouldn't it make sense to also implement a C#ified version of VkBootstrap? probably not, as it's a specific need (beginners, not really used in production)
  • Practically essential to most production projects in a given workload.
  • If it's only relevant for hobbyists, they won't care about strongly-backed maintenance regimes so it shouldn't be in our umbrella.
  • Within reason: small libraries which most people will use.
  • (we already have windowing and input) What do we/the community want to maintain? Is it a want or need? etc etc
  • No realistic alternative in .NET?
  • We need to have people (plural) that actually know the space
  • They need to meet our quality standards
  • All these are subjective criteria, will evaluate with the working group on a case-by-case basis.

Consensus:

• There are some concerns about scope drift, maintenance, etc (above)
• The working group thinks this will be useful for a lot of the Vulkan users
• Will be incorporated as Silk.NET.Vulkan.MemoryAllocator
• We should consider maybe a "silk community" org later down the line perhaps, to prevent us engulfing everything useful & making it our responsibility.
  • topic for its own meeting

[Perksey]

The Silk.NET Vulkan Memory Allocator project is now underway and has a tracking issue, which supersedes this one. Closing accordingly, thanks for the great suggestion :D

Tracking issue: #605