Jump to page: 1 2
Thread overview
A ready to use Vulkan triangle example for D
May 27, 2016
maik klein
May 28, 2016
WhatMeWorry
May 28, 2016
maik klein
May 28, 2016
Alex Parrill
May 28, 2016
maik klein
May 29, 2016
Alex Parrill
May 29, 2016
maik klein
May 30, 2016
Alex Parrill
May 30, 2016
Manuel König
May 30, 2016
maik klein
Jun 01, 2016
Manuel König
May 27, 2016
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 28, 2016
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 28, 2016
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
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
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 29, 2016
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 29, 2016
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 30, 2016
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 30, 2016
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
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.
« First   ‹ Prev
1 2