colonelthirtytwo/dvulkan

Auto-generated D bindings for Vulkan

dvulkan's Issues

Support for VK_KHR_mir_surface should be removed

See also KhronosGroup/Vulkan-Docs#814

Remove @nogc from functions

Allocation callbacks may theoretically use the GC (ex. if using the default thisAllocator), so Vulkan functions in theory can use the GC.

They will remain nothrow, as throwing exceptions across unknown C code will likely break many things.

Function pointers in types.d should be extern(System)

What makes you think that enums are not global?

Check out DerelictGL3 or DerelictGLFW, global enums all over the place. I strongly recommend to remove this behavior, this deviates unnecessarily from the original. You could alias VkResult as int, its nothing else in the vulkan.h header.
I read Manuzor's pull request, I disagree with his point, but think if it is an optional feature it would be ok. However, the bindings you ship with this repo should be as close as possible to the original.

In any case, thanks for the awesome work.

Specify extensions to load via versions

To cut down on loading times, extension functions and structures should be put in version statements, so that the developer can specify which extension functions that their project actually uses and needs to be loaded versus functions that will never be used and can be skipped.

Deprecate VK_NULL_HANDLE since it is impossible to implement in D

It doesn't appear possible to portably implement VK_NULL_HANDLE in D at this time, so it should be discouraged.

The main issue is that on 32-bit platforms, VK_NULL_HANDLE must be both a null pointer (for dispatchable types like VkDevice, which are pointers) and zero (for non-dispatchable types like VkFence, which are 64-bit integers). Vulkan defines VK_NULL_HANDLE to 0, which works in C because in C, zero is implicitly convertible to the null pointer. However, in D, it is not; trying to convert 0 to a pointer without a cast results in a type error.

As an alternative, I will provide VK_NULL_DISPATCHABLE_HANDLE and VK_NULL_NONDISPATCHABLE_HANDLE. The value Vk(Type).init will also work (and works now). VK_NULL_HANDLE will be marked as deprecated with a message to the developer.

See also: https://forum.dlang.org/thread/[email protected]

Derelict loader needs libName for Linux

I don't have a Vulkan installation on Linux at the moment, so I don't know the Vulkan library name on Linux (or Mac, if Vulkan even exists there).

If someone knows, please leave a comment.

Make DVulkanLoader.loadAllFunctions(VkDevice device) static

Otherwise DVulkanLoader.loadAllFunctions(device) does not work because of missing this pointer.

Load function pointers to struct

Working with multiple devices in Vulkan requires either using the dynamically dispatching functions loaded with vkGetInstanceProcAddr or by loading separate sets of device-specific functions using vkGetDeviceProcAddr and storing them individually.

d-vulkan supports the former, but not the latter as functions are loaded globally.

Make VK_NULL_HANDLE a pointer type.

Please change the defintion to

enum VK_NULL_HANDLE = null;

in vkdgen.py, line 60 (was = 0 before), so that we don't get type errors when doing tests like physicalDevice == VK_NULL_HANDLE.

Loading vkDestroyInstance with vkGetDeviceProcAddr wrong?

After creating an instance and calling DVulkanLoader.loadAllFunctions(instance) initializes vkDestroyInstance just fine, using vkGetInstanceProcAddr(instance, "vkDestroyInstance") internally.

But when creating a device and calling DVulkanLoader.loadAllFunctions(device), the function internally calls vkGetDeviceProcAddr(device, "vkDestroyInstance") which returns null and thus resets vkDestroyInstance to null.

Is that a vulkan implementation error, or should we just not use vkGetDeviceProcAddr to retrieve vkDestroyInstance? I couldn't find any list which functions should be loaded with any of the two loader functions.

Add platform APIs support

Add bindings for the Vulkan platform extensions.