Vulkan bindings

[ZombineDev via Digitalmars-d]

On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote:
> On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote:
>> Hello Vulkan API 1.0 is here and I just wrapped it into D.
>>
>> https://github.com/Rikarin/VulkanizeD
>>
>> Have fun!
>
> Please consider making it a Dub package!
>
> (IMO It would be cool to generate OpenGL and Vulkan bindings 
> directly from the XML spec; std.xml doesn't work in CTFE. 
> Though it would probably take a long time to compile)

I started working on that. I've been reading the Python C Header 
generator code and I'm wondering if would be easier to just 
re-implement it in D, rather than trying to extend it. Currently 
the XML is very C oriented (e.g. has C macros in it), unlike the 
OpenGL spec which was written in a language agnostic way.

The advantages of using the vk.xml is that once the generator is 
complete you can easily adapt it for newer revisions of the spec. 
Also you have much more freedom in how you can organize the 
bindings (split by functions/structs/enums or logically by e.g. 
instance, device, command recording, queues, synchronization, 
shaders, pipelines, etc.), also it's easier to do other stuff 
like using D's builtin types instead of cstdint, generating 
ddoc-formatted function/struct/enum documentation and also 
ddoc-ed unittests from the spec examples. And maybe also provide 
two versions - one with vanilla names (easier if you are 
following tutorials) and one that's written in D style 
(http://dlang.org/dstyle.html) for those who prefer a more 
uniform syntax with the rest of the other D libraries out there.

I have completed the SPIR-V D header (which was trivial to 
generate from the .json file) and I'm also hoping to translate 
the other stuff from the LunarG SDK like the debug layers (no 
auto-generation would be possible there).

Given the advancements in the recent years of the D ecosystem 
(dub, high quality doc generators, CT generation of boilerplate, 
etc.), I think that D can offer even better developer experience 
than C++ for which the API was primary targeted.