Re: having troubles with D and Vulkan.

[Mike Shah via Digitalmars-d-learn]

On Friday, 21 July 2023 at 02:22:56 UTC, harakim wrote:

On Thursday, 20 July 2023 at 06:27:13 UTC, Danni Coy wrote:
ok found it, I am an idiot, (really not used to working with 
dynamic libraries).


erupted needs a call to load device level functions.

loadDeviceLevelFunctions(instance);

On Thu, Jul 20, 2023 at 4:22 PM Danni Coy 
 wrote:


https://pastebin.com/Jc9ZaFFs
Redid the code as an almost exact translation of the C code.
should be easier to test and compare. Same issue is occurring.

On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via 
Digitalmars-d-learn  wrote:

> [...]


Good work! Now I can rest in peace tonight. :D


Same for me :) Great to see folks working in Vulkan with D.

Re: having troubles with D and Vulkan.

[harakim via Digitalmars-d-learn]

On Thursday, 20 July 2023 at 06:27:13 UTC, Danni Coy wrote:
ok found it, I am an idiot, (really not used to working with 
dynamic libraries).


erupted needs a call to load device level functions.

loadDeviceLevelFunctions(instance);

On Thu, Jul 20, 2023 at 4:22 PM Danni Coy  
wrote:


https://pastebin.com/Jc9ZaFFs
Redid the code as an almost exact translation of the C code.
should be easier to test and compare. Same issue is occurring.

On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via 
Digitalmars-d-learn  wrote:

>
> On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
> > https://pastebin.com/JxxJufNB
>
> What platform are you using, and how are you trying to build?
>
> I can try to replicate on my end.


Good work! Now I can rest in peace tonight. :D

Re: having troubles with D and Vulkan.

[Danni Coy via Digitalmars-d-learn]

ok found it, I am an idiot, (really not used to working with dynamic libraries).

erupted needs a call to load device level functions.

loadDeviceLevelFunctions(instance);

On Thu, Jul 20, 2023 at 4:22 PM Danni Coy  wrote:
>
> https://pastebin.com/Jc9ZaFFs
> Redid the code as an almost exact translation of the C code.
> should be easier to test and compare. Same issue is occurring.
>
> On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn
>  wrote:
> >
> > On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
> > > https://pastebin.com/JxxJufNB
> >
> > What platform are you using, and how are you trying to build?
> >
> > I can try to replicate on my end.

Re: having troubles with D and Vulkan.

[Danni Coy via Digitalmars-d-learn]

https://pastebin.com/Jc9ZaFFs
Redid the code as an almost exact translation of the C code.
should be easier to test and compare. Same issue is occurring.

On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn
 wrote:
>
> On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
> > https://pastebin.com/JxxJufNB
>
> What platform are you using, and how are you trying to build?
>
> I can try to replicate on my end.

Re: having troubles with D and Vulkan.

[Danni Coy via Digitalmars-d-learn]

On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn
 wrote:
>
> On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:
> > https://pastebin.com/JxxJufNB
>
> What platform are you using, and how are you trying to build?
>
> I can try to replicate on my end.

I am on Manjaro Linux with an AMD RX 6600 using the open source driver.
I am building with visual studio code and dub.
I get segfaults when building with dmd or ldc.

The following C code https://pastebin.com/2XJbjzMw
does not cause a segfault on the same system.

Other code you will need to build
https://pastebin.com/hx2GD1DL

Build settings (from dub.json)
{
"dependencies": {
"bindbc-opengl": "~>1.0",
"bindbc-sdl": "~>1.0",
"erupted": "~>2.1.98+v1.3.248"
},
"versions": [
"SDL_206",
"GL_32",
"validateVulkan"
],
"name": "subterrainian"
}

Re: having troubles with D and Vulkan.

[Mike Shah via Digitalmars-d-learn]

On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote:

https://pastebin.com/JxxJufNB


What platform are you using, and how are you trying to build?

I can try to replicate on my end.

Re: having troubles with D and Vulkan.

[Danni Coy via Digitalmars-d-learn]

https://pastebin.com/JxxJufNB

Re: having troubles with D and Vulkan.

[Danni Coy via Digitalmars-d-learn]

>
> I was able to get through the triangle demo a while back. I feel
> like it's more of a D question than a Vulkan library question.
> You'll have to post your code so people can tell what it is. Just
> a hunch, but it's probably something that the gc is collecting
> before it is used.

What's the best way to post code?

I am mostly not using the GC, using std.experimental.allocator
specifically mallocator to allocate other than using
std.exception.enforce.

Re: having troubles with D and Vulkan.

[harakim via Digitalmars-d-learn]

On Wednesday, 19 July 2023 at 02:50:05 UTC, Danni Coy wrote:
I am trying to run through the basic Vulkan triangle demo. I am 
getting stuck at

vkGetDeviceQueue which segfaults for me.
I have written the same tutorial to about the same point in C 
and I am

not getting the segfault.
I have enabled validation layers and they are not picking up 
anything.


Any suggestions?


I was able to get through the triangle demo a while back. I feel 
like it's more of a D question than a Vulkan library question. 
You'll have to post your code so people can tell what it is. Just 
a hunch, but it's probably something that the gc is collecting 
before it is used.

having troubles with D and Vulkan.

[Danni Coy via Digitalmars-d-learn]

I am trying to run through the basic Vulkan triangle demo. I am getting stuck at
vkGetDeviceQueue which segfaults for me.
I have written the same tutorial to about the same point in C and I am
not getting the segfault.
I have enabled validation layers and they are not picking up anything.

Any suggestions?
module vulkan;

import std.exception : enforce;

import erupted;
import bindbc.sdl : SDL_Window, SDL_Vulkan_GetInstanceExtensions, SDL_Vulkan_CreateSurface;

import memory;
import util: CStringList;

version (validateVulkan) 
{ 
string [] validationLayers = ["VK_LAYER_KHRONOS_validation"];
const(char)[] debugExtension = "VK_EXT_debug_utils";
} else {
string [] validationLayers = [];
}  



CStringList getInstanceExtensions (SDL_Window * window)
{
uint n;
SDL_Vulkan_GetInstanceExtensions(window,,null);
version (validateVulkan)
{
auto extensions = CStringList(n+1);
SDL_Vulkan_GetInstanceExtensions(window,,extensions.ptr);
extensions[n] = cast(const(char)*) debugExtension.ptr;
} else {
auto extensions = CStringList(n);
SDL_Vulkan_GetInstanceExtensions(window,,extensions.ptr);
}

return extensions;
}

void createInstance (CStringList extensions)
{
auto vlayers = CStringList(validationLayers); 
VkApplicationInfo appInfo = 
{
    pApplicationName: "Vulkan Test",
apiVersion: VK_MAKE_API_VERSION(0,1,3,0),
};
VkInstanceCreateInfo createInfo = 
{
pApplicationInfo: ,
enabledLayerCount: cast(uint) vlayers.length,
ppEnabledLayerNames: vlayers.ptr,
enabledExtensionCount: cast(uint) extensions.length,
ppEnabledExtensionNames: extensions.ptr,
};
auto r = vkCreateInstance(, null, );
enforce(r == VK_SUCCESS,"failed to create instance");
loadInstanceLevelFunctions(instance);
}


void getPhysicalDevices ()
{
uint n;
vkEnumeratePhysicalDevices(instance, , null);
physicalDevices = allocator.makeArray!VkPhysicalDevice(n);
vkEnumeratePhysicalDevices(instance,,physicalDevices.ptr);
enforce(physicalDevices.length > 0,"no physical devices found");
}

void pickPhysicalDevice ()
{
if (physicalDevices.length == 1) 
{
primaryPhysicalDevice = physicalDevices[0];
} else { 
ulong maxScore,index=-1;
foreach(i,device; physicalDevices)
{
uint score = 0;
VkPhysicalDeviceProperties properties;
device.vkGetPhysicalDeviceProperties();
VkPhysicalDeviceFeatures features;
device.vkGetPhysicalDeviceFeatures();
switch(properties.deviceType)
{
case VK_PHYSICAL_DEVICE_TYPE_DISCRETE_GPU: score = 1000; break;
case VK_PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU: score = 500; break;
case VK_PHYSICAL_DEVICE_TYPE_CPU: score = 100; break;
default: score = 0;
}
if (score > maxScore)
{
maxScore = score;
index = i;
}

}
primaryPhysicalDevice = physicalDevices[index];
}
enforce(primaryPhysicalDevice,"failed to find acceptable physical device");
}

int [2] findQueueFamilies (VkPhysicalDevice dev)
{
int [2] r = [-1,-1];
uint n;
vkGetPhysicalDeviceQueueFamilyProperties(dev,,null);
auto families = memory.allocator.makeArray!VkQueueFamilyProperties(n);
vkGetPhysicalDeviceQueueFamilyProperties(dev,,families.ptr);
foreach (i,family; families)
{
if (family.queueCount > 0 && family.queueFlags & VK_QUEUE_GRAPHICS_BIT) r[0] = cast(uint) i;   
VkBool32 presentSupport = false;
vkGetPhysicalDeviceSurfaceSupportKHR(dev,cast(uint)i, surface, );
if (family.queueCount > 0 && presentSupport) r[1] = cast(uint) i;
}
enforce (r[0] >= 0,"failed to find grahpics family");
enforce (r[1] >= 0,"failed to find present family");
return r;
}

void createLogicalDevice (int[2] q)
{
const(float[]) priority = [1.0f];
VkDeviceQueueCreateInfo queueCreateInfo =
{
sType: VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO,
queueFamilyIndex: cast(uint) q[0],
queueCount: 1,
pQueuePriorities: priority.ptr,
};
VkPhysicalDeviceFeatures deviceFeatures;
VkDeviceCreateInfo createInfo =
{
sType: VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
pQueueCreateInfos: ,
queueCreateInfoCount: 1,
pEnabledFeatures: ,
};
auto r = vkCreateDevice(primaryPhysicalDevice,,null,);
enforce(r == VK_SUCCESS,"failed to create logical device");

}

void getGraphicsQueue (uint i)
{
vkGetDeviceQueue(device, 0, 0, );
enforce(graphicsQueue,"failed to get graphics queue");
}

void init (SDL_Window * window)
{
createInstance

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[Imperatorn via Digitalmars-d-announce]

On Thursday, 27 May 2021 at 10:12:43 UTC, Danny Arends wrote:

On Friday, 14 May 2021 at 21:12:55 UTC, Imperatorn wrote:

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote:

[...]


Nice! Is it on dub as well?


No not yet, It's still very very early for that I think. I was 
hoping to get some more feedback on the code as well as have 
more people test it on different platforms (e.g. 32 bit 
linux/android)


But I do plan on releasing a v0.0.1 to dub in the near future, 
when I get things like multi-texture support, STL and 3DS model 
formats working.


Danny




Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[Danny Arends via Digitalmars-d-announce]

On Friday, 14 May 2021 at 21:12:55 UTC, Imperatorn wrote:

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote:

Dear all,

I'm proud to announce CalderaD, yet another SDL2 Vulkan 
renderer in the D Programming Language. However, this one will 
work on Windows, Linux, and even Android. The current 'engine' 
is based on the excellent vulkan-tutorial.com, and uses SDL2 
via the bindbc-sdl bindings for cross-platform support. Vulkan 
support is provided by using the ErupteD binding for Vulkan.


[...]


Nice! Is it on dub as well?


No not yet, It's still very very early for that I think. I was 
hoping to get some more feedback on the code as well as have more 
people test it on different platforms (e.g. 32 bit linux/android)


But I do plan on releasing a v0.0.1 to dub in the near future, 
when I get things like multi-texture support, STL and 3DS model 
formats working.


Danny

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[Imperatorn via Digitalmars-d-announce]

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote:

Dear all,

I'm proud to announce CalderaD, yet another SDL2 Vulkan 
renderer in the D Programming Language. However, this one will 
work on Windows, Linux, and even Android. The current 'engine' 
is based on the excellent vulkan-tutorial.com, and uses SDL2 
via the bindbc-sdl bindings for cross-platform support. Vulkan 
support is provided by using the ErupteD binding for Vulkan.


[...]


Nice! Is it on dub as well?

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[bioinfornatics via Digitalmars-d-announce]

On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote:

On Friday, 14 May 2021 at 17:29:13 UTC, evilrat wrote:

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote:


Find the GPL-v3 licensed code here: 
https://github.com/DannyArends/CalderaD




You can set up platform filters in dub to automatically match 
target platforms without specifying configuration for build.


See this 
https://github.com/Superbelko/android-sdl-d/blob/master/dub.json


P.S. No idea why you choose GPL, I usually don't bother with 
GPL libraries because of license, and I think this is also the 
majority of people on this forum.


Hmm, things gotta have a license, why not GPL would CC0 be 
better? is attribution and sharing code so weird ?


I think: "license": "proprietary" also doesn't sound very 
inviting

Any suggestions license-wise ?

Thanks for the configuration tip


To complete the subject,
A GPL licence imply that any software that use your library have 
to be a GPL like licence.


Usually for a library we use a LGPL licence. That is a non viral 
licence bases on GPL.


Below a list if compatible licence :
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[evilrat via Digitalmars-d-announce]

On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote:


Hmm, things gotta have a license, why not GPL would CC0 be 
better? is attribution and sharing code so weird ?


I think: "license": "proprietary" also doesn't sound very 
inviting


It's a WIP tutorial project. It is not finished yet. It needs 
more details where needed and have everything re-checked.



Any suggestions license-wise ?




zlib, Boost, BSD/MIT, anything will do, its just the GPL itself. 
I don't think it is allowed to copy-paste any part of it at all.


Licensing is pain and I usually avoid it, so please refer to 
special web sites that will help pick the license that suit your 
intentions.


Or at least make it LGPL so it is possible to be used as a 
library without licensing headache.

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[Adam D. Ruppe via Digitalmars-d-announce]

On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote:
Hmm, things gotta have a license, why not GPL would CC0 be 
better? is attribution and sharing code so weird ?


GPL is a perfectly fine license. If people don't want to use it 
because of that, their loss, not your problem.

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[Danny Arends via Digitalmars-d-announce]

On Friday, 14 May 2021 at 17:29:13 UTC, evilrat wrote:

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote:


Find the GPL-v3 licensed code here: 
https://github.com/DannyArends/CalderaD




You can set up platform filters in dub to automatically match 
target platforms without specifying configuration for build.


See this 
https://github.com/Superbelko/android-sdl-d/blob/master/dub.json


P.S. No idea why you choose GPL, I usually don't bother with 
GPL libraries because of license, and I think this is also the 
majority of people on this forum.


Hmm, things gotta have a license, why not GPL would CC0 be 
better? is attribution and sharing code so weird ?


I think: "license": "proprietary" also doesn't sound very inviting
Any suggestions license-wise ?

Thanks for the configuration tip

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[evilrat via Digitalmars-d-announce]

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote:


Find the GPL-v3 licensed code here: 
https://github.com/DannyArends/CalderaD




You can set up platform filters in dub to automatically match 
target platforms without specifying configuration for build.


See this 
https://github.com/Superbelko/android-sdl-d/blob/master/dub.json


P.S. No idea why you choose GPL, I usually don't bother with GPL 
libraries because of license, and I think this is also the 
majority of people on this forum.

Re: SDL2 Android vulkan question

[Danny Arends via Digitalmars-d-learn]

On Sunday, 2 May 2021 at 13:43:11 UTC, evilrat wrote:
Anyway, I might try to look at this next weekend. Do you have 
this project available on github/google drive?


Open-sourced the code see:

https://github.com/DannyArends/CalderaD

Danny

CalderaD - SDL2 Vulkan renderer for windows, linux, and android

[Danny Arends via Digitalmars-d-announce]

Dear all,

I'm proud to announce CalderaD, yet another SDL2 Vulkan renderer 
in the D Programming Language. However, this one will work on 
Windows, Linux, and even Android. The current 'engine' is based 
on the excellent vulkan-tutorial.com, and uses SDL2 via the 
bindbc-sdl bindings for cross-platform support. Vulkan support is 
provided by using the ErupteD binding for Vulkan.


Find the GPL-v3 licensed code here: 
https://github.com/DannyArends/CalderaD


The name CalderaD, comes from the word caldera a large 
cauldron-like hollow that forms shortly after a volcanic 
eruption. The term comes from Spanish caldera, and Latin 
caldaria, meaning "cooking pot".


I hope this project can help others cook up some nice android 
apps, and will show that a language like D has something to offer 
on the mobile platform.


Danny

Re: SDL2 Android vulkan question

[Danny Arends via Digitalmars-d-learn]

On Sunday, 2 May 2021 at 16:42:07 UTC, evilrat wrote:

On Sunday, 2 May 2021 at 16:06:10 UTC, Danny Arends wrote:

On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote:

As for SDL2, are you sure it was built with Vulkan support?


That's the thing I worry about, since the SDL2 libraries are 
locally build using android studio and I'm kind of a noob in 
that.





Ok, since this is potentially the case, just to clarify, 
building C/C++ with CMake for Android these days is basically 
one extra parameter pointing to CMake toolchain file in your 
local NDK location when configuring your build.


https://developer.android.com/ndk/guides/cmake#file

(from the docs)
```
$ cmake \

-DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake 
\

-DANDROID_ABI=$ABI \
-DANDROID_NATIVE_API_LEVEL=$MINSDKVERSION \
$OTHER_ARGS

```

Then I would probably use gradle for the rest of the process to 
produce apk, including copy libraries step.


Thanks, but the APK builds fine, and installs. OpenGLES and SDL 
work like a charm, it's just the SDL_Vulkan_LoadLibrary call 
crashing. I think it might have to do with the bindbc-sdl 
dependency compiling with SDL_201 support, while Vulkan needs 
SDL_206 minimum. Even though I set SDL_2014 in DUB, it seems not 
to get picked up in some way.


I also found this: 
https://developer.android.com/guide/topics/manifest/uses-feature-element


So it might be the manifest needs to be updated as well.
A real puzzle,

Danny

Re: SDL2 Android vulkan question

[evilrat via Digitalmars-d-learn]

On Sunday, 2 May 2021 at 16:06:10 UTC, Danny Arends wrote:

On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote:

As for SDL2, are you sure it was built with Vulkan support?


That's the thing I worry about, since the SDL2 libraries are 
locally build using android studio and I'm kind of a noob in 
that.





Ok, since this is potentially the case, just to clarify, building 
C/C++ with CMake for Android these days is basically one extra 
parameter pointing to CMake toolchain file in your local NDK 
location when configuring your build.


https://developer.android.com/ndk/guides/cmake#file

(from the docs)
```
$ cmake \

-DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \

-DANDROID_ABI=$ABI \
-DANDROID_NATIVE_API_LEVEL=$MINSDKVERSION \
$OTHER_ARGS

```

Then I would probably use gradle for the rest of the process to 
produce apk, including copy libraries step.

Re: SDL2 Android vulkan question

[Danny Arends via Digitalmars-d-learn]

On Sunday, 2 May 2021 at 13:43:11 UTC, evilrat wrote:

On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote:

On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote:

Any thoughts on why loading the Vulkan library using SDL2 
would not work ?

thoughts in general about the process ?


Just few tips.
GC "crashes" since you have custom main, D default main has 
runtime initialization code so it "just works", in you custom 
main function try to do this before any call to D code.




Oops, nevermind. I thought you've missed runtime initialization 
at all but you have rt_init.
In that case you can try disable parallel collection, or it 
could be a bug.


https://dlang.org/spec/garbage.html#gc_config
https://dlang.org/spec/garbage.html#gc_parallel


As for SDL2, are you sure it was built with Vulkan support?
Do you have any other Vulkan apps to test if it actually 
supported by your device?


SDL2 docs also says vulkan load library should be called only 
after you created window surface. It is hard to say from 
provided code if you have that too.




Yeah, it's tricky to create an SDL window sometimes, like on 
android SDL_CreateWindow not being allowed to have it 
SDL_WINDOWPOS_CENTERED


I thought they meant use it like after SDL_Init(), but before you 
create the window. I think the function pointer might not be 
loaded since the SDL_Init returns a which means 2.0.1 for some 
reason.


I think something is going wrong and nothing is doing a dlopen() 
on vulkan.so


Anyway, I might try to look at this next weekend. Do you have 
this project available on github/google drive?


well it's just a bunch of files atm, but with a serious 
dependency chain, I'll try to minimize it. Guess for now the 
deprecated openGL has to be the fallback

Re: SDL2 Android vulkan question

[Danny Arends via Digitalmars-d-learn]

On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote:

On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote:

Any thoughts on why loading the Vulkan library using SDL2 
would not work ?

thoughts in general about the process ?


Just few tips.
GC "crashes" since you have custom main, D default main has 
runtime initialization code so it "just works", in you custom 
main function try to do this before any call to D code.


https://dlang.org/phobos/core_runtime.html#.Runtime.initialize

```d
extern(C) main()
{
import core.runtime;
Runtime.initialize();
scope(exit)
  Runtime.terminate();
}
```



Yeah, I just use the rt_init() and disable it, no real issue. 
Most of the code is @nogc code anyway.



As for SDL2, are you sure it was built with Vulkan support?


That's the thing I worry about, since the SDL2 libraries are 
locally build using android studio and I'm kind of a noob in that.


I use the provided android_project (from the sdl zip) and make 
symbolic links in the app/jni folder to:


SDL, SDL2_Image, SDL2_Mixer, Etc

I delete the creation of the libmain.so by removing the src/ 
folder


Do you have any other Vulkan apps to test if it actually 
supported by your device?


It's android 10 so it should be, but I could try creating a c 
minimal example in vulkan, although that's gonna be 500 LoC as 
well.

Re: SDL2 Android vulkan question

[evilrat via Digitalmars-d-learn]

On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote:

On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote:

Any thoughts on why loading the Vulkan library using SDL2 
would not work ?

thoughts in general about the process ?


Just few tips.
GC "crashes" since you have custom main, D default main has 
runtime initialization code so it "just works", in you custom 
main function try to do this before any call to D code.




Oops, nevermind. I thought you've missed runtime initialization 
at all but you have rt_init.
In that case you can try disable parallel collection, or it could 
be a bug.


https://dlang.org/spec/garbage.html#gc_config
https://dlang.org/spec/garbage.html#gc_parallel


As for SDL2, are you sure it was built with Vulkan support?
Do you have any other Vulkan apps to test if it actually 
supported by your device?


SDL2 docs also says vulkan load library should be called only 
after you created window surface. It is hard to say from provided 
code if you have that too.


Anyway, I might try to look at this next weekend. Do you have 
this project available on github/google drive?

Re: SDL2 Android vulkan question

[evilrat via Digitalmars-d-learn]

On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote:

Any thoughts on why loading the Vulkan library using SDL2 would 
not work ?

thoughts in general about the process ?


Just few tips.
GC "crashes" since you have custom main, D default main has 
runtime initialization code so it "just works", in you custom 
main function try to do this before any call to D code.


https://dlang.org/phobos/core_runtime.html#.Runtime.initialize

```d
extern(C) main()
{
import core.runtime;
Runtime.initialize();
scope(exit)
  Runtime.terminate();
}
```

As for SDL2, are you sure it was built with Vulkan support?
Do you have any other Vulkan apps to test if it actually 
supported by your device?

SDL2 Android vulkan question

[Danny Arends via Digitalmars-d-learn]

Dear all,

I've written a 2D/3D engine in D before which runs on windows, 
linux and android using SDL2 as the window manager and uses 
Modern OpenGL /OpenGLES for rendering. It compiles fine for 
android using ldc and works like a charm, although the garbage 
collection under android has multi-threading issues.


Since OpenGL is abandoned, I am currently adding Vulkan support 
to future proof it.


I have done this in D with the help of the bindbc-sdl and erupted 
packages and managed to get the whole vulkan-tutorial.com example 
working under windows without much hassle. (I bet it would run on 
linux without much issues as well)


So I have now been stuck for a week on getting the tutorial 
example to successfully run on android. To do this I get a DLL 
compiled with ldc, I have setup the SDL2 toolchain for android, 
with symlinks to SDL2/IMAGE/TTF/etc, I hook the call to SDL_main 
from the JNI:


```D
/* Main entry point to the program */
version (Android) {
  import core.memory;
  import core.runtime : rt_init;

  extern(C) int SDL_main(int argc, char* argv) { // Hijack the 
SDL main

rt_init();
GC.disable(); // The GC crashes on android
run(["android"]);
return(0);
  }
// Other OS can just call run() directly (No known issues with 
garbage collection)

} else { void main (string[] args) { run(args); } }
```

I create my APK using Android Studio, and load it onto my phone. 
The hook succeeds, I can do:


```D
loadSDL();
SDL_Log("SDL loaded");
SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO);
SDL_Log("SDL init");
SDL_Vulkan_LoadLibrary();
SDL_Log("SDL_Vulkan_LoadLibrary");
```

I see SDL being loaded and initialized (successfully) on my 
phone. However, the SDL_Vulkan_LoadLibrary call just crashes the 
whole thing dead, with a:


```cmd
I/SDL/APP: SDL loaded
I/SDL/APP: SDL init
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault 
addr 0x0 in tid 25878 (SDLThread), pid 25794 (SDLActivity)

```

I was wondering if I am missing something obvious. Since it works 
for SDL2 and opengles


Any thoughts on why loading the Vulkan library using SDL2 would 
not work ?

thoughts in general about the process ?

Danny

Re: BetterC issues with ErupteD Vulkan binding typedef handles

[ParticlePeter via Digitalmars-d-learn]

[snip]

Forgot to add another question. The mentioned error message is 
not too helpful in locating the real offended code. Is there a 
way to get more information or additional hints about the actual 
cause of the problem?

Re: BetterC issues with ErupteD Vulkan binding typedef handles

[ParticlePeter via Digitalmars-d-learn]

On Sunday, 20 December 2020 at 15:52:39 UTC, Adam D. Ruppe wrote:
On Sunday, 20 December 2020 at 15:45:59 UTC, ParticlePeter 
wrote:
VkSemaphore[]  wait_semaphores = [],  // 
error: TypeInfo required


does it still error if you just use = null? they work the same 
way but might avoid the annoying error.


Wow, it does, that was unexpected and unexpectedly hassle free, 
thanks a lot :-)

Re: BetterC issues with ErupteD Vulkan binding typedef handles

[Adam D. Ruppe via Digitalmars-d-learn]

On Sunday, 20 December 2020 at 15:45:59 UTC, ParticlePeter wrote:
VkSemaphore[]  wait_semaphores = [],  // 
error: TypeInfo required


does it still error if you just use = null? they work the same 
way but might avoid the annoying error.

BetterC issues with ErupteD Vulkan binding typedef handles

[ParticlePeter via Digitalmars-d-learn]

Hello,

I am experimenting with betterC and Vulkan through Erupted [0] 
binding, but unfortunately I find myself hunting down these kind 
of errors:
 ..\ErupteD\source\erupted\types.d-mixin-77(77,1): Error: 
`TypeInfo` cannot be used with -betterC


The issue is with Vulkan type handles. One such error occurs when 
a function's parameter list contains an optional slice of such 
handles, e.g.:


void queueSubmit(
VkQueuequeue,
VkCommandBuffer[]  command_buffers,
VkSemaphore[]  wait_semaphores = [],  // 
error: TypeInfo required
VkPipelineStageFlags[] wait_dest_stage_masks   = [],  // ok, 
not a handle
VkSemaphore[]  signal_semaphores   = []   // 
error: TypeInfo required

)  { .. }


A possible workaround which I found is:
VkSemaphore[] wait_semaphores = ( const VkSemaphore[] ).init,

but this feels more like fighting a symptom instead of getting 
rid of the cause.
I am wondering if there is a better way to translate these C 
typedefs to D:


// from vulkan_core.h [1]
// ...

#define VK_DEFINE_HANDLE(object) typedef struct object##_T* 
object;


#if !defined(VK_DEFINE_NON_DISPATCHABLE_HANDLE)
#if defined(__LP64__) || defined(_WIN64) || (defined(__x86_64__) 
&& !defined(__ILP32__) ) || defined(_M_X64) || defined(__ia64) || 
defined (_M_IA64) || defined(__aarch64__) || 
defined(__powerpc64__)
#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef 
struct object##_T *object;

#else
#define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef 
uint64_t object;

#endif
#endif

// ...
VK_DEFINE_HANDLE(VkQueue)
VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSemaphore)
// ...


Correspondingly to the C typedefs:

// from erupted/types.d [2]
// ...

enum VK_DEFINE_HANDLE( string name ) = "struct " ~ name ~ 
"_handle; alias " ~ name ~ " = " ~ name ~ "_handle*;";


version( X86_64 ) {
alias VK_DEFINE_NON_DISPATCHABLE_HANDLE( string name ) = 
VK_DEFINE_HANDLE!name;

enum VK_NULL_ND_HANDLE = null;
} else {
enum VK_DEFINE_NON_DISPATCHABLE_HANDLE( string name ) = 
"alias " ~ name ~ " = ulong;";

enum VK_NULL_ND_HANDLE = 0uL;
}

// ...
mixin( VK_DEFINE_HANDLE!q{VkQueue} );
mixin( VK_DEFINE_NON_DISPATCHABLE_HANDLE!q{VkSemaphore} );
// ...


I am running building for x64, would anyone know a smoother 
betterC approach to these typedefs?



[0] https://github.com/ParticlePeter/ErupteD
[1] 
https://github.com/KhronosGroup/Vulkan-Headers/blob/master/include/vulkan/vulkan_core.h
[2] 
https://github.com/ParticlePeter/ErupteD/blob/master/source/erupted/types.d

ErupteD v2.0 + Vulkan v1.1 breaking changes and NEW transition strategy

[ParticlePeter via Digitalmars-d-announce]

The deprecated ErupteD was un-deprecated again. Version v2.0 
comes with Vulkan 1.1 support and breaking changes regarding its 
dependency mechanism. Details in the projects dub and github [0] 
pages.


Regarding [1]:
ErupteD-V1 will be destroyed, ErupteD-V2 continued to implement a 
valid automation and testing scenario. If this is in placed a 
transition will be reconsider.


Apologies for your inconveniences, lessons learned. Put less on 
the plate and decrease the gradient of the gradual transition.


[0] https://github.com/ParticlePeter/ErupteD
[1] 
https://forum.dlang.org/thread/ljuodxxxqocakcczw...@forum.dlang.org

Re: Vulkan ErupteD breaking changes and transition strategy

[ParticlePeter via Digitalmars-d-announce]

On Sunday, 25 March 2018 at 22:23:06 UTC, Peter Particle wrote:

ErupteD [0] is deprecated (one of its major modules).


[snip]



Rewind and Undo
---

I must apologize for the mess I have created, ErupteD is 
un-deprecated again. It will be further developed until 
ErupteD-V2 has a proper automation and testing system in place. 
There will be a separate announcement, when ErupteD v2.0.0 
reaches vulkan 1.1 status.

Re: Vulkan ErupteD breaking changes and transition strategy

[ParticlePeter via Digitalmars-d-announce]

On Monday, 26 March 2018 at 12:22:25 UTC, Anton Fediushin wrote:

On Monday, 26 March 2018 at 11:13:03 UTC, ParticlePeter wrote:


[snip]
Here I was hoping for a little more attentive reading, the 
bugfix (if any bugs happen in the end) for v1.1.70 would be 
v1.1.71 (as in "point seven ONE") -bugfix.1. I would hope for 
community colaboration to always use prerelease. Not sure if 
this is the best idea, as it cannot be specified in dub 
dependency afaics, but only on dub upgrade. That might 
actually be expecting to much from users. I'll think about it.


But then 1.1.71 without `-bugfix.1` will be a binding to vulkan 
v1.1.71? That doesn't make any sense.


Actually, for me it does, afaik we can put whatever into the 
pre-release names, so this would work for me: 
v1.1.71-bugfix.1.1.70.1
It informs me that v1.1.71 is on its way but we are fixing 1.1.70 
bugs before that.


Dah again, no it cannot. Could it be that you are talking 
about DEPRECATED ErupteD? Please compare [0] and [1], and 
their project names.


I'm talking about erupted-v1.


I think you have old ErupteD modules in your ErupteD-V1 source 
directory. Please try to remove them and re-fetch E-V1.


[snip]
move the semvers. Actually, if you use ErupteD as a 
submodule, why do care about semvers at all?


Because dub can notify about new version. That's why it 
exists in the first place


Sorry, here I cannot follow any more, so why are you using it 
then as a submodule again?


Erupted_v1 has a configuration which uses old derelict-util. 
Even though I use derelict-glfw to load vulkan, dub downloads 
both old derelict-util and the new one used by derelict-glfw. 
This results in warnings because versions mismatch (erupted 
wants old one while derelict-glfw uses newest).


That's not what I meant. I don't understand why you use ErupteD 
as dub project AND as submodule. I don't see the advantage of 
this approach. More specific, if you rely on dub informing you 
that a new version is out, why use it as a submodule?


I opened an issue about erupted-v2 on linux as well: 
https://github.com/ParticlePeter/Erupted-V2/issues/1


Fixed, but the next issue is waiting already. Maybe not the best 
idea after all. Anyway, lets try the pre-rlease suggestion :-)



The GREATER Plan - as promised
--

I want to evolve and learn more about techniques which I have 
never touched before. This is already great I would think. But 
fun aside, I would like to look into full automation.


1.) get informed about vulkan-docs updates, trigger automated 
build process with V-Erupt. Is this possible? Don't know, want 
to find out.


I think it is possible.

2.) setup auto testing for ErupteD-V2. If fail, get informed. 
Else apply version tag, the same as vulkan-docs. Is this 
possible? Don't know, want to find out.


It is possible but tests are required. More tests - better.


That's the plan, and that's the reason ErupteD-V1 exists as 
fallback.

Re: Vulkan ErupteD breaking changes and transition strategy

[Anton Fediushin via Digitalmars-d-announce]

On Monday, 26 March 2018 at 11:13:03 UTC, ParticlePeter wrote:
I strongly believe that the generator can be made fail safe, so 
that the produced binding is error free. I will elaborate a 
little more about the greater plan at the bottom, I just didn't 
think that anyone is interested in it.


Well, I am interested in it - Vulkan is cool and so is D.

Here I was hoping for a little more attentive reading, the 
bugfix (if any bugs happen in the end) for v1.1.70 would be 
v1.1.71 (as in "point seven ONE") -bugfix.1. I would hope for 
community colaboration to always use prerelease. Not sure if 
this is the best idea, as it cannot be specified in dub 
dependency afaics, but only on dub upgrade. That might actually 
be expecting to much from users. I'll think about it.


But then 1.1.71 without `-bugfix.1` will be a binding to vulkan 
v1.1.71? That doesn't make any sense.


Dah again, no it cannot. Could it be that you are talking about 
DEPRECATED ErupteD? Please compare [0] and [1], and their 
project names.


I'm talking about erupted-v1.

Erupted-V2 doesn't work for me - when compiling on Linux it 
fails on some Windows-specific code. I'll open an issue as 
soon as I get home.


I am really sorry for that, I have an idea what might be 
wrong. Please, if you don't min, post an issue with the 
error. I hope that in this alpha stage of ErupteD-V2, where 
some poo poo was expected to hit the fan, it would be ok to 
move the semvers. Actually, if you use ErupteD as a 
submodule, why do care about semvers at all?


Because dub can notify about new version. That's why it exists 
in the first place


Sorry, here I cannot follow any more, so why are you using it 
then as a submodule again?


Erupted_v1 has a configuration which uses old derelict-util. Even 
though I use derelict-glfw to load vulkan, dub downloads both old 
derelict-util and the new one used by derelict-glfw. This results 
in warnings because versions mismatch (erupted wants old one 
while derelict-glfw uses newest).


I opened an issue about erupted-v2 on linux as well: 
https://github.com/ParticlePeter/Erupted-V2/issues/1



The GREATER Plan - as promised
--

I want to evolve and learn more about techniques which I have 
never touched before. This is already great I would think. But 
fun aside, I would like to look into full automation.


1.) get informed about vulkan-docs updates, trigger automated 
build process with V-Erupt. Is this possible? Don't know, want 
to find out.


I think it is possible.

2.) setup auto testing for ErupteD-V2. If fail, get informed. 
Else apply version tag, the same as vulkan-docs. Is this 
possible? Don't know, want to find out.


It is possible but tests are required. More tests - better.

Re: Vulkan ErupteD breaking changes and transition strategy

[ParticlePeter via Digitalmars-d-announce]

On Monday, 26 March 2018 at 09:50:16 UTC, Anton Fediushin wrote:

On Monday, 26 March 2018 at 09:20:13 UTC, ParticlePeter wrote:
First of all, don't worry, don't panic, we will figure it out, 
together ;-). Everything will be alright in the end, and if 
not, its not the end.

[snip]
The bug then is not in ErupteD but in its generator. It needs 
to be fixed there.
The plan was to then move the sem vers to the bug fix release. 
Never done that, wanted to try it. Buuut, got inspired by a 
great idea 3 min ago (please read on).


After generator is fixed it'll produce new binding which should 
be marked as a new release.


I strongly believe that the generator can be made fail safe, so 
that the produced binding is error free. I will elaborate a 
little more about the greater plan at the bottom, I just didn't 
think that anyone is interested in it.


[snip]

Great idea! Have not considered it. So the Bug fix for version 
1.1.70 could be 1.1.71-bugfix.1. How does it screw up dub 
semver?


Dub isn't going to use pre-release version unless it is 
specified in user's dub.json. So, if user already has erupted 
1.1.70 as a dependency, he will *never* receive 1.1.70-bugfix.1 
unless he updates his dub.json. Basic 'dub upgrade' won't work 
in this case.


Here I was hoping for a little more attentive reading, the bugfix 
(if any bugs happen in the end) for v1.1.70 would be v1.1.71 (as 
in "point seven ONE") -bugfix.1. I would hope for community 
colaboration to always use prerelease. Not sure if this is the 
best idea, as it cannot be specified in dub dependency afaics, 
but only on dub upgrade. That might actually be expecting to much 
from users. I'll think about it.



This is a *bad* idea and you shouldn't do that.


Why is it a bad idea, could you elaborate?


Because it doesn't follow semver meaning that dub won't work 
correctly.


Dah, yes it does! As explained above at least :-)

[snip]


Indeed, metadata change isn't going to trigger an update 
neither does pre-release.


My solution:
1. Add generator as a git submodule (generator could be 
versioned)
2. Start versioning from 2.0.0 increasing MINOR when new Vulkan 
version is supported and increasing PATCH when bug fixes 
happen. Metadata can be added too.


This way users are going to always get latest version possible.

It'll look like this:

2.0.0+1.0.69
2.0.1+1.0.69 - first bugfix
2.1.0+1.0.70 - new vulkan version
2.1.1+1.0.70 - first bugfix

...And so on.


Hm, don't like it. The generator part is not changing when 
releasing a new vulkan version, but its version has to be 
incremented to triger an update. The generator itself should be 
incremented only if he produces buggy code. Actually this is part 
of my 1. explenation.


Also, if you'll stick to your *bad-in-every-way* plan, you 
*can't* publish erupted-v2 as erupted package on dub 
registry. You'd have to remove it from registry first, which 
will break every single package that depends on it.


Thanks for your nice words all over the place, sun is rising 
in my hart :-). Well, yeah, I didn't. ErupteD-V2 is published 
as erupted_v2, and Erupted-V1 as erupted_v1.


Hey, I have another awesome idea, you are an the safe side, 
you just change your dependency to erupted_v1. I hope this is 
not too much of effort on your side? Sorry for inconvenience. 
Ah, but wait! Fear not, I read ahead and have a solution for 
your way of using erupted, just read on.


I already use erupted-v1. Deprecation messages annoy me.


Dah again, no it cannot. Could it be that you are talking about 
DEPRECATED ErupteD? Please compare [0] and [1], and their project 
names.


[snip]
Ah, but that was one of the two reason for the breaking 
change. Btw. I am/was using diferent versioned derelict-utils 
and have no problems other than being informed that xcb-d (on 
windows!) does not use it. What is the "impossible" part you 
have to face?


Erupted uses derelict-util 2.something.something and 
derelict-glfw uses 3.0.0-beta. Because of that dub warns about 
version mismatch every single time I build my program.


Well, that's not impossible to use, but pretty annoying.


Yeah sounds different than impossible, doesn't it? But as said, 
that is 2. reason of my breaking change.


Erupted-V2 doesn't work for me - when compiling on Linux it 
fails on some Windows-specific code. I'll open an issue as 
soon as I get home.


I am really sorry for that, I have an idea what might be 
wrong. Please, if you don't min, post an issue with the error. 
I hope that in this alpha stage of ErupteD-V2, where some poo 
poo was expected to hit the fan, it would be ok to move the 
semvers. Actually, if you use ErupteD as a submodule, why do 
care about semvers at all?


Because dub can notify about new version. That's why it exists 
in the first place


Sorry, here I cannot follow any more, so why are you using it 
then as a submodule again?



The GREATER Plan - as promised
--

I want to evolve 

Re: Vulkan ErupteD breaking changes and transition strategy

[Anton Fediushin via Digitalmars-d-announce]

On Monday, 26 March 2018 at 09:20:13 UTC, ParticlePeter wrote:
First of all, don't worry, don't panic, we will figure it out, 
together ;-). Everything will be alright in the end, and if 
not, its not the end.


On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:
1. This breaks semver. You shouldn't just use Vulkan's 
versions. If you release 1.0.69 which contains bindings to 
Vulkan 1.0.69 and there is a bug in the binding which you want 
to fix, you have to increase PATCH number which results in 
1.0.70 which (obviously) is not a binding to Vulkan 1.0.70.


The bug then is not in ErupteD but in its generator. It needs 
to be fixed there.
The plan was to then move the sem vers to the bug fix release. 
Never done that, wanted to try it. Buuut, got inspired by a 
great idea 3 min ago (please read on).


After generator is fixed it'll produce new binding which should 
be marked as a new release.


Even though you can use PRE-RELEASE part of semver to show 
users that this is a bugfix release (ie. 1.0.69-bugfix.1) this 
shouldn't be used because it breaks semver *again* and dub 
(which follows semver) isn't going to tolerate that.


Great idea! Have not considered it. So the Bug fix for version 
1.1.70 could be 1.1.71-bugfix.1. How does it screw up dub 
semver?


Dub isn't going to use pre-release version unless it is specified 
in user's dub.json. So, if user already has erupted 1.1.70 as a 
dependency, he will *never* receive 1.1.70-bugfix.1 unless he 
updates his dub.json. Basic 'dub upgrade' won't work in this case.



This is a *bad* idea and you shouldn't do that.


Why is it a bad idea, could you elaborate?


Because it doesn't follow semver meaning that dub won't work 
correctly.



Just increase MAJOR version and start from there:

2.0.0 - Changing how binding works, Vulkan v1.0.69
2.1.0 - Vulkan 1.0.70

...And so on. This way semver is followed and you don't have 
to mess with erupted-v1 and erupted-v2 repos.


Thought about that, but there is one issue which I mentioned in 
the announcement. I experience it as a bad idea to have the 
generator part of the binding. Both of them have different 
purpose and should have different version numbers. Meta data is 
nice approach as in GenVer+VulkanVer, but unfortunately dub 
upgrade is not triggered if Only vulkanVer increments. Hm...


Indeed, metadata change isn't going to trigger an update neither 
does pre-release.


My solution:
1. Add generator as a git submodule (generator could be versioned)
2. Start versioning from 2.0.0 increasing MINOR when new Vulkan 
version is supported and increasing PATCH when bug fixes happen. 
Metadata can be added too.


This way users are going to always get latest version possible.

It'll look like this:

2.0.0+1.0.69
2.0.1+1.0.69 - first bugfix
2.1.0+1.0.70 - new vulkan version
2.1.1+1.0.70 - first bugfix

...And so on.

Also, if you'll stick to your *bad-in-every-way* plan, you 
*can't* publish erupted-v2 as erupted package on dub registry. 
You'd have to remove it from registry first, which will break 
every single package that depends on it.


Thanks for your nice words all over the place, sun is rising in 
my hart :-). Well, yeah, I didn't. ErupteD-V2 is published as 
erupted_v2, and Erupted-V1 as erupted_v1.


Hey, I have another awesome idea, you are an the safe side, you 
just change your dependency to erupted_v1. I hope this is not 
too much of effort on your side? Sorry for inconvenience. Ah, 
but wait! Fear not, I read ahead and have a solution for your 
way of using erupted, just read on.


I already use erupted-v1. Deprecation messages annoy me.


2. Great! I ended up adding erupted as a git submodule just so


Wouldn't it be possible for you to switch your submodule to 
ErupteD-V1 then?
I mean, that's the reason for repo "mess" and gradual 
transition.


I can remove all of the unnecessary dependencies (erupted uses 
pretty old derelict-util which makes it impossible to use both 
erupted and last version of derelict-glfw).


Ah, but that was one of the two reason for the breaking change. 
Btw. I am/was using diferent versioned derelict-utils and have 
no problems other than being informed that xcb-d (on windows!) 
does not use it. What is the "impossible" part you have to face?


Erupted uses derelict-util 2.something.something and 
derelict-glfw uses 3.0.0-beta. Because of that dub warns about 
version mismatch every single time I build my program.


Well, that's not impossible to use, but pretty annoying.

Erupted-V2 doesn't work for me - when compiling on Linux it 
fails on some Windows-specific code. I'll open an issue as 
soon as I get home.


I am really sorry for that, I have an idea what might be wrong. 
Please, if you don't min, post an issue with the error. I hope 
that in this alpha stage of ErupteD-V2, where some poo poo was 
expected to hit the fan, it would be ok to move the semvers. 
Actually, if you use ErupteD as a submodule, why do care about 
semvers a

Re: Vulkan ErupteD breaking changes and transition strategy

[ParticlePeter via Digitalmars-d-announce]

First of all, don't worry, don't panic, we will figure it out, 
together ;-). Everything will be alright in the end, and if not, 
its not the end.


On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:
1. This breaks semver. You shouldn't just use Vulkan's 
versions. If you release 1.0.69 which contains bindings to 
Vulkan 1.0.69 and there is a bug in the binding which you want 
to fix, you have to increase PATCH number which results in 
1.0.70 which (obviously) is not a binding to Vulkan 1.0.70.


The bug then is not in ErupteD but in its generator. It needs to 
be fixed there.
The plan was to then move the sem vers to the bug fix release. 
Never done that, wanted to try it. Buuut, got inspired by a great 
idea 3 min ago (please read on).


Even though you can use PRE-RELEASE part of semver to show 
users that this is a bugfix release (ie. 1.0.69-bugfix.1) this 
shouldn't be used because it breaks semver *again* and dub 
(which follows semver) isn't going to tolerate that.


Great idea! Have not considered it. So the Bug fix for version 
1.1.70 could be 1.1.71-bugfix.1. How does it screw up dub semver?



This is a *bad* idea and you shouldn't do that.


Why is it a bad idea, could you elaborate?


Just increase MAJOR version and start from there:

2.0.0 - Changing how binding works, Vulkan v1.0.69
2.1.0 - Vulkan 1.0.70

...And so on. This way semver is followed and you don't have to 
mess with erupted-v1 and erupted-v2 repos.


Thought about that, but there is one issue which I mentioned in 
the announcement. I experience it as a bad idea to have the 
generator part of the binding. Both of them have different 
purpose and should have different version numbers. Meta data is 
nice approach as in GenVer+VulkanVer, but unfortunately dub 
upgrade is not triggered if Only vulkanVer increments. Hm...


Also, if you'll stick to your *bad-in-every-way* plan, you 
*can't* publish erupted-v2 as erupted package on dub registry. 
You'd have to remove it from registry first, which will break 
every single package that depends on it.


Thanks for your nice words all over the place, sun is rising in 
my hart :-). Well, yeah, I didn't. ErupteD-V2 is published as 
erupted_v2, and Erupted-V1 as erupted_v1.


Hey, I have another awesome idea, you are an the safe side, you 
just change your dependency to erupted_v1. I hope this is not too 
much of effort on your side? Sorry for inconvenience. Ah, but 
wait! Fear not, I read ahead and have a solution for your way of 
using erupted, just read on.



2. Great! I ended up adding erupted as a git submodule just so


Wouldn't it be possible for you to switch your submodule to 
ErupteD-V1 then?

I mean, that's the reason for repo "mess" and gradual transition.

I can remove all of the unnecessary dependencies (erupted uses 
pretty old derelict-util which makes it impossible to use both 
erupted and last version of derelict-glfw).


Ah, but that was one of the two reason for the breaking change. 
Btw. I am/was using diferent versioned derelict-utils and have no 
problems other than being informed that xcb-d (on windows!) does 
not use it. What is the "impossible" part you have to face?


Erupted-V2 doesn't work for me - when compiling on Linux it 
fails on some Windows-specific code. I'll open an issue as soon 
as I get home.


I am really sorry for that, I have an idea what might be wrong. 
Please, if you don't min, post an issue with the error. I hope 
that in this alpha stage of ErupteD-V2, where some poo poo was 
expected to hit the fan, it would be ok to move the semvers. 
Actually, if you use ErupteD as a submodule, why do care about 
semvers at all?


Please be patient we have not reached the end of the transition 
period, where everything will be all right again [0] at the end, 
I promise!


[0] http://make-everything-ok.com/

Re: Vulkan ErupteD breaking changes and transition strategy

[Seb via Digitalmars-d-announce]

On Monday, 26 March 2018 at 09:04:20 UTC, Anton Fediushin wrote:

On Monday, 26 March 2018 at 07:51:31 UTC, Seb wrote:
On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin 
wrote:

This is a *bad* idea and you shouldn't do that.

Just increase MAJOR version and start from there:

2.0.0 - Changing how binding works, Vulkan v1.0.69
2.1.0 - Vulkan 1.0.70

...And so on. This way semver is followed and you don't have 
to mess with erupted-v1 and erupted-v2 repos.


Also note that SemVer allows to attach meta data:

2.0.0+1.0.69


That'll work too, but I'm not sure how dub handles it. Anyway, 
even a little note in release description "Vulkan API vX.X.X" 
should be enough.


It will work fine with dub (it just ignores the meta data).
For example, if you do a `dub add-local`, your package version is 
"+ annotated" with the git commit sha.

Re: Vulkan ErupteD breaking changes and transition strategy

[Anton Fediushin via Digitalmars-d-announce]

On Monday, 26 March 2018 at 07:51:31 UTC, Seb wrote:

On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:

This is a *bad* idea and you shouldn't do that.

Just increase MAJOR version and start from there:

2.0.0 - Changing how binding works, Vulkan v1.0.69
2.1.0 - Vulkan 1.0.70

...And so on. This way semver is followed and you don't have 
to mess with erupted-v1 and erupted-v2 repos.


Also note that SemVer allows to attach meta data:

2.0.0+1.0.69


That'll work too, but I'm not sure how dub handles it. Anyway, 
even a little note in release description "Vulkan API vX.X.X" 
should be enough.

Re: Vulkan ErupteD breaking changes and transition strategy

[Seb via Digitalmars-d-announce]

On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:

This is a *bad* idea and you shouldn't do that.

Just increase MAJOR version and start from there:

2.0.0 - Changing how binding works, Vulkan v1.0.69
2.1.0 - Vulkan 1.0.70

...And so on. This way semver is followed and you don't have to 
mess with erupted-v1 and erupted-v2 repos.


Also note that SemVer allows to attach meta data:

2.0.0+1.0.69

Build metadata MAY be denoted by appending a plus sign and a 
series of dot separated identifiers immediately following the 
patch or pre-release version. Identifiers MUST comprise only 
ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST 
NOT be empty. Build metadata SHOULD be ignored when determining 
version precedence. Thus two versions that differ only in the 
build metadata, have the same precedence.


https://semver.org/#spec-item-10

Re: Vulkan ErupteD breaking changes and transition strategy

[Anton Fediushin via Digitalmars-d-announce]

On Sunday, 25 March 2018 at 22:23:06 UTC, Peter Particle wrote:
ErupteD [0] is deprecated (one of its major modules). The 
project content is supposed to be replaced completely. Current 
state was copied into ErupteD-V1 [1] (without deprecation 
message), neither ErupteD nor ErupteD-V1 will be further 
developed.
The breaking changes and Vulkan 1.1 are implemented in 
ErupteD-V2 [2]. At some future point ErupteD will be destroyed 
and recreated with all releases of ErupteD-V2 [3].


Two issues bugged me with the previous design of the binding:
1. versions are not only disconnected from, but also far beyond 
Vulkan
2. too many dub dependencies - if on windows, than platform 
foreign ones


1. this is the reason for the involved transition, ErupteD 
needs to get rid of all releases / version tags to restart with 
a clean slate.
I also extracted the python generator script into its own 
non-dub project, V-Erupt [5]. It was kind of wired to mix two 
different purposes into one project version scheme.


2. the new approach does not require dependencies at all (other 
than phobos / druntime). Platform dependent extensions are 
implemented in form of a parameterizable mixin template. User 
is supposed to mix them into his project and take care of the 
dependencies himself [4]. Platform windows is pre-instantiated, 
as it relies only on druntime. With this approach dub cache 
stays clean from foreign platform dependencies and silences 
version mismatch noise.
While at it, I also removed the DerelictUtil dependency and 
added simple entrypoint loading mechanics. ErupteD-V2 is now 
fully nothrow @nogc and should be -betterC compatible (not 
tested yet). Moreover, no requirement for dub configurations 
any more.


[0] : https://github.com/ParticlePeter/ErupteD
[1] : https://github.com/ParticlePeter/ErupteD-V1
[2] : https://github.com/ParticlePeter/ErupteD-V2
[3] : 
https://github.com/ParticlePeter/ErupteD-V2#erupted-deprecation-and-upgrade-process
[4] : 
https://github.com/ParticlePeter/ErupteD-V2#platform-extensions

[5] : https://github.com/ParticlePeter/V-Erupt


1. This breaks semver. You shouldn't just use Vulkan's versions. 
If you release 1.0.69 which contains bindings to Vulkan 1.0.69 
and there is a bug in the binding which you want to fix, you have 
to increase PATCH number which results in 1.0.70 which 
(obviously) is not a binding to Vulkan 1.0.70.


Even though you can use PRE-RELEASE part of semver to show users 
that this is a bugfix release (ie. 1.0.69-bugfix.1) this 
shouldn't be used because it breaks semver *again* and dub (which 
follows semver) isn't going to tolerate that.


This is a *bad* idea and you shouldn't do that.

Just increase MAJOR version and start from there:

2.0.0 - Changing how binding works, Vulkan v1.0.69
2.1.0 - Vulkan 1.0.70

...And so on. This way semver is followed and you don't have to 
mess with erupted-v1 and erupted-v2 repos.


Also, if you'll stick to your *bad-in-every-way* plan, you 
*can't* publish erupted-v2 as erupted package on dub registry. 
You'd have to remove it from registry first, which will break 
every single package that depends on it.


2. Great! I ended up adding erupted as a git submodule just so I 
can remove all of the unnecessary dependencies (erupted uses 
pretty old derelict-util which makes it impossible to use both 
erupted and last version of derelict-glfw).


Erupted-V2 doesn't work for me - when compiling on Linux it fails 
on some Windows-specific code. I'll open an issue as soon as I 
get home.

Vulkan ErupteD breaking changes and transition strategy

[Peter Particle via Digitalmars-d-announce]

ErupteD [0] is deprecated (one of its major modules). The project 
content is supposed to be replaced completely. Current state was 
copied into ErupteD-V1 [1] (without deprecation message), neither 
ErupteD nor ErupteD-V1 will be further developed.
The breaking changes and Vulkan 1.1 are implemented in ErupteD-V2 
[2]. At some future point ErupteD will be destroyed and recreated 
with all releases of ErupteD-V2 [3].


Two issues bugged me with the previous design of the binding:
1. versions are not only disconnected from, but also far beyond 
Vulkan
2. too many dub dependencies - if on windows, than platform 
foreign ones


1. this is the reason for the involved transition, ErupteD needs 
to get rid of all releases / version tags to restart with a clean 
slate.
I also extracted the python generator script into its own non-dub 
project, V-Erupt [5]. It was kind of wired to mix two different 
purposes into one project version scheme.


2. the new approach does not require dependencies at all (other 
than phobos / druntime). Platform dependent extensions are 
implemented in form of a parameterizable mixin template. User is 
supposed to mix them into his project and take care of the 
dependencies himself [4]. Platform windows is pre-instantiated, 
as it relies only on druntime. With this approach dub cache stays 
clean from foreign platform dependencies and silences version 
mismatch noise.
While at it, I also removed the DerelictUtil dependency and added 
simple entrypoint loading mechanics. ErupteD-V2 is now fully 
nothrow @nogc and should be -betterC compatible (not tested yet). 
Moreover, no requirement for dub configurations any more.


[0] : https://github.com/ParticlePeter/ErupteD
[1] : https://github.com/ParticlePeter/ErupteD-V1
[2] : https://github.com/ParticlePeter/ErupteD-V2
[3] : 
https://github.com/ParticlePeter/ErupteD-V2#erupted-deprecation-and-upgrade-process
[4] : 
https://github.com/ParticlePeter/ErupteD-V2#platform-extensions

[5] : https://github.com/ParticlePeter/V-Erupt

Re: Vulkan

[Peter Campbell via Digitalmars-d]

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote:
I wanted to do some experimentation with Vulkan using D. None 
of the projects that I found (derelict-vulkan, d-vulkan and 
erupted) work.


Are there D bindings to Vulkan that actually work?


I had success using Vulkan in University by using Derelict-GLFW3 
and Erupted, what issues did you have with them?

Re: Vulkan

[rumbu via Digitalmars-d]

On Saturday, 17 February 2018 at 05:52:38 UTC, Jonathan M Davis 
wrote:


Well, in D-speak, C header definitions rewritten as D so that D 
can call the C functions are exactly what bindings are, whereas 
if bindings are wrapped in D code to make them more D-like, 
those are called wrappers. I don't know that there's a specific 
term for a case where marshalling is involved.




Dynamic binding?

Re: Vulkan

[Jonathan M Davis via Digitalmars-d]

On Saturday, February 17, 2018 13:52:06 Danni Coy via Digitalmars-d wrote:
> On Wed, Feb 14, 2018 at 2:26 PM, rikki cattermole via Digitalmars-d <
>
> digitalmars-d@puremagic.com> wrote:
> > On 13/02/2018 10:54 PM, Danni Coy wrote:
> >> On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d <
> >>
> >> digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> 
wrote:
> >> I wanted to do some experimentation with Vulkan using D. None of
> >> the
> >> projects that I found (derelict-vulkan, d-vulkan and erupted) work.
> >>
> >> Are there D bindings to Vulkan that actually work?
> >>
> >> strictly speaking you don't need a binding, you can access C code
> >> directly as long as you write compatible header definitions for the
> >> parts
> >> of vulkan you are actually using in your code.
> >
> > Which is then called a binding ;)
>
> The programmers I work with like to differentiate between situations where
> you can call code directly and when you have to do stuff like marshalling
> to get code in one language to talk to code in another language so I tend
> not to think of writing header definitions as making bindings.

Well, in D-speak, C header definitions rewritten as D so that D can call the
C functions are exactly what bindings are, whereas if bindings are wrapped
in D code to make them more D-like, those are called wrappers. I don't know
that there's a specific term for a case where marshalling is involved.

- Jonathan M Davis

Re: Vulkan

[Danni Coy via Digitalmars-d]

On Wed, Feb 14, 2018 at 2:26 PM, rikki cattermole via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 13/02/2018 10:54 PM, Danni Coy wrote:
>
>>
>> On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d <
>> digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>>
>> I wanted to do some experimentation with Vulkan using D. None of the
>> projects that I found (derelict-vulkan, d-vulkan and erupted) work.
>>
>> Are there D bindings to Vulkan that actually work?
>>
>>
>> strictly speaking you don't need a binding, you can access C code
>> directly as long as you write compatible header definitions for the parts
>> of vulkan you are actually using in your code.
>>
>
> Which is then called a binding ;)
>

The programmers I work with like to differentiate between situations where
you can call code directly and when you have to do stuff like marshalling
to get code in one language to talk to code in another language so I tend
not to think of writing header definitions as making bindings.

Re: Vulkan

[Rubn via Digitalmars-d]

On Friday, 16 February 2018 at 22:58:30 UTC, Ivan Trombley wrote:
On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker 
wrote:
What [does] it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.


Derelict-vulkan is Windows only ATM.


The only difference is the one specific function for creating the 
surface. You are better off using something like SDL2 for 
creating the window anyways, which takes care of the only OS 
specific code of vulkan.


None of the types also have default value set to the proper value.

https://github.com/Zoadian/DerelictVulkan/blob/master/source/derelict/vulkan/types.d#L1102

It's not that difficult to add though, the name of the struct 
name is pretty much the type enum name but with all caps and 
underscores. A simple regex replace and formatting easily adds 
most of them.

Re: Vulkan

[Zoadian via Digitalmars-d]

On Friday, 16 February 2018 at 22:58:30 UTC, Ivan Trombley wrote:
On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker 
wrote:
What [does] it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.


Derelict-vulkan is Windows only ATM.


Actually someone added posix support. Just forgot to flag a new 
release. (I did not test posix support myself yet).

If there are other issues please file them on GitHub.

Re: Vulkan

[Ivan Trombley via Digitalmars-d]

On Wednesday, 14 February 2018 at 00:22:25 UTC, flamencofantasy 
wrote:

Maybe these work, not sure;

https://github.com/Rikarin/VulkanizeD


Thanks, I'll check this out.

Re: Vulkan

[Ivan Trombley via Digitalmars-d]

On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote:
What [does] it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.


Derelict-vulkan is Windows only ATM.

Re: Vulkan

[rikki cattermole via Digitalmars-d]

On 13/02/2018 10:54 PM, Danni Coy wrote:


On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d 
<digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:


I wanted to do some experimentation with Vulkan using D. None of the
projects that I found (derelict-vulkan, d-vulkan and erupted) work.

Are there D bindings to Vulkan that actually work?


strictly speaking you don't need a binding, you can access C code 
directly as long as you write compatible header definitions for the 
parts of vulkan you are actually using in your code.


Which is then called a binding ;)

Re: Vulkan

[Mike Parker via Digitalmars-d]

On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote:



What doesn't it mean


Eh, what *does* it mean.

Re: Vulkan

[Mike Parker via Digitalmars-d]

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote:
I wanted to do some experimentation with Vulkan using D. None 
of the projects that I found (derelict-vulkan, d-vulkan and 
erupted) work.


Are there D bindings to Vulkan that actually work?


What doesn't it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.

Re: Vulkan

[flamencofantasy via Digitalmars-d]

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote:
I wanted to do some experimentation with Vulkan using D. None 
of the projects that I found (derelict-vulkan, d-vulkan and 
erupted) work.


Are there D bindings to Vulkan that actually work?


Maybe these work, not sure;

https://github.com/Rikarin/VulkanizeD

Re: Vulkan

[Danni Coy via Digitalmars-d]

On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> I wanted to do some experimentation with Vulkan using D. None of the
> projects that I found (derelict-vulkan, d-vulkan and erupted) work.
>
> Are there D bindings to Vulkan that actually work?
>

strictly speaking you don't need a binding, you can access C code directly
as long as you write compatible header definitions for the parts of vulkan
you are actually using in your code.

eg
extern(C) int someExternalCLibraryFunction ();

auto a = someExternalCLibraryFunction();

Just make sure that you link to that C Library when you build.

If you do this on an as needed basis It's not too painful.

Vulkan

[Ivan Trombley via Digitalmars-d]

I wanted to do some experimentation with Vulkan using D. None of 
the projects that I found (derelict-vulkan, d-vulkan and erupted) 
work.


Are there D bindings to Vulkan that actually work?

Weekend Project: Vulkan-DPP

[Swoorup Joshi via Digitalmars-d]

Hi All,

I am toying with the idea to use 
https://github.com/KhronosGroup/Vulkan-Hpp to target the D 
language. I haven't started it yet, but would like to hear 
people's thought and opinion on it.


My goal is learning about vulkan and D in general. The existing 
wrappers we have namely: ErupteD is directly one-to-one wrapper 
based on C.


Thanks,
Swoorup

Re: A ready to use Vulkan triangle example for D

[Manuel König via Digitalmars-d-announce]

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.

Re: A ready to use Vulkan triangle example for D

[maik klein via Digitalmars-d-announce]

On Monday, 30 May 2016 at 11:30:24 UTC, Manuel König wrote:

On Fri, 27 May 2016 18:40:24 +, 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.

Re: A ready to use Vulkan triangle example for D

[Manuel König via Digitalmars-d-announce]

On Fri, 27 May 2016 18:40:24 +, 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.

Re: A ready to use Vulkan triangle example for D

[Alex Parrill via Digitalmars-d-announce]

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...

Re: A ready to use Vulkan triangle example for D

[maik klein via Digitalmars-d-announce]

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

Re: A ready to use Vulkan triangle example for D

[maik klein via Digitalmars-d-announce]

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 = 


vertexInputStateCreateInfo.vertexAttributeDescriptionCount = 1;
vertexInputStateCreateInfo.pVertexAttributeDescriptions = 



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 = ,
vertexAttributeDescriptionCount = 1,
pVertexAttributeDescriptions = ,
};


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.

Re: A ready to use Vulkan triangle example for D

[Alex Parrill via Digitalmars-d-announce]

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 = 


vertexInputStateCreateInfo.vertexAttributeDescriptionCount = 1;
vertexInputStateCreateInfo.pVertexAttributeDescriptions = 



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 = ,
vertexAttributeDescriptionCount = 1,
pVertexAttributeDescriptions = ,
};

Re: A ready to use Vulkan triangle example for D

[maik klein via Digitalmars-d-announce]

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.

Re: A ready to use Vulkan triangle example for D

[WhatMeWorry via Digitalmars-d-announce]

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.

A ready to use Vulkan triangle example for D

[maik klein via Digitalmars-d-announce]

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.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

Test worked, now supporting dub packages xcb-d, xlib-d, 
wayland-client-d.

Re: d-vulkan, automatically generated D bindings for Vulkan

[Alex Parrill via Digitalmars-d-announce]

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

https://github.com/ColonelThirtyTwo/dvulkan


I've updated the bindings to Vulkan 1.0.13, and added a few fixes.

Platform support will come in a bit. I'm going to use void* 
pointers for most of the platform-specific types, so you can use 
whatever bindings you want to use with them (whether they are 
full bindings or just one little opaque struct alias to use with, 
say, glfw).

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Friday, 20 May 2016 at 18:52:35 UTC, maik klein wrote:

On Thursday, 19 May 2016 at 15:44:27 UTC, ParticlePeter wrote:
I am a bit slow, how do I add xcb as a dependency?

/source/erupted/types.d(3335,16): Error: module xcb is in file 
'xcb/xcb.d' which cannot be read


Can I add dependencies for dependencies in dub?


This is WIP and should be resolved within this week. Do you want 
to use dub xcb-d, or do you have some other bindings?


In the former case I would need somebody to test the setup before 
I publish a new version, I don't have access to posix.


If you want to test, please add this configuration to erupted 
dub.json configurations (temporarily!), if it works I will add it:


{
"name"  :   "dub-platform-xcb",
"versions"  :   [ "VK_USE_PLATFORM_XCB_KHR" ],
"dependencies"  :   {
"xcb-d" : "~>2.1.0+1.11.1"
},

In your project dub.json add:

"subConfigurations" :   {
"erupted"   : "dub-platform-xcb",
},

This should add xcb-d dependencies to erupted.

In any case, feel free to open an issue at:
https://github.com/ParticlePeter/ErupteD

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[maik klein via Digitalmars-d]

On Thursday, 19 May 2016 at 15:44:27 UTC, ParticlePeter wrote:

On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:

[...]


As far as I understand Mike it is still possible. Suppose you 
build an engine based on (d-)vulkan/erupted, lets call it 
Turtle-Engine, you would also specify sub-configurations for 
xcb, xlib, win, ... and you could support any of 
(d-)vulkans/erupted sub-configs in your corresponding configs. 
When some dude (no sexual prejudice meant) wants to write a 
Turtle-App, which is based on your Turtle-Engine he decides how 
many of your configs representing platforms he would like to 
support. Now you see, as the language architect pointed out, 
its turtles all the way down.


I am a bit slow, how do I add xcb as a dependency?

/source/erupted/types.d(3335,16): Error: module xcb is in file 
'xcb/xcb.d' which cannot be read


Can I add dependencies for dependencies in dub?

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:

Am Wed, 18 May 2016 18:57:48 +
schrieb ParticlePeter <particlepe...@gmx.de>:


On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:
> On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König 
> wrote:
> 
>> I think I will use glfw3 later. I don't know if the 
>> original problem of using multiple configurations (xcb, 
>> xlib, glfw3, ...) is possible with only dub's internal 
>> logic. I tried putting this in my "vulkantest" packages' 
>> dub.json

>>
>> "subConfigurations":
>> {
>>"erupted": "with-derelict-loader",
>>"erupted": "normal"
>> }
>>
>> just for testing, and dub told me
>>
>> Could not resolve configuration for package vulkantest
>>
>> So I thinnk multiple subconfigurations are not supported.
>
> The way to handle this is to make multiple configurations of 
> vulkantest, one for each of the configurations of erupted 
> you want to support. Then, when you build vulkantest, you 
> specify the configuration you want to build on the command 
> line (unless you're building the default).


This is a good point, the custom project platform 
configuration would then be forwarded to erupted. Only 
drawback would be that "with-derelict-loader" config is not 
available in combination with a platform config, but in the 
later case you would want to grab vkGetInstanceProcAddr anyway 
in platform specific means.


Manuel, I could just skim over xcb-d. As far as I can see it 
has the module xcb.xcb. Is this module sufficient to be 
imported in erupted.types.d? In this case I would not have to 
touch the erupt.py generator but instead just fix the 
erupted.dub file. As you can test it, how about a pull request?




@ Peter: Yes, importing xcb.xcb is all you need, no patches 
necessary. But I could patch erupteD's dub.json for an xcb 
configuration, and maybe put in the readme how to use a 
configuration, but probably not until sunday.


@Mike: Having multiple subconfigurations (xcb, xlib, glfw3, 
...) to pick for the user is the solution Peter was going for, 
as I understood him. The problem is when a user wants to 
support both xcb and xlib, or any mix of them. But this is 
probably just a pathetic use case not relevant in practice, I 
just stumbled over the question if that is possible when I 
wanted to add proper xcb, xlib, etc. support to erupteD.


As far as I understand Mike it is still possible. Suppose you 
build an engine based on (d-)vulkan/erupted, lets call it 
Turtle-Engine, you would also specify sub-configurations for xcb, 
xlib, win, ... and you could support any of (d-)vulkans/erupted 
sub-configs in your corresponding configs. When some dude (no 
sexual prejudice meant) wants to write a Turtle-App, which is 
based on your Turtle-Engine he decides how many of your configs 
representing platforms he would like to support. Now you see, as 
the language architect pointed out, its turtles all the way down.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Thursday, 19 May 2016 at 00:09:42 UTC, Alex Parrill wrote:
Apparently GitHub didn't add my own repo to my list of watch 
repos, meaning no notifications for them...

I'll look over the pull request. Let's not split this project.


Depends on how far you want to catch up. Lets discuss this in the 
d-vulkan issues.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[Alex Parrill via Digitalmars-d]

On Monday, 16 May 2016 at 12:10:58 UTC, ParticlePeter wrote:

This is in respect to announce thread:
https://forum.dlang.org/post/mdpjqdkenrnuxvruw...@forum.dlang.org

Please let me know if you had the chance to test the 
functionality as requested in the announce thread.

All other question are welcome here as well of course.

Cheers, ParticlePeter


Apparently GitHub didn't add my own repo to my list of watch 
repos, meaning no notifications for them...


I'll look over the pull request. Let's not split this project.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[Manuel König via Digitalmars-d]

Am Wed, 18 May 2016 18:57:48 +
schrieb ParticlePeter :

> On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:
> > On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König wrote:
> >  
> >> I think I will use glfw3 later. I don't know if the original 
> >> problem of using multiple configurations (xcb, xlib, glfw3, 
> >> ...) is possible with only dub's internal logic. I tried 
> >> putting this in my "vulkantest" packages' dub.json
> >>
> >> "subConfigurations":
> >> {
> >>"erupted": "with-derelict-loader",
> >>"erupted": "normal"
> >> }
> >>
> >> just for testing, and dub told me
> >>
> >> Could not resolve configuration for package vulkantest
> >>
> >> So I thinnk multiple subconfigurations are not supported.  
> >
> > The way to handle this is to make multiple configurations of 
> > vulkantest, one for each of the configurations of erupted you 
> > want to support. Then, when you build vulkantest, you specify 
> > the configuration you want to build on the command line (unless 
> > you're building the default).  
> 
> This is a good point, the custom project platform configuration 
> would then be forwarded to erupted. Only drawback would be that 
> "with-derelict-loader" config is not available in combination 
> with a platform config, but in the later case you would want to 
> grab vkGetInstanceProcAddr anyway in platform specific means.
> 
> Manuel, I could just skim over xcb-d. As far as I can see it has 
> the module xcb.xcb. Is this module sufficient to be imported in 
> erupted.types.d? In this case I would not have to touch the 
> erupt.py generator but instead just fix the erupted.dub file. As 
> you can test it, how about a pull request?
> 

@ Peter: Yes, importing xcb.xcb is all you need, no patches necessary.
But I could patch erupteD's dub.json for an xcb configuration, and
maybe put in the readme how to use a configuration, but probably not
until sunday.

@Mike: Having multiple subconfigurations (xcb, xlib, glfw3, ...) to pick
for the user is the solution Peter was going for, as I understood him.
The problem is when a user wants to support both xcb and xlib, or any
mix of them. But this is probably just a pathetic use case not relevant
in practice, I just stumbled over the question if that is possible when
I wanted to add proper xcb, xlib, etc. support to erupteD.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote:

On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König wrote:

I think I will use glfw3 later. I don't know if the original 
problem of using multiple configurations (xcb, xlib, glfw3, 
...) is possible with only dub's internal logic. I tried 
putting this in my "vulkantest" packages' dub.json


"subConfigurations":
{
"erupted": "with-derelict-loader",
"erupted": "normal"
}

just for testing, and dub told me

Could not resolve configuration for package vulkantest

So I thinnk multiple subconfigurations are not supported.


The way to handle this is to make multiple configurations of 
vulkantest, one for each of the configurations of erupted you 
want to support. Then, when you build vulkantest, you specify 
the configuration you want to build on the command line (unless 
you're building the default).


This is a good point, the custom project platform configuration 
would then be forwarded to erupted. Only drawback would be that 
"with-derelict-loader" config is not available in combination 
with a platform config, but in the later case you would want to 
grab vkGetInstanceProcAddr anyway in platform specific means.


Manuel, I could just skim over xcb-d. As far as I can see it has 
the module xcb.xcb. Is this module sufficient to be imported in 
erupted.types.d? In this case I would not have to touch the 
erupt.py generator but instead just fix the erupted.dub file. As 
you can test it, how about a pull request?

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[Mike Parker via Digitalmars-d]

On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König wrote:

I think I will use glfw3 later. I don't know if the original 
problem of using multiple configurations (xcb, xlib, glfw3, 
...) is possible with only dub's internal logic. I tried 
putting this in my "vulkantest" packages' dub.json


"subConfigurations":
{
"erupted": "with-derelict-loader",
"erupted": "normal"
}

just for testing, and dub told me

Could not resolve configuration for package vulkantest

So I thinnk multiple subconfigurations are not supported.


The way to handle this is to make multiple configurations of 
vulkantest, one for each of the configurations of erupted you 
want to support. Then, when you build vulkantest, you specify the 
configuration you want to build on the command line (unless 
you're building the default).

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[Manuel König via Digitalmars-d]

On, 18 May 2016 04:51:10 +,
ParticlePeter  wrote:
> >
> > Sounds reasonable, picking a subconfig is definitely easier to 
> > use and implement. I was looking into that too, the only 
> > nitpicking I have is that it sounded like you can't select 
> > multiple subconfigurations. So for corner cases like having 
> > your app support xcb and xlib, a new subconfig has to be added. 
> > But I'll have to try that for myself.  
> 
> Actually that's a good point, I had also some trouble with this 
> behavior as well already. Do you have any suggestions to solve 
> that?
> One way would be using glfw3 or some other platform abstraction 
> layer and not using platform versions yourself.

I think I will use glfw3 later. I don't know if the original problem
of using multiple configurations (xcb, xlib, glfw3, ...) is possible
with only dub's internal logic. I tried putting this in my
"vulkantest" packages' dub.json

"subConfigurations":
{
"erupted": "with-derelict-loader",
"erupted": "normal"
}

just for testing, and dub told me

Could not resolve configuration for package vulkantest

So I thinnk multiple subconfigurations are not supported.
I think the options are
- add ability to dub to allow multiple subconfigurations
- tinker with dub's pre/postGenerateCommands, pre/postBuildCommands

But I think sticking with the simple one-config-per-backend solution
is enough. This is more a problem of finding the right balance of an
easy to use build tool, and having full control over the build process,
and should rather be discussed in a dub thread.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Tuesday, 17 May 2016 at 16:17:39 UTC, Manuel König wrote:


had to update the function loading names I chose differently.


This bugged me a little, v1.1.0 has the EruptedLoader struct 
removed so that the loading functions are called without 
EruptedLoader. prefix and can be renamed at import. This is a 
BERAKING CHANGE.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Tuesday, 17 May 2016 at 20:34:17 UTC, Manuel König wrote:
> What I want to do is to tell dub that erupted should depend 
> on xcb-d in my project's dub.json, is that possible?


I am not very confident with dub, but think that it would not 
work. Maybe you ask in the dub forum?


[...]

Another way would be, and I think I'll go for it, that I add 
dub

platform configurations. In your case it would be:
"subConfigurations": { "erupted": "dub_platform_xcb" }
which would add xcb-d as dependency and the relevant xcb-d
modules in erupted.types.d



Sounds reasonable, picking a subconfig is definitely easier to 
use and implement. I was looking into that too, the only 
nitpicking I have is that it sounded like you can't select 
multiple subconfigurations. So for corner cases like having 
your app support xcb and xlib, a new subconfig has to be added. 
But I'll have to try that for myself.


Actually that's a good point, I had also some trouble with this 
behavior as well already. Do you have any suggestions to solve 
that?
One way would be using glfw3 or some other platform abstraction 
layer and not using platform versions yourself.


On another note, while I like the creative package naming, it 
may not
be very easy for search engines to pick up or recognize by 
potential

users as vulkan bindings. The project is still new, but
gooogle and duckduckgo don't find erupteD when searching for 
"dlang
vulkan", but they do find derelict-vulkan, d-vulkan and 
vulkanizeD. I
hope I'm just overanalyzing, but I think having vulkan in the 
name
would be good. But I see that we're getting out of naming 
options

here...


I agree with all your arguments, in particular that last one :-) 
but I think as long as google and duckduck show that something is 
happening with vulkan in dland its O.K. Diving deeper and using 
dub package search for vulkan does list erupted. Additionally I 
asked vinjn/awesome-vulkan and jcoder58/VulkanResources to list 
erupted as d binding.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[Manuel König via Digitalmars-d]

> > What I want to do is to tell dub that erupted should depend on
> > xcb-d in my project's dub.json, is that possible?  
> 
> I am not very confident with dub, but think that it would not 
> work. Maybe you ask in the dub forum?
> 
> [...]
>
> Another way would be, and I think I'll go for it, that I add dub 
> platform configurations. In your case it would be:
> "subConfigurations": { "erupted": "dub_platform_xcb" }
> which would add xcb-d as dependency and the relevant xcb-d 
> modules in erupted.types.d
> 

Sounds reasonable, picking a subconfig is definitely easier to use and
implement. I was looking into that too, the only nitpicking I have is
that it sounded like you can't select multiple subconfigurations. So
for corner cases like having your app support xcb and xlib, a new
subconfig has to be added. But I'll have to try that for myself.

On another note, while I like the creative package naming, it may not
be very easy for search engines to pick up or recognize by potential
users as vulkan bindings. The project is still new, but
gooogle and duckduckgo don't find erupteD when searching for "dlang
vulkan", but they do find derelict-vulkan, d-vulkan and vulkanizeD. I
hope I'm just overanalyzing, but I think having vulkan in the name
would be good. But I see that we're getting out of naming options
here...

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

On Tuesday, 17 May 2016 at 16:17:39 UTC, Manuel König wrote:

Hi, Kalua here :)

First, thanks again for fixing vulkanizeD, now I don't have to 
use my locally patched version anymore ;)


Welcome :-)

Giving you some input for how your lib works on my posix sytem 
(arch

linux):

My simple triangle drawing program works with your lib, I only 
had to update the function loading names I chose differently.


That's nice to hear!

But I had to modify erupteD's dub.json to depend on xcb (dub 
package xcb-d), because simply putting the xcb dependency in my 
project's dub.json was not enough. But this should only be a 
workaround, because not everyone uses/can use xcb, or they may 
even want to use different xcb bindings.


That's right, but if the platform modules are available as dub 
packages they should be supported somehow.



What I want to do is to tell dub that erupted should depend on
xcb-d in my project's dub.json, is that possible?


I am not very confident with dub, but think that it would not 
work. Maybe you ask in the dub forum?


But I have one idea which might work:
Create a module xcb.xcb.d yourself and publicly import all 
required sources from xcb-d into it. In your triangle vulkan 
project add the path to xcb.xcb.d and xcb-d to "sourcePaths" and 
"importPaths". Erupted might pick it up.


Another way would be, and I think I'll go for it, that I add dub 
platform configurations. In your case it would be:

"subConfigurations": { "erupted": "dub_platform_xcb" }
which would add xcb-d as dependency and the relevant xcb-d 
modules in erupted.types.d

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[Andrej Mitrovic via Digitalmars-d]

On Monday, 16 May 2016 at 12:10:58 UTC, ParticlePeter wrote:

This is in respect to announce thread:
https://forum.dlang.org/post/mdpjqdkenrnuxvruw...@forum.dlang.org

Please let me know if you had the chance to test the 
functionality as requested in the announce thread.

All other question are welcome here as well of course.

Cheers, ParticlePeter


Cool stuff! I think I'll try this out soon on Posix. My Nvidia 
driver should in theory support Vulkan already.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

[Manuel König via Digitalmars-d]

Hi, Kalua here :)

First, thanks again for fixing vulkanizeD, now I don't have to use my
locally patched version anymore ;)

Giving you some input for how your lib works on my posix sytem (arch
linux):

My simple triangle drawing program works with your lib, I only had to
update the function loading names I chose differently.

But I had to modify erupteD's dub.json to depend on xcb (dub package
xcb-d), because simply putting the xcb dependency in my project's
dub.json was not enough. But this should only be a workaround, because
not everyone uses/can use xcb, or they may even want to use different
xcb bindings.

What I want to do is to tell dub that erupted should depend on
xcb-d in my project's dub.json, is that possible?

Discuss vulkan erupted, the other auto-generated vulkan binding

[ParticlePeter via Digitalmars-d]

This is in respect to announce thread:
https://forum.dlang.org/post/mdpjqdkenrnuxvruw...@forum.dlang.org

Please let me know if you had the chance to test the 
functionality as requested in the announce thread.

All other question are welcome here as well of course.

Cheers, ParticlePeter

Re: Anonther auto-generated vulkan binding

[ParticlePeter via Digitalmars-d-announce]

Please discuss here:
https://forum.dlang.org/post/mclrqnwwrhmbxumgj...@forum.dlang.org

Anonther auto-generated vulkan binding

[ParticlePeter via Digitalmars-d-announce]

ErupteD is based on D-Vulkan, but goes further:
* Platform surface extensions
* DerelictLoader for Posix Systems
* With respect to [API without 
Secrets](https://software.intel.com/en-us/api-without-secrets-introduction-to-vulkan-part-1) D-Vulkan function loading system is partially broken


https://code.dlang.org/packages/erupted

Why another project?
I did submit pull requests to D-Vulkan, but so far they are 
ignored. However I feel that my edits add value to the bindings.


ErupteD is only partially tested, as I don't have:
1.) any posix system available (or android for that matter)
2.) A Multi-Vulkan-Device System (e.g. APU and GPU)

For the interested reader:
1.) When presenting content to a window vulkan relies on platform 
specific sources (or some other platform independent mechanism, 
e.g. glfw3). In case of windows these sources can be found in 
phobos, but I don't know where to find and how to supply them in 
the other cases (posix and android). Hence I just used the same 
names found in the vk_platform.h file for imports (more details 
in the README.md). Please inform me if those imports point to the 
right modules paths, if any.


2.) Vulkan functions can be loaded in two ways, a) through the 
instance and b) through the logical device. Former gets all 
functions for all found devices, but when calling them they will 
be internally dispatched to the proper device. Later gets the 
functions for one device, these functions don't have the dispatch 
indirection. In theory, loading the functions a second time for a 
different logical device should overwrite the functions of the 
previously loaded device functions, but as I don't have a 
multi-device system I can't be sure. It would be nice if anybody 
could test this functionality (again more details in the 
README.md) with the supplied devices.d example.


I will open up a discussion thread for that.

Cheers, ParticlePeter

Re: d-vulkan, automatically generated D bindings for Vulkan

[Manuel Maier via Digitalmars-d-announce]

On Monday, 21 March 2016 at 09:27:35 UTC, Manuel Maier wrote:

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

https://github.com/ColonelThirtyTwo/dvulkan

[...]


@Alex Parrill: Thanks for sharing! Looks nice. I was just 
wondering... why did you write the generator in python and not 
in D? Just curious :)


I see now... The Vulkan docs provide python modules for easier 
integration already. Makes sense.

Re: d-vulkan, automatically generated D bindings for Vulkan

[Manuel Maier via Digitalmars-d-announce]

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

https://github.com/ColonelThirtyTwo/dvulkan

[...]


@Alex Parrill: Thanks for sharing! Looks nice. I was just 
wondering... why did you write the generator in python and not in 
D? Just curious :)

Re: d-vulkan, automatically generated D bindings for Vulkan

[burjui via Digitalmars-d-announce]

On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote:

If I import a xcb_connection_t from some bindings,
it ties d-vulkan to those bindings, which I'd rather not do.


By the magic of D:

version (Linux)
{
import xcb.xcb;
}

...

version (Linux)
{
xcb_connection_t* con;
}

Also you can make xcb-d dependency optional in DUB.

d-vulkan, automatically generated D bindings for Vulkan

[Alex Parrill via Digitalmars-d-announce]

https://github.com/ColonelThirtyTwo/dvulkan

I know there are a few other bindings for Vulkan around, but I 
didn't see one that generated the bindings from the XML spec, so 
I made d-vulkan. The included vkdgen.py script leverages the spec 
parser included in the Vulkan-Docs repo to generate D bindings 
that can easily be updated with new versions and extensions.


The bindings load all functions using the vkGetInstanceProcAddr 
function; however, it does not provide any way of loading that 
function by default, and you must provide it when loading Vulkan. 
The `with-derelict-loader` dub configuration provides uses 
derelict.util to load the vkGetInstanceProcAddr function, and 
I've added a wiki page demonstrating loading the function using 
GLFW.


This includes bindings for all extensions, except for the 
platform-dependent VK_KHR_*_surface APIs, which require type 
declarations from other projects (like X11) that I didn't want to 
include. The platform-independent VK_KHR_surface extension is 
available, however.


(Currently the Derelict loader only works in Windows because I 
don't know the library names for Vulkan on Linux or OSX; if 
anyone knows them, please tell me, and I'll add them)

Re: d-vulkan, automatically generated D bindings for Vulkan

[Nicholas Wilson via Digitalmars-d-announce]

On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote:


If I import a xcb_connection_t from
some bindings, it ties d-vulkan to those bindings, which I'd 
rather not do.


really? It would be a 1 line change. Or alternatively tell the 
user to import

their own bindings.

Re: d-vulkan, automatically generated D bindings for Vulkan

[Alex Parrill via Digitalmars-d-announce]

On Sunday, 20 March 2016 at 00:03:16 UTC, Nicholas Wilson wrote:

On Saturday, 19 March 2016 at 19:37:38 UTC, Alex Parrill wrote:
On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson 
wrote:
On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill 
wrote:


Should be doable using appropriate version blocks.



The problem is that I'd have to define my own structs (Xlib 
Display, Xlib Window, etc), which will be incompatible with 
the ones defined in any bindings to those libraries.


You don't. Code in undefined versions need only be 
syntactically valid
not semantically valid. i.e. the types in versions not compiled 
in need not

be declared nor defined.

version(none)
{
xcb_connection_t* con;
}
 will compile fine.


Yes, I know. The issue is, when compiling with the version, where 
does xcb_connection_t come from? If I declare it myself, as 
`struct xcb_connection_t;` in the version block, then that type 
will be different than the xcb_connection_t declared in the XCB 
bindings that the developer is likely using, and thus they will 
be incompatible. If I import a xcb_connection_t from some 
bindings, it ties d-vulkan to those bindings, which I'd rather 
not do.

Re: d-vulkan, automatically generated D bindings for Vulkan

[Nicholas Wilson via Digitalmars-d-announce]

On Saturday, 19 March 2016 at 19:37:38 UTC, Alex Parrill wrote:
On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson 
wrote:

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

Should be doable using appropriate version blocks.



The problem is that I'd have to define my own structs (Xlib 
Display, Xlib Window, etc), which will be incompatible with the 
ones defined in any bindings to those libraries.


You don't. Code in undefined versions need only be syntactically 
valid
not semantically valid. i.e. the types in versions not compiled 
in need not

be declared nor defined.

version(none)
{
xcb_connection_t* con;
}
 will compile fine.

Re: d-vulkan, automatically generated D bindings for Vulkan

[Alex Parrill via Digitalmars-d-announce]

On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson wrote:

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

Should be doable using appropriate version blocks.



The problem is that I'd have to define my own structs (Xlib 
Display, Xlib Window, etc), which will be incompatible with the 
ones defined in any bindings to those libraries.

Re: d-vulkan, automatically generated D bindings for Vulkan

[Jacob Carlborg via Digitalmars-d-announce]

On 19/03/16 13:57, Nicholas Wilson wrote:


Afaik OSX doesn't support vulkan, due to Apple's metal.


Seems someone is creating a Vulkan wrapper around Metal: 
https://moltengl.com/moltenvk/


--
/Jacob Carlborg

Re: d-vulkan, automatically generated D bindings for Vulkan

[Nicholas Wilson via Digitalmars-d-announce]

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:

https://github.com/ColonelThirtyTwo/dvulkan

This includes bindings for all extensions, except for the 
platform-dependent VK_KHR_*_surface APIs, which require type 
declarations from other projects (like X11) that I didn't want 
to include. The platform-independent VK_KHR_surface extension 
is available, however.




Should be doable using appropriate version blocks.

(Currently the Derelict loader only works in Windows because I 
don't know the library names for Vulkan on Linux or OSX; if 
anyone knows them, please tell me, and I'll add them)


Afaik OSX doesn't support vulkan, due to Apple's metal.

Re: d-vulkan, automatically generated D bindings for Vulkan

[Johannes Pfau via Digitalmars-d-announce]

Am Sat, 19 Mar 2016 01:12:08 +
schrieb Alex Parrill <initrd...@gmail.com>:

> https://github.com/ColonelThirtyTwo/dvulkan
> [...]
> 
> (Currently the Derelict loader only works in Windows because I 
> don't know the library names for Vulkan on Linux or OSX; if 
> anyone knows them, please tell me, and I'll add them)

For Archlinux:

usr/lib/libvulkan.so
usr/lib/libvulkan.so.1
usr/lib/libvulkan.so.1.0.5

(see https://www.archlinux.org/packages/extra/x86_64/vulkan-icd-loader/
and maybe https://www.archlinux.org/packages/extra/x86_64/vulkan-intel/
and click on "View the file list" on the bottom of the page)

Re: D Vulkan API

[karabuta via Digitalmars-d]

On Tuesday, 1 March 2016 at 11:33:26 UTC, Nicholas Wilson wrote:
So i've spent the last few days making more D feeling bindings 
for vulkan, based off Satoshi's because going strait  from the 
spec was a PITA and very inconsistent, and they're almost done.


I would like to request some feedback on the code itself as 
well as the generated code and general feel of the interface 
for a an article/blog post on meta-programming and text 
processing in D. (I know I should replace most of those c-style 
for loops with join(er),but some of the ones dealing with 
arrays are quite complicated, and I really ought to factor out 
a lot of code). Also I just realised that all the extension 
functions will have to be called through obtained function 
pointers.




Just one non-technical thing, the module naming does not follow 
the D style. This is common is some few projects and makes things 
inconsistent :)


*** Modules
Module and package names should be all lowercase, and only 
contain the characters [a..z][0..9][_]. This avoids problems when 
dealing with case-insensitive file systems. ***




Code: http://dpaste.dzfl.pl/3146cdf9d382
outputted code http://dpaste.dzfl.pl/811796605755
Satoshi's bindings: 
https://github.com/Rikarin/VulkanizeD/blob/master/Vulkan.d


Nic