www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Discuss vulkan erupted, the other auto-generated vulkan binding

reply ParticlePeter <ParticlePeter gmx.de> writes:
This is in respect to announce thread:
https://forum.dlang.org/post/mdpjqdkenrnuxvruwoqs 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
May 16 2016
next sibling parent reply Manuel =?UTF-8?B?S8O2bmln?= <manuelk89 gmx.net> writes:
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?
May 17 2016
next sibling parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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
May 17 2016
parent reply Manuel =?UTF-8?B?S8O2bmln?= <manuelk89 gmx.net> writes:
 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...
May 17 2016
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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.
May 17 2016
parent reply Manuel =?UTF-8?B?S8O2bmln?= <manuelk89 gmx.net> writes:
On, 18 May 2016 04:51:10 +0000,
ParticlePeter <ParticlePeter gmx.de> 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.
May 18 2016
parent reply Mike Parker <aldacron gmail.com> writes:
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).
May 18 2016
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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?
May 18 2016
parent reply Manuel =?UTF-8?B?S8O2bmln?= <manuelk89 gmx.net> writes:
Am Wed, 18 May 2016 18:57:48 +0000
schrieb ParticlePeter <ParticlePeter 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=C3=B6nig wrote:
 =20

 I think I will use glfw3 later. I don't know if the original=20
 problem of using multiple configurations (xcb, xlib, glfw3,=20
 ...) is possible with only dub's internal logic. I tried=20
 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. =20


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


=20
 This is a good point, the custom project platform configuration=20
 would then be forwarded to erupted. Only drawback would be that=20
 "with-derelict-loader" config is not available in combination=20
 with a platform config, but in the later case you would want to=20
 grab vkGetInstanceProcAddr anyway in platform specific means.
=20
 Manuel, I could just skim over xcb-d. As far as I can see it has=20
 the module xcb.xcb. Is this module sufficient to be imported in=20
 erupted.types.d? In this case I would not have to touch the=20
 erupt.py generator but instead just fix the erupted.dub file. As=20
 you can test it, how about a pull request?
=20


  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.
May 18 2016
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:

 Am Wed, 18 May 2016 18:57:48 +0000
 schrieb ParticlePeter <ParticlePeter 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.
May 19 2016
parent reply maik klein <maikklein googlemail.com> writes:
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?
May 20 2016
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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
May 21 2016
parent ParticlePeter <ParticlePeter gmx.de> writes:
Test worked, now supporting dub packages xcb-d, xlib-d, 
wayland-client-d.
May 21 2016
prev sibling parent ParticlePeter <ParticlePeter gmx.de> writes:
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.
May 17 2016
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On Monday, 16 May 2016 at 12:10:58 UTC, ParticlePeter wrote:

 This is in respect to announce thread:
 https://forum.dlang.org/post/mdpjqdkenrnuxvruwoqs 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.
May 17 2016
prev sibling parent reply Alex Parrill <initrd.gz gmail.com> writes:
On Monday, 16 May 2016 at 12:10:58 UTC, ParticlePeter wrote:

 This is in respect to announce thread:
 https://forum.dlang.org/post/mdpjqdkenrnuxvruwoqs 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.
May 18 2016
parent ParticlePeter <ParticlePeter gmx.de> writes:
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.
May 19 2016