Cmake update, getQueue crash fix, changes necessery to update to recent Vulkan-Hpp

See commit messages for details

Any feedback on the proposed changes by a chance?

Hi lhog. I should have just taken your changes verbatim. I'm having testing issues at the moment as my work computer is on Ubuntu 16.04 and CMake is 3.5.1 in this release. If you bear with me, I'll have a new version soon.

Hi Andy!

Great to hear vookoo is alive and getting updates!

FindVulkan is indeed only available natively on CMake 3.7.x. Perhaps I can port it over just as a file from here: https://github.com/Kitware/CMake/blob/master/Modules/FindVulkan.cmake , so it's available for older versions of CMake. Though it only makes sense if you as a lib maintainer approve such approach, that Vulkan headers should be searched in LunarG SDK folder, rather than supplied along with vookoo.

I'm only starting to learn vulkan, so if you can pardon my ignorance, I'd like to clarify a few questions:

vku_framework seems to lack flexibility a little bit. For during the framework initialization, one cannot specify if they want validations layers or how many queues and of what type they would like to instance... etc. With that I was wondering if it's reasonable that vku_framework get some flexibility or is it here just to outline how vku can be used in principle?
This one is really embarrassing for me to ask (see my ignorance reference), but can you describe in a few words how do levels of "wrapping"/simplification compare between vookoo and AMD's https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ ? They seem to have removed/alleviated the most tedious parts of vulkan initialization (see two pics they posted on the front page). Generally what will be the direction of vookoo development? Do you plan to catch-up with V-EZ in terms of simplification (if there is anything to catch-up to)?

Very pleased you are interested. I had begun working on a book and needed to brush Vookoo up a little as part of the pitch.

The FindVulkan is a good idea and solves some of the problems that I solved by including the files. The problems mostly occur on Windows, but on my Linux system it is trivial to install Vulkan and GLM. The only problem is that some people are running on systems they can't upgrade, so latest CMake may not be available to them.

I did think about making the framework a little more flexible, but as it was intended only for the examples, I wanted to keep it simple.

What we could do is split the initialisation into helper functions so that you could do all the initialisation with about 20 lines of code with sensible defaults, keeping the same "default + extras as calls" format. For example, we could have an "vku::InstanceMaker" class.

The V-EZ is interesting, I've only just seen it. I guess they didn't know about Vookoo when they started. V-EZ (which doesn't work as an acronym in UK english!) is essentially a wrapper to avoid using data structures. The C++ API (vulkan.hpp) does almost all of this and more and only lacks independent documentation. I used the C++ API as a starting point as my attempts to do something similar were not as successful.

On Wed, Dec 12, 2018 at 11:21 AM lhog notifications@github.com wrote:

Hi Andy!

Great to hear vookoo is alive and getting updates!

FindVulkan is indeed only available natively on CMake 3.7.x. Perhaps I can port it over just as a file from here: https://github.com/Kitware/CMake/blob/master/Modules/FindVulkan.cmake , so it's available for older versions of CMake. Though it only makes sense if you as a lib maintainer approve such approach, that Vulkan headers should be searched in LunarG SDK folder, rather than supplied along with vookoo.

I'm only starting to learn vulkan, so if you can pardon my ignorance, I'd like to clarify a few questions:

vku_framework seems to lack flexibility a little bit. For during the framework initialization, one cannot specify if they want validations layers or how many queues and of what type they would like to instance... etc. With that I was wondering if it's reasonable that vku_framework get some flexibility or is it here just to outline how vku can be used in principle?

This one is really embarrassing for me to ask (see my ignorance reference), but can you describe in a few words how do levels of "wrapping"/simplification compare between vookoo and AMD's https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ ? They seem to have removed/alleviated the most tedious parts of vulkan initialization (see two pics they posted on the front page). Generally what will be the direction of vookoo development? Do you plan to catch-up with V-EZ in terms of simplification (if there is anything to catch-up to)?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/pull/10#issuecomment-446553549, or mute the thread https://github.com/notifications/unsubscribe-auth/ABe_XMfLJjEP4DdndX0liEYXYGObtuZjks5u4ObUgaJpZM4Yx46f .

Very pleased you are interested.

I'm actually very interested indeed. From the first sight vookoo is made just right:

It's based on vulkan.hpp, which is supposed to be maintained by Khronos, so it won't wither and die as many other Vulkan wrappers have or might have
It has minimal dependencies. Many other wrappers tend to include every good lib they can find into the framework. If one wants to use such wrappers, it's almost impossible to do easily in case your library stack is different. For the sake of argument you might use something other than GLM or GLFW.
It seems to take care of most explicit and tedious parts of Vulkan.

I had begun working on a book

Not sure what book you mean here? Is it Vulkan related?

The FindVulkan is a good idea and solves some of the problems that I solved by including the files. The problems mostly occur on Windows, but on my Linux system it is trivial to install Vulkan and GLM. The only problem is that some people are running on systems they can't upgrade, so latest CMake may not be available to them.

I'll have a look into this.

What we could do is split the initialisation into helper functions so that you could do all the initialisation with about 20 lines of code with sensible defaults, keeping the same "default + extras as calls" format. For example, we could have an "vku::InstanceMaker" class.

Yep I tried something similar. C++ is not really a language I know or use a lot, so I ended up with something like this here: https://github.com/lhog/Vookoo/blob/test/include/vku/vku_framework.hpp#L55-L107 https://github.com/lhog/Vookoo/blob/test/examples/helloTriangle/helloTriangle.cpp#L34-L36

V-EZ (which doesn't work as an acronym in UK english!) is essentially a wrapper to avoid using data structures.

They not only wrap the data into structures (vulkan.hpp does that a lot better I think), but they also managed to abstract away a lot of things. I'll quote from their doc site https://gpuopen-librariesandsdks.github.io/V-EZ/:

1.2. What is Abstracted From Vulkan?

The following is a short list of low level Vulkan API features and responsibilities which are abstracted in V-EZ and no longer a concern of the application.
    Memory management
    Swapchain management
    Render Passes
    Pipeline permutations
    Pipeline layouts
    Pipeline barriers
    Descriptor pools
    Descriptor sets
    Descriptor set layouts
    Image layouts
    GLSL compilation

One good thing about V-EZ is that it's well documented. The bad thing is that it's a vendor project, which they suddenly made Open Source. I personally don't buy that it's a reliable lib to put bets on:

The code hasn't seen any updates since October (Is it bug free? Is everything done perfectly?)
AMD also released https://github.com/GPUOpen-LibrariesAndSDKs/Anvil earlier. How did it happen that they have two wrapper frameworks that don't share anything?

P.S.

which doesn't work as an acronym in UK english!

You refer to this? https://www.urbandictionary.com/define.php?term=VEZ LOL then.

I'm going to improve the documentation and provide and example for each function if possible.

I'll try to communicate with the Vulkan_cpp people and get their interface documented as if it is its own thing...

It may be that AMD don't want to support Vulkan_cpp as it is an Nvidia thing.

Andy.

On Wed, Dec 12, 2018 at 2:07 PM lhog notifications@github.com wrote:

Very pleased you are interested.

I'm actually very interested indeed. From the first sight vookoo is made just right:

It's based on vulkan.hpp, which is supposed to be maintained by Khronos, so it won't wither and die as many other Vulkan wrappers have or might have

It has minimal dependencies. Many other wrappers tend to include every good lib they can find into the framework. If one wants to use such wrappers, it's almost impossible to do easily in case your library stack is different. For the sake of argument you might use something other than GLM or GLFW.

It seems to take care of most explicit and tedious parts of Vulkan.

I had begun working on a book

Not sure what book you mean here? Is it Vulkan related?

The FindVulkan is a good idea and solves some of the problems that I solved by including the files. The problems mostly occur on Windows, but on my Linux system it is trivial to install Vulkan and GLM. The only problem is that some people are running on systems they can't upgrade, so latest CMake may not be available to them.

I'll have a look into this.

What we could do is split the initialisation into helper functions so that you could do all the initialisation with about 20 lines of code with sensible defaults, keeping the same "default + extras as calls" format. For example, we could have an "vku::InstanceMaker" class.

Yep I tried something similar. C++ is not really a language I know or use a lot, so I ended up with something like this here: https://github.com/lhog/Vookoo/blob/test/include/vku/vku_framework.hpp#L55-L107 https://github.com/lhog/Vookoo/blob/test/examples/helloTriangle/helloTriangle.cpp#L34-L36

V-EZ (which doesn't work as an acronym in UK english!) is essentially a wrapper to avoid using data structures.

They not only wrap the data into structures (vulkan.hpp does that a lot better I think), but they also managed to abstract away a lot of things. I'll quote from their doc site https://gpuopen-librariesandsdks.github.io/V-EZ/:

1.2. What is Abstracted From Vulkan?

The following is a short list of low level Vulkan API features and responsibilities which are abstracted in V-EZ and no longer a concern of the application. Memory management Swapchain management Render Passes Pipeline permutations Pipeline layouts Pipeline barriers Descriptor pools Descriptor sets Descriptor set layouts Image layouts GLSL compilation

One good thing about V-EZ is that it's well documented. The bad thing is that it's a vendor project, which they suddenly made Open Source. I personally don't buy that it's a reliable lib to put bets on:

The code hasn't seen any updates since October (Is it bug free? Is everything done perfectly?)

AMD also released https://github.com/GPUOpen-LibrariesAndSDKs/Anvil earlier. How did it happen that they have two wrapper frameworks that don't share anything?

P.S.

which doesn't work as an acronym in UK english!

You refer to this? https://www.urbandictionary.com/define.php?term=VEZ LOL then.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/pull/10#issuecomment-446599676, or mute the thread https://github.com/notifications/unsubscribe-auth/ABe_XPDxcAhZnUCnewiIQzVVT2_agB7Qks5u4Q2_gaJpZM4Yx46f .

I like the framework options idea.

If you want to see a larger Vookoo project, I have:

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

On Wed, Dec 12, 2018 at 2:17 PM Andy Thomason andy@andythomason.com wrote:

I'm going to improve the documentation and provide and example for each function if possible.

I'll try to communicate with the Vulkan_cpp people and get their interface documented as if it is its own thing...

It may be that AMD don't want to support Vulkan_cpp as it is an Nvidia thing.

Andy.

On Wed, Dec 12, 2018 at 2:07 PM lhog notifications@github.com wrote:

Very pleased you are interested.

I'm actually very interested indeed. From the first sight vookoo is made just right:

It's based on vulkan.hpp, which is supposed to be maintained by Khronos, so it won't wither and die as many other Vulkan wrappers have or might have

It has minimal dependencies. Many other wrappers tend to include every good lib they can find into the framework. If one wants to use such wrappers, it's almost impossible to do easily in case your library stack is different. For the sake of argument you might use something other than GLM or GLFW.

It seems to take care of most explicit and tedious parts of Vulkan.

I had begun working on a book

Not sure what book you mean here? Is it Vulkan related?

The FindVulkan is a good idea and solves some of the problems that I solved by including the files. The problems mostly occur on Windows, but on my Linux system it is trivial to install Vulkan and GLM. The only problem is that some people are running on systems they can't upgrade, so latest CMake may not be available to them.

I'll have a look into this.

What we could do is split the initialisation into helper functions so that you could do all the initialisation with about 20 lines of code with sensible defaults, keeping the same "default + extras as calls" format. For example, we could have an "vku::InstanceMaker" class.

Yep I tried something similar. C++ is not really a language I know or use a lot, so I ended up with something like this here: https://github.com/lhog/Vookoo/blob/test/include/vku/vku_framework.hpp#L55-L107 https://github.com/lhog/Vookoo/blob/test/examples/helloTriangle/helloTriangle.cpp#L34-L36

V-EZ (which doesn't work as an acronym in UK english!) is essentially a wrapper to avoid using data structures.

They not only wrap the data into structures (vulkan.hpp does that a lot better I think), but they also managed to abstract away a lot of things. I'll quote from their doc site https://gpuopen-librariesandsdks.github.io/V-EZ/:

1.2. What is Abstracted From Vulkan?

The following is a short list of low level Vulkan API features and responsibilities which are abstracted in V-EZ and no longer a concern of the application. Memory management Swapchain management Render Passes Pipeline permutations Pipeline layouts Pipeline barriers Descriptor pools Descriptor sets Descriptor set layouts Image layouts GLSL compilation

One good thing about V-EZ is that it's well documented. The bad thing is that it's a vendor project, which they suddenly made Open Source. I personally don't buy that it's a reliable lib to put bets on:

The code hasn't seen any updates since October (Is it bug free? Is everything done perfectly?)

AMD also released https://github.com/GPUOpen-LibrariesAndSDKs/Anvil earlier. How did it happen that they have two wrapper frameworks that don't share anything?

P.S.

which doesn't work as an acronym in UK english!

You refer to this? https://www.urbandictionary.com/define.php?term=VEZ LOL then.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/pull/10#issuecomment-446599676, or mute the thread https://github.com/notifications/unsubscribe-auth/ABe_XPDxcAhZnUCnewiIQzVVT2_agB7Qks5u4Q2_gaJpZM4Yx46f .

Moovoo looks impressive, I'll have a look.

As far as V-EZ abstractions/wrappers compared to vookoo, can you point out which ones are done or not:

Memory management
Swapchain management
Render Passes
Pipeline permutations
Pipeline layouts
Pipeline barriers
Descriptor pools
Descriptor sets
Descriptor set layouts
Image layouts
GLSL compilation

From my side I'll certainly have a look at dealing with CMake and findVulkan. Also I might look into FW options (like it's outlined in the examples I sent), if you don't mind.

Sure. Have a go.

On Wed, 12 Dec 2018 18:42 lhog <notifications@github.com wrote:

Moovoo looks impressive, I'll have a look.

As far as V-EZ abstractions/wrappers compared to vookoo, can you point out which ones are done or not:

Memory management

Swapchain management

Render Passes

Pipeline permutations

Pipeline layouts

Pipeline barriers

Descriptor pools

Descriptor sets

Descriptor set layouts

Image layouts

GLSL compilation

From my side I'll certainly have a look at dealing with CMake and findVulkan. Also I might look into FW options (like it's outlined in the examples I sent), if you don't mind.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/pull/10#issuecomment-446697372, or mute the thread https://github.com/notifications/unsubscribe-auth/ABe_XJppW3F6LMaEIS5N_tSzrBVK0v-Eks5u4U4agaJpZM4Yx46f .

I've done all the above. Could do with an option to generate layouts from shaders.

On Thu, 13 Dec 2018 20:26 Andy Thomason <andy@andythomason.com wrote:

Sure. Have a go.

On Wed, 12 Dec 2018 18:42 lhog <notifications@github.com wrote:

Moovoo looks impressive, I'll have a look.

As far as V-EZ abstractions/wrappers compared to vookoo, can you point out which ones are done or not:

Memory management

Swapchain management

Render Passes

Pipeline permutations

Pipeline layouts

Pipeline barriers

Descriptor pools

Descriptor sets

Descriptor set layouts

Image layouts

GLSL compilation

From my side I'll certainly have a look at dealing with CMake and findVulkan. Also I might look into FW options (like it's outlined in the examples I sent), if you don't mind.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/pull/10#issuecomment-446697372, or mute the thread https://github.com/notifications/unsubscribe-auth/ABe_XJppW3F6LMaEIS5N_tSzrBVK0v-Eks5u4U4agaJpZM4Yx46f .

andy-thomason / Vookoo

Cmake update, getQueue crash fix, changes necessery to update to recent Vulkan-Hpp #10