www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - A ready to use Vulkan triangle example for D

reply maik klein <maikklein googlemail.com> writes:
https://github.com/MaikKlein/VulkanTriangleD

Currently only Linux is supported but it should be fairly easy to 
also add Windows support. Only the surface extensions have to be 
changed.

The example requires Vulkan ready hardware + driver + LunarG sdk 
with validation layer + sdl2.

Another dependency is ErupteD which I have forked myself because 
there is currently an issue with xlib-d and xcb-d with their 
versioning.

The example is also not currently completely 100% correct but it 
should run on most hardware.

I don't get any validation errors but I am sure I have made a few 
mistakes along the way.

It took me around 15 hours to get to a working triangle and I 
hope this might help someone who is interested in Vulkan.
May 27 2016
next sibling parent reply WhatMeWorry <kheaser gmail.com> writes:
On Friday, 27 May 2016 at 18:40:24 UTC, maik klein wrote:
 https://github.com/MaikKlein/VulkanTriangleD
 Another dependency is ErupteD which I have forked myself 
 because there is currently an issue with xlib-d and xcb-d with 
 their versioning.
Nice work. As a person still trying to understand modern OpenGL, I admire your jump into Vulkan. Just a quick question if I may; Why did you use ErupteD over say d-vulkan or derelict-vulcan? From my brief perusal of all three, they all seem kind of the same. Thanks.
May 27 2016
parent reply maik klein <maikklein googlemail.com> writes:
On Saturday, 28 May 2016 at 03:02:23 UTC, WhatMeWorry wrote:
 On Friday, 27 May 2016 at 18:40:24 UTC, maik klein wrote:
 https://github.com/MaikKlein/VulkanTriangleD
 Another dependency is ErupteD which I have forked myself 
 because there is currently an issue with xlib-d and xcb-d with 
 their versioning.
Nice work. As a person still trying to understand modern OpenGL, I admire your jump into Vulkan. Just a quick question if I may; Why did you use ErupteD over say d-vulkan or derelict-vulcan? From my brief perusal of all three, they all seem kind of the same. Thanks.
derelict-vulcan only works on windows, dvulkan doesn't have the platform dependend surface extensions for xlib, xcb, w32 and wayland. Without them Vulkan is unusable for me. I really don't care what I use, I just wanted something that works.
May 28 2016
parent reply Alex Parrill <initrd.gz gmail.com> writes:
On Saturday, 28 May 2016 at 10:58:05 UTC, maik klein wrote:
 derelict-vulcan only works on windows, dvulkan doesn't have the 
 platform dependend surface extensions for xlib, xcb, w32 and 
 wayland. Without them Vulkan is unusable for me.

 I really don't care what I use, I just wanted something that 
 works.
Platform extension support will be in the next release of d-vulkan. It doesn't include platform extensions now because I wanted to find a way to implement it without tying d-vulkan to a specific set of bindings, though I can't seem to find a good solution unfortunately... I personally use the git version of GLFW, which handles the platform-dependent surface handling for me. As for the demo itself... It might help explain things more if the separate stages (instance creation, device creation, setting up shaders, etc) were split into their own functions, instead of stuffing everything into `main`. Struct initializers are also useful when dealing with Vulkan info structs, since you don't have to repeat the variable name each time. Ex this: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = {}; vertexInputStateCreateInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO; vertexInputStateCreateInfo.vertexBindingDescriptionCount = 1; vertexInputStateCreateInfo.pVertexBindingDescriptions = &vertexBindingDescription; vertexInputStateCreateInfo.vertexAttributeDescriptionCount = 1; vertexInputStateCreateInfo.pVertexAttributeDescriptions = &vertexAttributeDescritpion; Can become: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = { sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO, // also sType is pre-set with erupted or d-derelict vertexBindingDescriptionCount = 1, pVertexBindingDescriptions = &vertexBindingDescription, vertexAttributeDescriptionCount = 1, pVertexAttributeDescriptions = &vertexAttributeDescritpion, };
May 28 2016
parent reply maik klein <maikklein googlemail.com> writes:
On Saturday, 28 May 2016 at 17:50:30 UTC, Alex Parrill wrote:
 On Saturday, 28 May 2016 at 10:58:05 UTC, maik klein wrote:
 derelict-vulcan only works on windows, dvulkan doesn't have 
 the platform dependend surface extensions for xlib, xcb, w32 
 and wayland. Without them Vulkan is unusable for me.

 I really don't care what I use, I just wanted something that 
 works.
Platform extension support will be in the next release of d-vulkan. It doesn't include platform extensions now because I wanted to find a way to implement it without tying d-vulkan to a specific set of bindings, though I can't seem to find a good solution unfortunately... I personally use the git version of GLFW, which handles the platform-dependent surface handling for me. As for the demo itself... It might help explain things more if the separate stages (instance creation, device creation, setting up shaders, etc) were split into their own functions, instead of stuffing everything into `main`. Struct initializers are also useful when dealing with Vulkan info structs, since you don't have to repeat the variable name each time. Ex this: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = {}; vertexInputStateCreateInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO; vertexInputStateCreateInfo.vertexBindingDescriptionCount = 1; vertexInputStateCreateInfo.pVertexBindingDescriptions = &vertexBindingDescription; vertexInputStateCreateInfo.vertexAttributeDescriptionCount = 1; vertexInputStateCreateInfo.pVertexAttributeDescriptions = &vertexAttributeDescritpion; Can become: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = { sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO, // also sType is pre-set with erupted or d-derelict vertexBindingDescriptionCount = 1, pVertexBindingDescriptions = &vertexBindingDescription, vertexAttributeDescriptionCount = 1, pVertexAttributeDescriptions = &vertexAttributeDescritpion, };
I think its personal preference, I like tutorials more if everything I just in the main instead of creating their own "architecture". Though I could probably group with comments. I saw that sType was a default value after a few hours and that is when I started using it. But at the end I was so annoyed by typing all the enums by hand that I mostly copied stuff from other people and translated it to D. This was mostly caused by my current vim D setup with vim-dutyl and dcd, it is really unreliable and I didn't get any sane autocompletion. (I have to investigate that at some point). Btw does this even work? I think the struct initializers have to be Foo foo = { someVar: 1 }; `:` instead of a `=` I didn't do this because I actually got autocompletion for `vertexInputStateCreateInfo.` and that meant less typing for me.
May 28 2016
parent reply Alex Parrill <initrd.gz gmail.com> writes:
On Saturday, 28 May 2016 at 19:32:58 UTC, maik klein wrote:
 Btw does this even work? I think the struct initializers have 
 to be

 Foo foo = { someVar: 1 };

 `:` instead of a `=`

 I didn't do this because I actually got autocompletion for  
 `vertexInputStateCreateInfo.` and that meant less typing for me.
No, its equals. In C it's a colon, which is a tad confusing.
May 28 2016
parent reply maik klein <maikklein googlemail.com> writes:
On Sunday, 29 May 2016 at 00:37:54 UTC, Alex Parrill wrote:
 On Saturday, 28 May 2016 at 19:32:58 UTC, maik klein wrote:
 Btw does this even work? I think the struct initializers have 
 to be

 Foo foo = { someVar: 1 };

 `:` instead of a `=`

 I didn't do this because I actually got autocompletion for  
 `vertexInputStateCreateInfo.` and that meant less typing for 
 me.
No, its equals. In C it's a colon, which is a tad confusing.
https://dpaste.dzfl.pl/bd29c970050a
May 28 2016
parent Alex Parrill <initrd.gz gmail.com> writes:
On Sunday, 29 May 2016 at 00:42:56 UTC, maik klein wrote:
 On Sunday, 29 May 2016 at 00:37:54 UTC, Alex Parrill wrote:
 On Saturday, 28 May 2016 at 19:32:58 UTC, maik klein wrote:
 Btw does this even work? I think the struct initializers have 
 to be

 Foo foo = { someVar: 1 };

 `:` instead of a `=`

 I didn't do this because I actually got autocompletion for  
 `vertexInputStateCreateInfo.` and that meant less typing for 
 me.
No, its equals. In C it's a colon, which is a tad confusing.
https://dpaste.dzfl.pl/bd29c970050a
Gah, I got them backwards. Colon in D, equals in C. Could have sworn I checked before I posted that...
May 29 2016
prev sibling next sibling parent reply Manuel =?UTF-8?B?S8O2bmln?= <manuelk89 gmx.net> writes:
On Fri, 27 May 2016 18:40:24 +0000, maik klein wrote:

 https://github.com/MaikKlein/VulkanTriangleD
 
 Currently only Linux is supported but it should be fairly easy to 
 also add Windows support. Only the surface extensions have to be 
 changed.
 
 The example requires Vulkan ready hardware + driver + LunarG sdk 
 with validation layer + sdl2.
Nice, runs without errors for me. I have a triangle example project too, but weird stuff happens when I resize my window. I see your window has fixed size, maybe I have more luck adding window resizing to your example. Will tell you when I get it to work. Does anyone here have a working vulkan window with a resizable window? I think its more of an xcb issue than a vulkan issue in my code, because even when I do - create xcb window with dimensions (w1, h1) - resize it to dimensions (w2, h2) (no vulkan interaction yet) - create a vulkan surface from that window - render the rendered image still has the original size (w1, h1), and I loose my vulkan device when (w2, h2) deviates too much from the original size.
May 30 2016
parent maik klein <maikklein googlemail.com> writes:
On Monday, 30 May 2016 at 11:30:24 UTC, Manuel K├Ânig wrote:
 On Fri, 27 May 2016 18:40:24 +0000, maik klein wrote:

 [...]
Nice, runs without errors for me. I have a triangle example project too, but weird stuff happens when I resize my window. I see your window has fixed size, maybe I have more luck adding window resizing to your example. Will tell you when I get it to work. Does anyone here have a working vulkan window with a resizable window? I think its more of an xcb issue than a vulkan issue in my code, because even when I do - create xcb window with dimensions (w1, h1) - resize it to dimensions (w2, h2) (no vulkan interaction yet) - create a vulkan surface from that window - render the rendered image still has the original size (w1, h1), and I loose my vulkan device when (w2, h2) deviates too much from the original size.
You probably have to update a lot of code https://github.com/MaikKlein/VulkanTriangleD/blob/master/source/app.d Do a ctrl+f vkcontext.width and you will see all the code that needs to be updated.
May 30 2016
prev sibling parent Manuel =?UTF-8?B?S8O2bmln?= <manuelk89 gmx.net> writes:
I now have initial window resizing added to your example:

https://github.com/Manuel-Koenig/VulkanTriangleD

It's still pretty much your code, but I structured it into several
functions. Window resizing does work in the sense that the triangle
gets stretched and redrawn, but the validation layer is still
complaining.
Jun 01 2016