AMD are continuing their open source push with 'Anvil' a new MIT-licenses wrapper library for Vulkan. Its aim is to reduce the time developers spend to get a working Vulkan application.
Included features:
- A memory allocator which allocates as little memory as necessary for the specified list of memory regions, miptails, objects or subresources from one or more memory heaps, depending on platform’s capabilities.
- Automatic object lifetime management, thanks to auto pointers being used across the library.
- Descriptor sets and descriptor set layouts are automatically generated from user-created descriptor set groups.
- Helper routines for FP16<->FP32 conversion.
- Integrated validation support. Validation can be enabled by changing a single argument value at Vulkan instance creation time.
- Integration with glslang for run-time GLSL -> SPIR-V conversion. Assembly of the result blob can also be retrieved for further analysis.
- Object tracker which can be used to detect wrapper object leaks.
- Page tracker, useful for the purpose of tracking memory bindings, if sparse residency is used for buffers or images.
- Windowing system integration – current support includes XCB and Windows platforms.
It supports AMD-specific Vulkan extensions, but AMD claim it will work with any Vulkan implementation.
You can find Anvil on GitHub.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
5 comments
Does this mean that programming with Vulkan + anvil will reintroduce some of the overhead that one abandons when dropping openGL?
2 Likes, Who?
Does this mean that programming with Vulkan + anvil will reintroduce some of the overhead that one abandons when dropping openGL?Not really. Anvil is not a higher level API that completely abstracts away Vulkan, but basically a set of tools and helpers that make debugging easier and reduce the need to write your own boilerplate. Using AMD's Anvil or Nvidia's VkHLF or indeed any of the available helper libraries will still allow you to thread your workloads effectively and do all kinds of things OpenGL makes difficult.
Also keep in mind that it's entirely possible to write Vulkan code that performs worse than OpenGL. Vulkan is hard. These libraries make it more accessible.
EDIT: I tried to resist fixing that minor typo but I'm weak.
Last edited by tuubi on 24 March 2017 at 5:26 pm UTC
10 Likes, Who?
EDIT: I tried to resist fixing that minor typo but I'm weak.
I know how that feels.
2 Likes, Who?
It's terminological pedantry, but bear with me: isn't this more a "framework" than a "wrapper"?
1 Likes, Who?
It's terminological pedantry, but bear with me: isn't this more a "framework" than a "wrapper"?
Point taken as far as I'm concerned. I mean, my impression of what a "wrapper" is, is that it pretty much obscures what it wraps--you are now working with the "wrapper" at a higher, or translated, level, instead of working with the lower-level wrapped thing. Whereas with this Anvil thingie, it sounds more like it automates certain relatively predictable but onerous tasks one does in Vulkan while allowing you to still do the core Vulkan programming stuff yourself directly with Vulkan--so it's not really an intervening "wrapper" layer for the most part.
0 Likes
Patreon
PayPal
See more from me