https://github.com/ColonelThirtyTwo/dvulkan

I know there are a few other bindings for Vulkan around, but I didn't see one that generated the bindings from the XML spec, so I made d-vulkan. The included vkdgen.py script leverages the spec parser included in the Vulkan-Docs repo to generate D bindings that can easily be updated with new versions and extensions.

The bindings load all functions using the vkGetInstanceProcAddr function; however, it does not provide any way of loading that function by default, and you must provide it when loading Vulkan. The `with-derelict-loader` dub configuration provides uses derelict.util to load the vkGetInstanceProcAddr function, and I've added a wiki page demonstrating loading the function using GLFW.

This includes bindings for all extensions, except for the platform-dependent VK_KHR_*_surface APIs, which require type declarations from other projects (like X11) that I didn't want to include. The platform-independent VK_KHR_surface extension is available, however.

(Currently the Derelict loader only works in Windows because I don't know the library names for Vulkan on Linux or OSX; if anyone knows them, please tell me, and I'll add them)

Am Sat, 19 Mar 2016 01:12:08 +0000
schrieb Alex Parrill <initrd.gz@gmail.com>:

> https://github.com/ColonelThirtyTwo/dvulkan
> [...]
> 
> (Currently the Derelict loader only works in Windows because I don't know the library names for Vulkan on Linux or OSX; if anyone knows them, please tell me, and I'll add them)

For Archlinux:

usr/lib/libvulkan.so
usr/lib/libvulkan.so.1
usr/lib/libvulkan.so.1.0.5

(see https://www.archlinux.org/packages/extra/x86_64/vulkan-icd-loader/ and maybe https://www.archlinux.org/packages/extra/x86_64/vulkan-intel/ and click on "View the file list" on the bottom of the page)

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:
> https://github.com/ColonelThirtyTwo/dvulkan
>
> This includes bindings for all extensions, except for the platform-dependent VK_KHR_*_surface APIs, which require type declarations from other projects (like X11) that I didn't want to include. The platform-independent VK_KHR_surface extension is available, however.
>

Should be doable using appropriate version blocks.

> (Currently the Derelict loader only works in Windows because I don't know the library names for Vulkan on Linux or OSX; if anyone knows them, please tell me, and I'll add them)

Afaik OSX doesn't support vulkan, due to Apple's metal.

On 19/03/16 13:57, Nicholas Wilson wrote:

> Afaik OSX doesn't support vulkan, due to Apple's metal.

Seems someone is creating a Vulkan wrapper around Metal: https://moltengl.com/moltenvk/

-- 
/Jacob Carlborg

On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson wrote:
> On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:
>
> Should be doable using appropriate version blocks.
>

The problem is that I'd have to define my own structs (Xlib Display, Xlib Window, etc), which will be incompatible with the ones defined in any bindings to those libraries.

On Saturday, 19 March 2016 at 19:37:38 UTC, Alex Parrill wrote:
> On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson wrote:
>> On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:
>>
>> Should be doable using appropriate version blocks.
>>
>
> The problem is that I'd have to define my own structs (Xlib Display, Xlib Window, etc), which will be incompatible with the ones defined in any bindings to those libraries.

You don't. Code in undefined versions need only be syntactically valid
not semantically valid. i.e. the types in versions not compiled in need not
be declared nor defined.

version(none)
{
    xcb_connection_t* con;
}
 will compile fine.

On Sunday, 20 March 2016 at 00:03:16 UTC, Nicholas Wilson wrote:
> On Saturday, 19 March 2016 at 19:37:38 UTC, Alex Parrill wrote:
>> On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson wrote:
>>> On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:
>>>
>>> Should be doable using appropriate version blocks.
>>>
>>
>> The problem is that I'd have to define my own structs (Xlib Display, Xlib Window, etc), which will be incompatible with the ones defined in any bindings to those libraries.
>
> You don't. Code in undefined versions need only be syntactically valid
> not semantically valid. i.e. the types in versions not compiled in need not
> be declared nor defined.
>
> version(none)
> {
>     xcb_connection_t* con;
> }
>  will compile fine.

Yes, I know. The issue is, when compiling with the version, where does xcb_connection_t come from? If I declare it myself, as `struct xcb_connection_t;` in the version block, then that type will be different than the xcb_connection_t declared in the XCB bindings that the developer is likely using, and thus they will be incompatible. If I import a xcb_connection_t from some bindings, it ties d-vulkan to those bindings, which I'd rather not do.

On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote:

>If I import a xcb_connection_t from
> some bindings, it ties d-vulkan to those bindings, which I'd rather not do.

really? It would be a 1 line change. Or alternatively tell the user to import
their own bindings.

On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote:
> If I import a xcb_connection_t from some bindings,
> it ties d-vulkan to those bindings, which I'd rather not do.

By the magic of D:

version (Linux)
{
    import xcb.xcb;
}

...

version (Linux)
{
    xcb_connection_t* con;
}

Also you can make xcb-d dependency optional in DUB.

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:
> https://github.com/ColonelThirtyTwo/dvulkan
>
> [...]

@Alex Parrill: Thanks for sharing! Looks nice. I was just wondering... why did you write the generator in python and not in D? Just curious :)