khronosgroup / vulkan-hpp Goto Github PK

When using UniqueDebugReportCallbackEXT instead of DebugReportCallbackEXT i get two linker errors. one for Create and Destroy (i translated the error from german to english, so this might not be the exact Error String (marked italic):

../engine/libEngine.a(instance.cpp.o): In function `vk::Instance::createDebugReportCallbackEXT(vk::DebugReportCallbackCreateInfoEXT const&, vk::Optional<vk::AllocationCallbacks const>) const':
~/VulkanSDK/1.0.42.0/x86_64/include/vulkan/vulkan.hpp:26901: undefined reference to`vkCreateDebugReportCallbackEXT'

../engine/libEngine.a(instance.cpp.o): In function `vk::Instance::destroyDebugReportCallbackEXT(vk::DebugReportCallbackEXT, vk::Optional<vk::AllocationCallbacks const>) const':
~/VulkanSDK/1.0.42.0/x86_64/include/vulkan/vulkan.hpp:26920: _undefined reference to `vkDestroyDebugReportCallbackEXT'

The second error occurs when creating a variable holding a uniqueDebugReportCallbackEXT e.g.

class abc {
private:
  vk::UniqueDebugReportCallbackEXT callback_;
}

The first error occurs as soon as i try to access the vk::Instance::createDebugReportCallbackEXTUnique method

Allowing for easier reference to the differences from vulkan.h from IDE's and via browser.

I was reading the header and trying to figure our how things work together when I could find what actually use a InstanceCreateInfo. Also is seems more in missing like i couldn't find vk::Instance.

I believe this commit is the one that broke things
be9beb8

Thanks

Hello,
I'm still digging into Vulkan and this C++ API.

During this I saw, that there are no destructors for the objects, which is fine, because those would need more memory (maybe additional reference to the vk::Instance etc).

Anyway wouldn't it be fine to create as "nice to have" a wrapper for the vulkan objects, which takes care of their destruction? I'm thinking of an additional template class for example called "vk::Deleter" which wraps a vulkan object with the correct destroy function.

It's possible to make the flags class look even more like native flags by adding a new constructor which accepts a nullptr_t whic has a result would accept 0 as only integer. This way one could write

SomeFlag flag = 0.

In addition to this we could introduce operator == and operator != with nullptr_t to allow comparisons with 0. This change has one side effect can be considered harmless or harmfull. In addition to 0 Vulkan-Hpp would also accept nullptr as input for the constructor and the == and != operators.

Would this feature be a gain or loss?

Using clang, with exceptions disabled, client code is hitting several error messages such as:

../../third_party/vulkan_loader_and_validation_layers/include/vulkan/vulkan.hpp:747:41: error: cannot use 'throw' with exceptions disabled
case Result::eErrorOutOfHostMemory: throw OutOfHostMemoryError ( message );

This change seems to have introduced the problem:

commit 6e9d9b5
Author: Damian Dyńdo [email protected]
Date: Wed Apr 26 09:30:24 2017 +0200

Introduce custom exceptions for Vulkan-Hpp (#97) (#99)

imageMemoryBarrier.srcAccessMask == 0

Hi, how can I check for this?
I guess thats where the bool operator kicks in:
if(imageMemoryBarrier.srcAccessMask)

But how to pass 0 Flag, e.g. DependencyFlag 0
Like this i guess: {}

But how do I get the flagmask of for example vk::ShaderStageFlagBits?

causes

[T+0.098 main ERROR] DS Attempt to set lineWidth to 0.000000 but physical device limits line width to between [0.500000, 10.000000]!

Is there a reasonable default (e.g. 1?)

when launch:

VulkanHppGenerator foo/Vulkan-Docs/src/spec/vk.xml

and the vk.xm file is latest version of https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/spec/vk.xml (https://raw.githubusercontent.com/KhronosGroup/Vulkan-Docs/85184f305afe0f2e9e99cc9525e8ce25c32e74e0/src/spec/vk.xml)

gets

caught exception: basic_string::_M_construct null not valid

┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/tmp/makepkg/vulkan-git/src/build-vulkan-hpp]|
└───╼  ./VulkanHppGenerator /tmp/makepkg/vulkan-git/src/Vulkan-Docs/src/spec/vk.xml 
Loading vk.xml from /tmp/makepkg/vulkan-git/src/Vulkan-Docs/src/spec/vk.xml
Writing vulkan.hpp to /tmp/makepkg/vulkan-git/src/Vulkan-Hpp/vulkan/vulkan.hpp
caught exception: basic_string::_M_construct null not valid
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/tmp/makepkg/vulkan-git/src/build-vulkan-hpp]|
└───╼  echo $?
255

Currently in code, there is static assert to check if vulkan's header file is same version as the one generator is currently configured to. This makes it impossible to use vulkan.hpp from 1.0.x._ with vulkan.h from 1.0.y._ where x < y (e.g. can't use vulkan.hpp from 1.0.46.0 with vulkan.h of 1.0.50.0).

Since Vulkan's API shouldn't change that much between patch-versions, maybe it would be enough to check for major and minor versions only (and maybe warn if patch version isn't the same)?

I get that having exact same version is best, but I think that if API doesn't change, there shouldn't be a reason for generated earlier headers to not work with newer Vulkan headers.

The problem I see is that when someone want to use Vulkan-Hpp in his project, he should supply both vulkan.h (and other Vulkan headers) and vulkan.hpp for them to match, since some OSes might have older packages installed which might conflict with Vulkan-Hpp version (and using user-installed might not be best, as I'm not sure if API of Vulkan-Hpp is 100% stable and backward compatibility is maintained all the time).

It's not best, but maybe worth considering? What's your opinion?

Currently, Vulkan-Hpp uses the Flags class and some helping structure to emulate bitfields (especially bitwise logical operations on them) on C++11 scoped enums. However, this can be vastly simplified by using some template magic.

To make sure the underlying type of Vulkan-Hpp matches the upstream flag type provided by the enum (e.g. VkAttachmentDescriptionFlags, usually typedef to VkFlags), enums could further specify their base type. Example:

enum class ColorComponentFlags : VkColorComponentFlags
  {
    eR = VK_COLOR_COMPONENT_R_BIT,
    eG = VK_COLOR_COMPONENT_G_BIT,
    eB = VK_COLOR_COMPONENT_B_BIT,
    eA = VK_COLOR_COMPONENT_A_BIT
  };

Note that instead of ColorComponentFlagBits, the enum should be called ColorComponentFlags after such a change since it would also represent the bitfield itself and not only its flags.

I'm on Linux with the latest NVidia drivers, and VK_HEADER_VERSION is 39.

Additionally, I get the following problems:

vulkan.hpp:44:1: error: static_assert failed "Wrong VK_HEADER_VERSION!"
static_assert( VK_HEADER_VERSION ==  38 , "Wrong VK_HEADER_VERSION!" );
^              ~~~~~~~~~~~~~~~~~~~~~~~~
vulkan.hpp:16762:3: error: static_assert failed "struct and wrapper have different size!"
  static_assert( sizeof( ObjectTableIndexBufferEntryNVX ) == sizeof( VkObjectTableIndexBufferEntryNVX ), "struct and wrapper have different size!" );
  ^              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vulkan.hpp:16762:3: error: static_assert failed "struct and wrapper have different size!"
  static_assert( sizeof( ObjectTableIndexBufferEntryNVX ) == sizeof( VkObjectTableIndexBufferEntryNVX ), "struct and wrapper have different size!" );
  ^              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vulkan.hpp:44:1: error: static_assert failed "Wrong VK_HEADER_VERSION!"
static_assert( VK_HEADER_VERSION ==  38 , "Wrong VK_HEADER_VERSION!" );
^              ~~~~~~~~~~~~~~~~~~~~~~~~
vulkan.hpp:16762:3: error: static_assert failed "struct and wrapper have different size!"
  static_assert( sizeof( ObjectTableIndexBufferEntryNVX ) == sizeof( VkObjectTableIndexBufferEntryNVX ), "struct and wrapper have different size!" );

What do you think about adding custom exception/error classes derived from one of the std::exception derived classes? Currently without special filtering developer can't really know if given exception (like std::system_error was thrown by Vulkan-Hpp or other piece of code and with that developers would be able to use natural exceptions "filtering" like:

try {
    // some Vulkan-Hpp code that can throw
    // with some normal code that can throw
} catch(const vk::error& vk_error) {
    // error from vulkan-related code
} catch(const std::exception& exception) {
    // error related to normal code / STL / etc.
}

Since exceptions already add some small overhead (mostly when fired), maybe we could also add hierarchy of exceptions representing some scenarios based on VkResult return value like

vk::error
    - vk::out_of_memory_error
        - vk::out_of_device_memory_error
        - vk::out_of_host_memory_error
    - vk::initialization_failed_error
    - vk::device_lost_error
    - ...

That way some errors might be handled right away and others might for example terminate application.
Worst case you could still catch them by std::exception or another STD-base-class.

I know that VULKAN_HPP_TYPESAFE_CONVERSION should enable this but I think there is a more elegant solution. Instead of disabling the conversion constructor, just make it explicit if VULKAN_HPP_TYPESAFE_CONVERSION is not defined. This prevents unwanted conversions but allows explicit construction. Otherwise I always have to define the macro to make the following example possible:

vk::SurfaceKHR f()
{
	VkSurfaceKHR surf_ {};
	auto const result {glfwCreateWindowSurface(inst, wnd, nullptr, &surf_)};
	return vk::SurfaceKHR {surf_};
}

It should always be possible to construct the nice vk::* objects from raw Vk* handles. This could stay implicit for 64-bit because it is type safe. It should not be mandatory to give up type safety in 32-bit by always defining the macro.

VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHX, VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHX VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHX

do not exist in v46 vulkan.h. They are already KHR. Therefore compiles fail. Changing lines such as

ePhysicalDeviceProperties2KHX = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHX,

to

ePhysicalDeviceProperties2KHR = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHR,

causes a different compile failure because ePhysicalDeviceProperties2KHR was already defined earlier in vulkan.hpp.

I had a similar problem last time I copied the "latest" vulkan.hpp from https://github.com/KhronosGroup/Vulkan-Hpp/blob/master/vulkan/vulkan.hpp. See issue #85. I think you have a process problem that needs fixing.

Here is a diff from the downloaded file to the fixed file

mark:~/Projects/github/KTX (vkloadtests) $ diff ~/Downloads/vulkan.hpp ~/Molten*16.3/MoltenVK/include/vulkan/vulkan.hpp
6140,6142d6139
<     ePhysicalDeviceProperties2KHX = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2_KHX,
<     eImageFormatProperties2KHX = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2_KHX,
<     ePhysicalDeviceImageFormatInfo2KHX = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2_KHX,
28601,28603d28597
<     case StructureType::ePhysicalDeviceProperties2KHX: return "PhysicalDeviceProperties2KHX";
<     case StructureType::eImageFormatProperties2KHX: return "ImageFormatProperties2KHX";
<     case StructureType::ePhysicalDeviceImageFormatInfo2KHX: return "PhysicalDeviceImageFormatInfo2KHX";

I find it very distrubing that we are forced to mix C-style code with C++, as vulkan.h defines many "objects" with #define. With Vulkan-HPP we can do better - maybe we could simply expose some of these objects as constexpr (when supported) variables/objects? This would purify our code from C-like macros and defines.

Note that Vulkan-HPP already depends on specific version of vulkan.h so there shouldn't be any compatibility reason to not provide such feature.

Some example variables/objects that we use commonly:

• VK_NULL_HANDLE
• VK_TRUE / VK_FALSE
• etc.

I'm not sure whether this is only a problem for me, but last time I used Vulkan-Hpp and tried to create a Debug Callback, I got a linker error(The library didn't know the function? Even if the function for creation is at runtime available!). If I'm missing anything, I'm very sorry, just trying to understand and help :) !

I had setup a basic project from this Vulkan tutorial and i've replaced
vulkan.h with vulkancpp.h( which is vulkan.hpp) and i get these numerous compiler errors:
Visual Studio 2015 Community, toolset v140.

1>d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(2598): error C2678: binary '==': no operator found which takes a left-hand operand of type 'const vk::Buffer' (or there is no acceptable conversion)
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(2598): note: could be 'built-in C++ operator==(VkBuffer, VkBuffer)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(2598): note: or       'built-in C++ operator==(VkBuffer, bool)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(2598): note: or       'built-in C++ operator==(bool, VkBuffer)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(2598): note: or       'built-in C++ operator==(bool, bool)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(2598): note: while trying to match the argument list '(const vk::Buffer, const vk::Buffer)'
1>d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(3776): error C2678: binary '==': no operator found which takes a left-hand operand of type 'const vk::DisplayKHR' (or there is no acceptable conversion)
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(3776): note: could be 'built-in C++ operator==(VkDisplayKHR, VkDisplayKHR)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(3776): note: or       'built-in C++ operator==(VkDisplayKHR, bool)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(3776): note: or       'built-in C++ operator==(bool, VkDisplayKHR)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(3776): note: or       'built-in C++ operator==(bool, bool)'
1>  d:\vulkansdk\1.0.21.1\include\vulkan\vulcancpp.h(3776): note: while trying to match the argument list '(const vk::DisplayKHR, const vk::DisplayKHR)'

The SamplerCreateInfo constructor sets anisotropyEnabled to false and sets maxAnistropy to 0. 1.0 seems a more reasonable value based on language in the Vulkan spec. that the value must be 1.0 when samplerAnisotropy is not enabled on the device.

The spec. is not clear on valid usage when samplerAnisotropy enabled but anisotropyEnabled is false. See KhronosGroup/Vulkan-Docs#503.

Many cmake projects will build their upstream dependencies if necessary by downloading either a binary or a source zip file, using the cmake ExternalProject_Add functionality. However, this library can't be used in this way because the downloaded ZIP file doesn't contain the git submodules required to build.

Instead of using a git submodule for the tinyxml dependency, you can use an ExternalProject_Add command of your own. Instead of using a submodule for the spec dependency, you can use a file(DOWNLOAD ...) command to fetch the spec XML. This also has the advantage of allowing the build process to target a specific version of the spec at cmake configuration time by passing a command line argument to override the default spec URL.

Hi,

The README states:

All functions, enums and structs have the Vk prefix removed. vkCreateImage can be accessed as vk::CreateImage

Some functions do not follow this naming convention with respect to leading uppercase letters, e.g. vk::enumerateInstanceLayerProperties() or vk::enumerateInstanceExtensionProperties() (there may be others). Either they should be re-named to follow the naming convention, or the README should be clarified.

Trying to build vulkan.hpp with the new 1.0.55 header caused several issues related to the expanded use of tags. Made several changes noted below to get us going but a better solution would be great.

C:\dev\xgl\Vulkan-Hpp>git diff
diff --git a/Vulkan-Docs b/Vulkan-Docs
index 1d67e47..c1d03fd 160000
--- a/Vulkan-Docs
+++ b/Vulkan-Docs
@@ -1 +1 @@
-Subproject commit 1d67e47f1464d5f5e654a405e9a91c7d5441bbb6
+Subproject commit c1d03fdd6f2fc46976b4778d3f590d99c7b26f11-dirty
diff --git a/VulkanHppGenerator.cpp b/VulkanHppGenerator.cpp
index 3eafc6c..6fd893f 100644
--- a/VulkanHppGenerator.cpp
+++ b/VulkanHppGenerator.cpp
@@ -1203,14 +1203,14 @@ std::string readArraySize(tinyxml2::XMLNode * node, std::string& name)
         assert(node && node->ToElement() && (strcmp(node->Value(), "enum") == 0));
         arraySize = node->ToElement()->GetText();
         node = node->NextSibling();
-        assert(node && node->ToText() && (strcmp(node->Value(), "]") == 0) && !node->NextSibling());
+        ////assert(node && node->ToText() && (strcmp(node->Value(), "]") == 0) && !node->NextSibling());
       }
       else
       {
         // otherwise, the node holds '[' and ']', so get the stuff in between those as the array size
         assert((value.front() == '[') && (value.back() == ']'));
         arraySize = value.substr(1, value.length() - 2);
-        assert(!node->NextSibling());
+        ////assert(!node->NextSibling());
       }
     }
   }
@@ -1827,6 +1827,7 @@ void readTypeStruct( tinyxml2::XMLElement * element, VkData & vkData, bool isUni
   {
     assert( child->Value() );
     std::string value = child->Value();
+    if (value.compare("comment") == 0) continue;
     assert(value == "member");
     readTypeStructMember( child, it->second.members, vkData.dependencies.back().dependencies );
   }
@@ -1864,6 +1865,7 @@ void readTypes(tinyxml2::XMLElement * element, VkData & vkData)
 {
   for (tinyxml2::XMLElement * child = element->FirstChildElement(); child; child = child->NextSiblingElement())
   {
+    if (strcmp(child->Value(), "comment") == 0) continue;
     assert( strcmp( child->Value(), "type" ) == 0 );
     std::string type = child->Value();
     assert( type == "type" );
@@ -4092,9 +4094,11 @@ int main( int argc, char **argv )
       }
       else if (value == "comment")
       {
-        // get the vulkan license header and skip any leading spaces
-        readComment(child, vkData.vulkanLicenseHeader);
-        vkData.vulkanLicenseHeader.erase(vkData.vulkanLicenseHeader.begin(), std::find_if(vkData.vulkanLicenseHeader.begin(), vkData.vulkanLicenseHeader.end(), [](char c) { return !std::isspace(c); }));
+          if (vkData.vulkanLicenseHeader.size() == 0) {
+              // get the vulkan license header and skip any leading spaces
+              readComment(child, vkData.vulkanLicenseHeader);
+              vkData.vulkanLicenseHeader.erase(vkData.vulkanLicenseHeader.begin(), std::find_if(vkData.vulkanLicenseHeader.begin(), vkData.vulkanLicenseHeader.end(), [](char c) { return !std::isspace(c); }));
+          }
       }
       else if (value == "enums")
       {

The latest vulkan.hpp, which is checking that vulkan.h is version 40, uses several VK_COLOR_SPACE*EXT enum values which are not in either v40 or v41 of vulkan.h available from https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/vulkan/vulkan.h. e.g. VK_COLOR_SPACE_DISPLAY_P3_LINEAR_EXT.

When I try to compile a Win32 program, using Visual Studio 2013, I get 37 compiler errors in vulkan.hpp, each complaining that there is no == operator for the given types. The errors look like:

1>c:\vulkansdk\1.0.21.2.ccvb.1300\include\vulkan\vulkan.hpp(2598): error C2678: binary '==' : no operator found which takes a left-hand operand of type 'const vk::Buffer' (or there is no acceptable conversion)
1> could be 'built-in C++ operator==(VkBuffer, VkBuffer)'
1> or 'built-in C++ operator==(VkBuffer, bool)'
1> or 'built-in C++ operator==(bool, VkBuffer)'
1> or 'built-in C++ operator==(bool, bool)'
1> while trying to match the argument list '(const vk::Buffer, const vk::Buffer)'

It looks like what's happening is that each error occurs in an overloaded equality operator, but the member variables to not have overloaded equality operators. Everything compiles just fine with VULKAN_HPP_TYPESAFE_CONVERSION because the compiler uses equality from the C Vulkan structs (i.e. VkBuffer instead of vk::Buffer), but when implicit conversion isn't allowed, that conversion must be explicit (and it's still implicit).

To fix the compiler errors, you would need to either explicitly convert the C++ objects to their C counterparts, or overload the equality operator for the C++ objects. Obviously, you can work around this issue by simply defining VULKAN_HPP_TYPESAFE_CONVERSION, but since the header simply refuses to compile without it (which is default for 32-bit), this is something that should probably get fixed.

This header version extends the debug report enum type with VK_DEBUG_REPORT_OBJECT_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_KHR_EXT -- this triggers the assert in the strip() function:

assert(strippedValue.substr(strippedValue.length() - postfix.length()) == postfix);

Basic C-style Vulkan (via vulkan.h) allows loading its functions in runtime via macro VK_NO_PROTOTYPES and mechanism like

library = LoadLibrary("vulkan-1");
some_vulkan_func = GetProcAddr(library, "some_vulkan_func");

Is it possible to use Vulkan-Hpp in the same manner or we can either load Vulkan dynamically or use Vulkan-Hpp?

Please, add support for RS600 series (ATI Radeon Xpress 1250)

Hi,
GSL is a library that provides some types aimed at type safety and improved ownership semantics. It has a gsl::span<> type which is a non owning view over contigus collection of object in memory like std::array, std::vector, or raw pointer. I think it does the same things as ArrayProxy does plus it's intended to be understood by static analysis Tools and it hides pointer arithmetics with the help of subspan() functions :
https://github.com/Microsoft/GSL
Given that GSL is a semi standard in C++ (the gsl::string_view class made it to C++17 drafts) it would be nice to have some overloads accepting gsl::span instead of ArrayProxy (maybe guarded behind an ifdef).

Regards,
Vincent

I wonder whether there're any API documentation or cheat sheet for vulkan.hpp? It might be easier to reference to or search from.

It would be great to see, if there was any hello triangle example using Vulkan-Hpp

This is more like a C++ question:

When not using DISABLE_ENHANCED mode, there are methods like vk::Instance::createDebugReportCallbackEXT using vkCreateDebugReportCallbackEXT. This fails on my system with an unresolved external symbol for vkCreateDebugReportCallbackEXT.

How do I load the extension (VK_EXT_debug_report is supported on my system) so I can still use the enhanced mode?

Building with the 1.0.40 header and vk.xml file from Vulkan-Docs results in undefined errors for VK_EXT_SMPTE2086_metadata extension members. This extension is tagged as 'disabled' in vk.xml but is picked up regardless, causing compilation failures.

After reading your blog entry "vulkan-c-bindings-reloaded" I noticed your section on RAII. But nothing in the RAII principle require ref counting at all. It is only required if you want to do a smart pointer style thing. A more natural fit would be a unique_ptr style deal.

For a example implementation take a look at

https://github.com/Unarmed1000/RapidVulkan

Tried Windows and Linux -- debug builds assert as follows while release builds hang.

C:\dev\xgl\Vulkan-Hpp\build\Debug>.\VulkanHppGenerator.exe .\vk.xml
Loading vk.xml from c:[blah]\vk.xml
Writing vulkan.hpp to C:\blah\Vulkan-Hpp\vulkan\vulkan.hpp
Assertion failed: stit != vkData.structs.end() && stit->second.protect.empty(), file C:\dev\xgl\Vulkan-Hpp\VulkanHppGenerator.cpp, line 1205

The line m_value = nullptr doesn't compile. Should be m_value = VK_NULL_HANDLE.

Defines like VULKAN_HPP_DISABLE_ENHANCED_MODE and VULKAN_HPP_NO_EXCEPTIONS make the generated file a lot bigger and more complex than it could be. I believe generator flags/options should be added to the generator to replace those. Such flags can be accessible via command-line arguments like --disable-enhanced-mode and --disable-exceptions.

The downside to this is that it would add complexity to some parts of the generator.

... in order to prevent premature or multiple destruction. For example:

void f(vk::UniqueDevice const& dev) {}

void g(vk::Device dev)
{
    f(dev); // oops
}

The enhanced-mode body for PhysicalDevice::getSurfaceCapabilities2KHR() appears to be incorrect and causes the following build errors:

1  VULKAN_HPP_INLINE Result PhysicalDevice::getSurfaceCapabilities2KHR( const PhysicalDeviceSurfaceInfo2KHR* pSurfaceInfo, SurfaceCapabilities2KHR* pSurfaceCapabilities ) const
2    {
3      return static_cast<Result>( vkGetPhysicalDeviceSurfaceCapabilities2KHR( m_physicalDevice, reinterpret_cast<const VkPhysicalDeviceSurfaceInfo2KHR*>( pSurfaceInfo ), reinterpret_cast<VkSurfaceCapabilities2KHR*>( pSurfaceCapabilities ) ) );
4    }
5  #ifndef VULKAN_HPP_DISABLE_ENHANCED_MODE
6    VULKAN_HPP_INLINE Result PhysicalDevice::getSurfaceCapabilities2KHR( const PhysicalDeviceSurfaceInfo2KHR & surfaceInfo ) const
7    {
8      Result result = static_cast<Result>( vkGetPhysicalDeviceSurfaceCapabilities2KHR( m_physicalDevice, reinterpret_cast<const VkPhysicalDeviceSurfaceInfo2KHR*>( &surfaceInfo ), reinterpret_cast<VkSurfaceCapabilities2KHR*>( &surfaceCapabilities ) ) );
9      return createResultValue( result, surfaceCapabilities, "vk::PhysicalDevice::getSurfaceCapabilities2KHR" );
10   }
11 #endif /*VULKAN_HPP_DISABLE_ENHANCED_MODE*/

Line 8: 'surfaceCapabilities': undeclared identifier
Line 9: 'surfaceCapabilities': undeclared identifier

The set methods for arrays is a bit ugly and cumbersome.

return vk::PipelineVertexInputStateCreateInfo()
	.setVertexBindingDescriptionCount(binding_descriptions.size())
	.setPVertexBindingDescriptions(binding_descriptions.data())
	.setVertexAttributeDescriptionCount(attribute_descriptions.size())
	.setPVertexAttributeDescriptions(attribute_descriptions.data());

Would be nicer to write something like:

return vk::PipelineVertexInputStateCreateInfo()
	.setVertexBindingDescriptions(binding_descriptions)
	.setVertexAttributeDescriptions(attribute_descriptions));

Or perhaps:

return vk::PipelineVertexInputStateCreateInfo()
	.setVertexBindingDescriptions(binding_descriptions.begin(), binding_descriptions.end())
	.setVertexAttributeDescriptions(attribute_descriptions.begin(), attribute_descriptions.end());

Or both?

The vulkan 1.0.28 spec changed the notiation used to refer to members of structs when they're referenced as an array length. Previously, the spec would notate this like pAllocateInfo->descriptorSetCount, but in 1.0.28 this is notated as pAllocateInfo::descriptorSetCount. As a result, when trying to generate vulkan.hpp with the 1.0.28 version of vk.xml, I get an assertion error. My guess is that you'll want to make this project handle both notations so that it works both before and after 1.0.28.

The following code doesn't work (it crashes):

vk::UniqueFence createSubmitFence(vk::Device dev)
{
	auto const create_info {vk::FenceCreateInfo {}
		.setFlags(vk::FenceCreateFlagBits::eSignaled)};
	return dev.createFenceUnique(create_info);
}

The problem is the temporary handle "dev" getting destroyed when the function returns. The Deleters should store the handle directly and not a pointer to it.

Due to current version missmatch of the vulkan.hpp and the latest vulkan.h I decided to rebuild it myself. Compilation of the VulkanHppGenerator.exe (im on Win10 VS2015) works fine, but executing it throws this message:

Loading vk.xml from D:\Repos - Kopie\Vulkan-Hpp\Vulkan-Docs\src\spec\vk.xml
Writing vulkan.hpp to D:\Repos - Kopie\Vulkan-Hpp\vulkan\vulkan.hpp
caught exception: spec error: enums name="ExternalMemoryHandleTypeFlagBitsNV" 
is missing the type attribute

Older versions work just fine. I already ran the integrity tests for the vk.xml and successfully compiled the vulkan.h generated from it. Any clue on where to start the bug hunt?

Pulled the 1.0.40 version of vulkan.hpp into Vulkan-LoaderAndValidationLayers and continuous integration began failing with scads of the following errors:

In file included from /home/travis/build/KhronosGroup/Vulkan-LoaderAndValidationLayers/demos/cube.cpp:37:
/home/travis/build/KhronosGroup/Vulkan-LoaderAndValidationLayers/include/vulkan/vulkan.hpp:1095:19: error: 
      unknown type name 'nullptr_t'; did you mean 'std::nullptr_t'?
    DeviceMemory( nullptr_t )
                  ^~~~~~~~~
                  std::nullptr_t
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8/bits/c++config.h:190:29: note: 
      'std::nullptr_t' declared here
  typedef decltype(nullptr)     nullptr_t;

                            ^

This happens when using functions which can receive VK_NULL_HANDLE as arguments, like the fence argument of vk::Queue::submit.
Due to the new constructors in SDK 1.0.42 taking std::nullptr_t as argument, g++6 reports an ambiguity error because VK_NULL_HANDLE can be the argument of both the c-struct- and the nullptr-constructor. This ambiguity makes it also impossible to initialize a wrapper class with the VK_NULL_HANDLE value.
Making the nullptr-constructor explicit solves this issue but I am not sure if this would violate any rules of the wrapping.

Vookoo:

https://github.com/andy-thomason/Vookoo

Is a collection of stateful helper classes for Vulkan-Hpp.

It makes constructing pipelines and renderpasses very easy as
the data structures are wrapped in a single class and have sensible
defaults.

I'm happy to contribute the insights we have gained from this to Vulkan-Hpp
if you are interested.

See my article

https://accu.org/index.php/journals/2380

I love how Vulkan-Hpp offers OOP patterns and compile time type checking for Vulkan constructs, and I'm wondering if there's any plans to bring that same style of header only library to OpenGL as an officially maintained library.

I know there's challenges involved like deciding what extension bindings to include for OpenGL, how far to take the abstraction, and there's a number of libraries like glad and OOGL that try solving this, but they either still opt for doing things in a C style or they don't pull from the specification to generate the library.

Here's a rough idea on how I would imagine it would look:

auto program = gl::Program();

auto vert = gl::Shader(gl::ShaderType::eVertex);
vert.source("#version 150\nin vec2 position; void main() { gl_Position = vec4(position, 0.0, 1.0); }");
vert.compile(); // Like Vulkan-Hpp, this would throw an exception if there was an error.

auto frag = gl::Shader(gl::ShaderType::eFrag);
frag.source("#version 150\nout vec4 outColor; void main() { outColor = vec4(1.0, 0.0, 0.0, 1.0); }");
frag.compile();

program.attach(vert);
program.attach(frag);
program.link();

Should the abstraction go further, like making every construct a RAII class? OOGL opted for not only making constructs RAII classes but also making constructors that make assumptions like:

// Shader is already compiled after construction.
GL::Shader vert(GL::ShaderType::Vertex, "#version 150\nin vec2 position; void main() { gl_Position = vec4(position, 0.0, 1.0); }");
GL::Shader frag(GL::ShaderType::Fragment, "#version 150\nout vec4 outColor; void main() { outColor = vec4(1.0, 0.0, 0.0, 1.0); }");
// Program is compiled after construction.
GL::Program program(vert, frag);

Questions

1. What would need to be done to make library like Vulkan-Hpp but for OpenGL?

2. How would it be able to get official Khronos support if that were the case?

Five instances of the warning occur when compiling vulkan.hpp here is the compiler output.

../external/Vulkan-Hpp/vulkan/vulkan.hpp:2633:62: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
    ClearColorValue( const std::array<float,4>& float32_ = { 0 } )
                                                             ^
                                                             {}
../external/Vulkan-Hpp/vulkan/vulkan.hpp:7166:105: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
    DebugMarkerMarkerInfoEXT( const char* pMarkerName_ = nullptr, std::array<float,4> const& color_ = { 0, 0, 0, 0 } )
                                                                                                        ^~~~~~~~~~
                                                                                                        {         }
../external/Vulkan-Hpp/vulkan/vulkan.hpp:8420:329: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
    PipelineColorBlendStateCreateInfo( PipelineColorBlendStateCreateFlags flags_ = PipelineColorBlendStateCreateFlags(), Bool32 logicOpEnable_ = 0, LogicOp logicOp_ = LogicOp::eClear, uint32_t attachmentCount_ = 0, const PipelineColorBlendAttachmentState* pAttachments_ = nullptr, std::array<float,4> const& blendConstants_ = { 0, 0, 0, 0 } )
                                                                                                                                                                                                                                                                                                                                        ^~~~~~~~~~
                                                                                                                                                                                                                                                                                                                                        {         }
../external/Vulkan-Hpp/vulkan/vulkan.hpp:9356:129: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
    ImageBlit( ImageSubresourceLayers srcSubresource_ = ImageSubresourceLayers(), std::array<Offset3D,2> const& srcOffsets_ = { Offset3D(), Offset3D() }, ImageSubresourceLayers dstSubresource_ = ImageSubresourceLayers(), std::array<Offset3D,2> const& dstOffsets_ = { Offset3D(), Offset3D() } )
                                                                                                                                ^~~~~~~~~~~~~~~~~~~~~~
                                                                                                                                {                     }
../external/Vulkan-Hpp/vulkan/vulkan.hpp:9356:268: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
    ImageBlit( ImageSubresourceLayers srcSubresource_ = ImageSubresourceLayers(), std::array<Offset3D,2> const& srcOffsets_ = { Offset3D(), Offset3D() }, ImageSubresourceLayers dstSubresource_ = ImageSubresourceLayers(), std::array<Offset3D,2> const& dstOffsets_ = { Offset3D(), Offset3D() } )
                                                                                                                                                                                                                                                                           ^~~~~~~~~~~~~~~~~~~~~~
                                                                                                                                                                                                                                                                           {                     }

I want to convert an existing program to use vulkan.hpp. As I am trying to do a little at a time, I want to pass the C++ structs & handles to Vk c functions.

vk::CommandBufferBeginInfo cmdBufInfo({}, nullptr);
vkBeginCommandBuffer(drawCmdBuffers[i], &cmdBufInfo);

produces the error

error: cannot convert ‘vk::CommandBufferBeginInfo*’ to ‘const VkCommandBufferBeginInfo*’

I suppose I am doing it wrong but I have tried just about everything I can think of and just keep getting various compile errors. The only thing that has worked is doing a reinterpret_cast myself.

vkBeginCommandBuffer(vkctx.drawCmdBuffers[i],
        	reinterpret_cast<const VkCommandBufferBeginInfo*>(&cmdBufInfo));

but since there is an operator in the class to do this, it shouldn't be necessary. What am I doing wrong?

Even the reinterpret_cast doesn't work if I create cmdBufInfo by

vk::CommandBufferBeginInfo cmdBufInfo();

In this case at the call to vkBeginCommandBuffer I get

undefined reference to `cmdBufInfo()'

Apparently it thinks cmdBufInfo is a function. This is confusing me too as the constructor has defaults for all its arguments.

I am using a 64-bit system, Ubuntu 16.10.

With code like this:

#define VULKAN_HPP_TYPESAFE_CONVERSION
#include <vulkan/vulkan.hpp>

I get a warning for multiple defined macros in 32-bit. Please check if the macro is already defined. Otherwise the correct code would not be pretty:

#if !defined(__LP64__) && !defined(_WIN64) && (!defined(__x86_64__) || defined(__ILP32__) ) && !defined(_M_X64) && !defined(__ia64) && !defined (_M_IA64) && !defined(__aarch64__) && !defined(__powerpc64__)
#define VULKAN_HPP_TYPESAFE_CONVERSION
#endif // #if !defined(__LP64__) && !defined(_WIN64) && (!defined(__x86_64__) || defined(__ILP32__) ) && !defined(_M_X64) && !defined(__ia64) && !defined (_M_IA64) && !defined(__aarch64__) && !defined(__powerpc64__)
#include <vulkan/vulkan.hpp>

After generation of vulkan.hpp and manually fixing issue #27, I get following error:

/home/pa/.../vulkan/vulkan.hpp: In constructor ‘vk::DebugReportLayerFlagsEXT::DebugReportLayerFlagsEXT(uint64_t)’:
/home/pa/.../vulkan/vulkan.hpp:8533:16: error: ‘eDebugReportLayerFlagsEXT’ is not a member of ‘vk::StructureType’
       : sType( StructureType::eDebugReportLayerFlagsEXT )
                ^~~~~~~~~~~~~

This happens due to writeStructConstructor in VulkanHppGenerator.cpp. It initializes sType member of 'structure types' to StructureType::e<name>. For VkDebugReportLayerFlagsEXT specification states:

Must be VK_STRUCTURE_TYPE_DEBUG_REPORT_VALIDATION_FLAGS_EXT

which corresponds to StructureType::eDebugReportValidationFlagsEXT.

With newer version of specification it is no longer the case: structures' names are changed and the writeStructConstructor logics doesn't fail (checked for 1.0.28).