Re: Discuss vulkan erupted, the other auto-generated vulkan binding
Test worked, now supporting dub packages xcb-d, xlib-d, wayland-client-d.
Re: Discuss vulkan erupted, the other auto-generated vulkan binding
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
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
On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote:
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.
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
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
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
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
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
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
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
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
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
> > 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
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
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
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
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
