www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - d-vulkan, automatically generated D bindings for Vulkan

reply Alex Parrill <initrd.gz gmail.com> writes:
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)
Mar 18 2016
next sibling parent Johannes Pfau <nospam example.com> writes:
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)
Mar 19 2016
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Mar 19 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Mar 19 2016
prev sibling parent reply Alex Parrill <initrd.gz gmail.com> writes:
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.
Mar 19 2016
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Mar 19 2016
parent reply Alex Parrill <initrd.gz gmail.com> writes:
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.
Mar 19 2016
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Mar 19 2016
prev sibling parent burjui <bytefu gmail.com> writes:
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.
Mar 21 2016
prev sibling next sibling parent reply Manuel Maier <mjmaier gmx.de> writes:
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 :)
Mar 21 2016
parent Manuel Maier <mjmaier gmx.de> writes:
On Monday, 21 March 2016 at 09:27:35 UTC, Manuel Maier wrote:

 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 :)


I see now... The Vulkan docs provide python modules for easier 
integration already. Makes sense.
Mar 21 2016
prev sibling parent Alex Parrill <initrd.gz gmail.com> writes:
On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

 https://github.com/ColonelThirtyTwo/dvulkan


I've updated the bindings to Vulkan 1.0.13, and added a few fixes.

Platform support will come in a bit. I'm going to use void* 
pointers for most of the platform-specific types, so you can use 
whatever bindings you want to use with them (whether they are 
full bindings or just one little opaque struct alias to use with, 
say, glfw).
May 21 2016