Re: Vulkan
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
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
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
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
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
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
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
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
On 13/02/2018 10:54 PM, Danni Coy wrote: On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d 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
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
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
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
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
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
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: 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
Re: D Vulkan API
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
D Vulkan API
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. I think i've covered most of the functions but if there are any that I have missed please tell me. Many thanks to Adam and others for answering my questions so one more. Is it possible to get Fields/Parameters to return aliased types? Because currently all the flags are uints not e.g. ImageCreateFlags.(This would enable the removal of a very large amount of hackery) 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
Re: Vulkan bindings
On Wednesday, 24 February 2016 at 12:45:13 UTC, Nicholas Wilson wrote: On Thursday, 18 February 2016 at 04:11:39 UTC, ZombineDev wrote: [...] Hey I've started work on a more D like vulkan http://dpaste.dzfl.pl/1ecfa367b966 I switched to adapting Satoshi bindings (I gave up on trying to gen it from the xml too much like hard work Way too many inconsistencies ) If you have any further ideas for improvements let me know! (I think a tool to autogen the descriptor layouts would be awesome But that will take a while and Uni starts soon so I probably won't have time) Nic Did you look into adapting VkCppGenerator for the task? https://github.com/nvpro-pipeline/vkcpp
Re: Vulkan bindings
On Thursday, 18 February 2016 at 04:11:39 UTC, ZombineDev wrote: On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote: [...] I started working on that. I've been reading the Python C Header generator code and I'm wondering if would be easier to just re-implement it in D, rather than trying to extend it. Currently the XML is very C oriented (e.g. has C macros in it), unlike the OpenGL spec which was written in a language agnostic way. The advantages of using the vk.xml is that once the generator is complete you can easily adapt it for newer revisions of the spec. Also you have much more freedom in how you can organize the bindings (split by functions/structs/enums or logically by e.g. instance, device, command recording, queues, synchronization, shaders, pipelines, etc.), also it's easier to do other stuff like using D's builtin types instead of cstdint, generating ddoc-formatted function/struct/enum documentation and also ddoc-ed unittests from the spec examples. And maybe also provide two versions - one with vanilla names (easier if you are following tutorials) and one that's written in D style (http://dlang.org/dstyle.html) for those who prefer a more uniform syntax with the rest of the other D libraries out there. I have completed the SPIR-V D header (which was trivial to generate from the .json file) and I'm also hoping to translate the other stuff from the LunarG SDK like the debug layers (no auto-generation would be possible there). Given the advancements in the recent years of the D ecosystem (dub, high quality doc generators, CT generation of boilerplate, etc.), I think that D can offer even better developer experience than C++ for which the API was primary targeted. Hey I've started work on a more D like vulkan http://dpaste.dzfl.pl/1ecfa367b966 I switched to adapting Satoshi bindings (I gave up on trying to gen it from the xml too much like hard work Way too many inconsistencies ) If you have any further ideas for improvements let me know! (I think a tool to autogen the descriptor layouts would be awesome But that will take a while and Uni starts soon so I probably won't have time) Nic
Re: Vulkan bindings
On Saturday, 20 February 2016 at 07:59:13 UTC, ParticlePeter wrote: On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! I think your usage of const pointer is wrong. E.g. c const char* maps to d const(char)* etc. Thanks, I just fixed it.
Re: Vulkan bindings
On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! I think your usage of const pointer is wrong. E.g. c const char* maps to d const(char)* etc.
Re: Vulkan bindings
On Friday, 19 February 2016 at 01:49:12 UTC, Alex Parrill wrote: On Thursday, 18 February 2016 at 03:39:30 UTC, Kapps wrote: On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote: This is what I did with OpenGL for my own bindings. It had some nice benefits like having the documentation be (mostly) accessible. Unfortunately, turns out the spec contains a lot of typos, including wrong arguments / function names. And I should clarify, ahead of time to generate a .d file, not at compile-time. :P Yea, by "directly", I meant using D templates and CTFE, not a script that generates a D file. For my own project, since I just need the function names, I'm using a Python script to generate a CSV file from the OpenGL spec, then importing/parsing that with D. It's neat, but slows down the build a lot. I haven't had any issues with typos, though. What about all the other layers (currently) found in the LunarG SDK? Without them its just toying around with Vulkan. Porting them manually seems a lot of work, how can this be tackled automatically?
Re: Vulkan bindings
On Thursday, 18 February 2016 at 03:39:30 UTC, Kapps wrote: On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote: This is what I did with OpenGL for my own bindings. It had some nice benefits like having the documentation be (mostly) accessible. Unfortunately, turns out the spec contains a lot of typos, including wrong arguments / function names. And I should clarify, ahead of time to generate a .d file, not at compile-time. :P Yea, by "directly", I meant using D templates and CTFE, not a script that generates a D file. For my own project, since I just need the function names, I'm using a Python script to generate a CSV file from the OpenGL spec, then importing/parsing that with D. It's neat, but slows down the build a lot. I haven't had any issues with typos, though.
Re: Vulkan bindings
On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote: (IMO It would be cool to generate OpenGL and Vulkan bindings directly from the XML spec; std.xml doesn't work in CTFE. Though it would probably take a long time to compile) https://github.com/Dav1dde/glad
Re: Vulkan bindings
On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote: On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! Please consider making it a Dub package! (IMO It would be cool to generate OpenGL and Vulkan bindings directly from the XML spec; std.xml doesn't work in CTFE. Though it would probably take a long time to compile) I started working on that. I've been reading the Python C Header generator code and I'm wondering if would be easier to just re-implement it in D, rather than trying to extend it. Currently the XML is very C oriented (e.g. has C macros in it), unlike the OpenGL spec which was written in a language agnostic way. The advantages of using the vk.xml is that once the generator is complete you can easily adapt it for newer revisions of the spec. Also you have much more freedom in how you can organize the bindings (split by functions/structs/enums or logically by e.g. instance, device, command recording, queues, synchronization, shaders, pipelines, etc.), also it's easier to do other stuff like using D's builtin types instead of cstdint, generating ddoc-formatted function/struct/enum documentation and also ddoc-ed unittests from the spec examples. And maybe also provide two versions - one with vanilla names (easier if you are following tutorials) and one that's written in D style (http://dlang.org/dstyle.html) for those who prefer a more uniform syntax with the rest of the other D libraries out there. I have completed the SPIR-V D header (which was trivial to generate from the .json file) and I'm also hoping to translate the other stuff from the LunarG SDK like the debug layers (no auto-generation would be possible there). Given the advancements in the recent years of the D ecosystem (dub, high quality doc generators, CT generation of boilerplate, etc.), I think that D can offer even better developer experience than C++ for which the API was primary targeted.
Re: Vulkan bindings
On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote: This is what I did with OpenGL for my own bindings. It had some nice benefits like having the documentation be (mostly) accessible. Unfortunately, turns out the spec contains a lot of typos, including wrong arguments / function names. And I should clarify, ahead of time to generate a .d file, not at compile-time. :P
Re: Vulkan bindings
On Thursday, 18 February 2016 at 03:27:55 UTC, Alex Parrill wrote: On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! Please consider making it a Dub package! (IMO It would be cool to generate OpenGL and Vulkan bindings directly from the XML spec; std.xml doesn't work in CTFE. Though it would probably take a long time to compile) This is what I did with OpenGL for my own bindings. It had some nice benefits like having the documentation be (mostly) accessible. Unfortunately, turns out the spec contains a lot of typos, including wrong arguments / function names.
Re: Vulkan bindings
On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! Please consider making it a Dub package! (IMO It would be cool to generate OpenGL and Vulkan bindings directly from the XML spec; std.xml doesn't work in CTFE. Though it would probably take a long time to compile)
Re: OT: Vulkan released
Le 17/02/2016 12:54, Vladimir Panteleev a écrit : On Tuesday, 16 February 2016 at 21:27:22 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 16 February 2016 at 19:03:13 UTC, Zoadian wrote: I'll write derelict bindings. 600 lines of code to display a triangle... I found this: https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig Lol I am in case where vulkan could help for my day job. But we are following Qt3D module that can help us for a lot of other issue with our current 3D engine. Qt3D will support vulkan as backend.
Re: OT: Vulkan released
On Wednesday, 17 February 2016 at 11:54:22 UTC, Vladimir Panteleev wrote: I found this: https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig Yes, Vulkan seems to be more suited for building a generic engine than a small scale application.
Re: Vulkan bindings
On Wednesday, 17 February 2016 at 10:55:22 UTC, Rikki Cattermole wrote: On 17/02/16 8:01 AM, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! Btw you removed Khronos header/license declaration. I'm copying back the original to my variation of these bindings. Fixed.
Re: OT: Vulkan released
On Tuesday, 16 February 2016 at 21:27:22 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 16 February 2016 at 19:03:13 UTC, Zoadian wrote: I'll write derelict bindings. 600 lines of code to display a triangle... I found this: https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig
Re: OT: Vulkan released
On Tuesday, 16 February 2016 at 19:05:03 UTC, Rikki Cattermole wrote: On 17/02/16 8:03 AM, Zoadian wrote: On Tuesday, 16 February 2016 at 14:20:51 UTC, Ola Fosheim I'll write derelict bindings. I'll steal it once you've done that for alphaPhobos :) Maybe even get Windows context creation made within a few weeks (depends on when I get a new GPU). I could test It when i update my GPU drivers
Re: Vulkan bindings
On 17/02/16 8:01 AM, Satoshi wrote: Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun! Btw you removed Khronos header/license declaration. I'm copying back the original to my variation of these bindings.
Re: OT: Vulkan released
On Tuesday, 16 February 2016 at 19:03:13 UTC, Zoadian wrote: I'll write derelict bindings. 600 lines of code to display a triangle... This is crying for toolkits. I guess they will emerge on github soon.
Re: OT: Vulkan released
On 17/02/16 8:03 AM, Zoadian wrote: On Tuesday, 16 February 2016 at 14:20:51 UTC, Ola Fosheim Grøstad wrote: https://www.khronos.org/vulkan/ OS-X Metal is kinda like a C++ derivative => GPU compilation. With Vulkan/SPIR other languages should be able to come up with something similar for other platforms. finally. I'll write derelict bindings. I'll steal it once you've done that for alphaPhobos :) Maybe even get Windows context creation made within a few weeks (depends on when I get a new GPU).
Re: OT: Vulkan released
On Tuesday, 16 February 2016 at 14:20:51 UTC, Ola Fosheim Grøstad wrote: https://www.khronos.org/vulkan/ OS-X Metal is kinda like a C++ derivative => GPU compilation. With Vulkan/SPIR other languages should be able to come up with something similar for other platforms. finally. I'll write derelict bindings.
Vulkan bindings
Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun!
Re: OT: Vulkan released
Thanks for the info.
OT: Vulkan released
https://www.khronos.org/vulkan/ OS-X Metal is kinda like a C++ derivative => GPU compilation. With Vulkan/SPIR other languages should be able to come up with something similar for other platforms.
Re: Did D will try to get the vulkan opportunity?
On Wednesday, 25 March 2015 at 18:46:51 UTC, bioinfornatics wrote:
Dear,
I would like to know if D dev have a plan with vulkan :
https://www.khronos.org/vulkan/ ?
D lang will be at same level than others language, nothing
exists !
D could try to provide API and an environment around vulkan. To
become a language "need to be used" in this field.
Regards
I'm not one of the D devs, but I'm working on a lib that builds
shaders from composable templates (in a very pre-alpha stage
still, but this is a tough thing to get right).
I was going to do GPGPU through openGL compute shaders, but as
soon as there are actual details on the Vulkan API, I will
probably go after that instead.
Maybe not what you were looking for, but if it works out, D will
be the only language that I know of with something like this.
What I mean by "composable templates":
alias affine_transform = vertex_shader!(
`translation`, `rotation`, `scale`, q{
gl_Position.x = gl_Position.x * cos (rotation) -
gl_Position.y * sin (rotation);
gl_Position.y = gl_Position.x * sin (rotation) +
gl_Position.y * cos (rotation);
gl_Position.xy *= scale;
gl_Position.xy += translation;
}
);
and basically you tack stuff like that together using UFCS,
auto boxes = Lifetime.Shared!Texture (resolution)
.fill (transparent);
auto sq = square (1f).VertexBuffer;
borrow (sq).basic_shader (green (0.5))
.affine_transform (fvec (0, 0), 0,
(resolution[1]*1.5f/resolution[0])*vector (1f, 1f/3))
.line_loop.render_to (boxes);
and once you attach the shader to a canvas, it'll deduce the
argument types, generate the rest of the shader code, compile,
link, upload uniforms and attributes, and save the shader in a
global AA for recall in case you're visiting it in a loop. It's
designed to be as much like calling r.map!(x => ...) and friends
as possible; functional programming with the GPU.
Still working out how to get it to play nicely with compute
shaders (IO works differently than for regular shaders) but maybe
the Vulkan spec will reveal an easier way to unify them.
So, there you go; someday, it could be D's own ArrayFire +
graphics (with a good bit more work).
I've been incubating it as a private repo since its still so raw,
and I don't want to unveil before its ready and have it get a
reputation as being half-baked, but if there's legitimate
interest from people who have a good idea of what they would like
to see from a graphics/compute API of this nature, I can open it
up publicly. Or I can send invites, if anyone wants to help
incubate it by tossing use-cases my way, I'll gladly take them
and do my best to build this thing out to meet the needs.
Re: Did D will try to get the vulkan opportunity?
On Wednesday, 25 March 2015 at 18:46:51 UTC, bioinfornatics wrote:
Dear,
I would like to know if D dev have a plan with vulkan :
https://www.khronos.org/vulkan/ ?
D lang will be at same level than others language, nothing
exists !
D could try to provide API and an environment around vulkan. To
become a language "need to be used" in this field.
Regards
I'm very excited about the movement in the graphics API space to
provide a better abstraction over the modern GPUs.
I was planning to make a Mantle binding when the SDK was to be
released (because it would be at least 90% the same as Vulkan,
minus the SPIR-V), and I also wanted to get my hands dirty
earlier), but unfortunately AMD announced that they will be
releasing only the spec.
Well they've now released[1] the spec and I couldn't resist
reading it.
I was very (pleasantly) surprised with how little AMD specific
stuff it has in it. Actually it is divided into core Mantle and
AMD extentions and the core part is pretty generic because it has
to support different GPUs, different OSes and different driver
versions. For example you need to query the API at runtime for
the size of the objects, their alignment requirements, their
preferred placement in one of the (possibly several) memory heaps
and so on. At the initialization of the API you can provide your
custom allocation and deallocation functions.
Since it is pure C API the obvious things that a D binding can do
better are:
+ use slices were the API expects a pointer and size
+ functions like grGetObjectInfo[2] can be templated on the
GR_INFO_TYPE enum, so you won't have to manually provide the
value of pDataSize and and the D binding will automatically
assert/enforce that pDataSize bytes has been written.
+ various other CTFE automation of the quite verbose C API.
+ overall the API is UFCS friendly - for example [3] can be
written in D as [4].
+ the one thing that can be potentially higher impact is to able
to compile D code to SPIR-V (maybe doable via CTFE DSL, but it
probably better if we can use the LLVM or GCC backends). There is
a C++14 subset that you can use in OpenCl 2.1 C++. We can do
probably something similar with D.
The moment a working Vulkan SDK is released I will try to make a
D binding. I expect that other people from the D community are
also interested in this, so you can sure there will be at least a
DerelictVulkan ;)
[1]:
http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/mantle#downloads
[2]: GR_RESULT grGetObjectInfo(
GR_BASE_OBJECT object,
GR_ENUM infoType,
GR_SIZE* pDataSize,
GR_VOID* pData);
[3]:
// This is C code
#include //mantle or vulkan
result = grCreateCommandBuffer(device, &cmdBufInfo, &cmdBuffer);
// Start building command buffer, optimize fo single time
submittion
result = grBeginCommandBuffer(
cmdBuffer,
GR_CMD_BUFFER_OPTIMIZE_ONE_TIME_SUBMIT);
// Record command buffer commands
grCmdSetEvent(cmdBuffer, event);
// Finish recording
grEndCommandBuffer(cmdBuffer);
[4]:
// This is D code
import gr; // this our Mantle or Vulkan wrapper module
// Return a new CmdBuffer instance by value, since it is
(probably)
// not much larger than a handle.
// Pass a CmdBufInfo by ref, or expand the members
// of the struct as parameters to
// device "method" (in semi-OOP terminology).
// The wrapper function asserts that the GR_RESULT is GR_SUCCESS
// since it is probably a logic error that we have provided
// invalid arguments, and we are not Go fanboys obsessed with
// checking error codes :-D
auto cmdBuffer = device.createCommandBuffer(cmdBufInfo);
// The rest is UFCS + scope statement + style
// changes (to make it more friendly-looking).
{
cmdBuffer.beginRecording(CmdBufUsage.oneTimeSubmit);
scope(exit) cmdBuffer.endRecording();
cmdBuffer.setEvent(event);
}
Did D will try to get the vulkan opportunity?
Dear, I would like to know if D dev have a plan with vulkan : https://www.khronos.org/vulkan/ ? D lang will be at same level than others language, nothing exists ! D could try to provide API and an environment around vulkan. To become a language "need to be used" in this field. Regards
Re: Targeting Vulkan and SPIR-V
On Friday, 13 March 2015 at 18:44:18 UTC, karl wrote: Spir-V may be producable from HLL tools, but that doesn't mean it's perfectly ok to use any HLL. Capability for HLL-to-spir is exposed mainly for syntax sugar and shallow precompile optimisations, but mostly to avoid vendor-specific HLL bugs that have plagued GLSL and HLSL (those billion d3dx_1503.dll on your system are bugfixes). Plus, to give the community access to one or several opensource HLL compilers that they can find issues with and submit for everyone to benefit. So, it's mostly to get a flawless opensource GLSL compiler. Dlang's strengths are simply not applicable directly. Though with a bit of work can actually be applied completely. (I've done them in/with our GLSL/backend compilers) - malloc. SpirV and such don't have malloc. Fix: Preallocate a big chunk of memory, and implement a massively-parallel allocator yourself (it should handle ~2000 requests to allocate per cycle, that's the gist of it). "atomic_add" on a memory location will help. If you don't want to preallocate too much, have a cpu thread poll while a gpu thread stalls (it should stall itself and 6 other threads) until the cpu allocates a new chunk for the heap and provides a base address. (hope the cpu thread responds quickly enough, or your gpu tasks will be mercilessly killed). - function-pointers, largely a no-no. Extensions might give you that capability, but implement as big switch-case tables. With the extensions, you will need to guarantee an arbitrary number (64) of threads all happened to call the same actual function. - stack. I don't know how to break it to you, there's no stack. Only around 256 dwords, that 8-200 threads get to allocate from. Your notion of a stack gets statically flattenized by the compilers. So, your whole program has e.g. 4 dwords to play around and have 64 things hide latency, or 64 dwords but only 4 threads to hide latency - and is 2-4x slower for rudimentary things (and utterly fail at latency hiding, becoming 50 times slower with memory-accesses), or 1 thread with 256 dwords, which is 8-16 times slower at rudimentary stuff and 50+ times slower if you access memory even if cached. Add a manually-managed programmable memory-stack, and your performance goes poof. - exceptions. A combined issue of the things above. Combine the limitations of function-pointers and stack, and I hope you get the point. Or well, how pointless the exercise to get Dlang as we know and love it on a gpu. A single-threaded javascript app on a cpu will beat it at performance on everything that's not trivial. The reason to use D for kernels / shaders would be for its metaprogramming, code-generation abilities and type-system (slices and structs in particular). Of course you wouldn't be allocating heap memory, using function pointers or exceptions. There's a still a lot that D has to offer without those. I regularly write thousands of lines of D in that subset. P.S. D is in pretty much the same boat as any other C-based language w.r.t. stack space. You have to be careful with the stack in OpenCL C, you would have to be careful with the stack in SPIR-D.
Re: Targeting Vulkan and SPIR-V
Spir-V may be producable from HLL tools, but that doesn't mean it's perfectly ok to use any HLL. Capability for HLL-to-spir is exposed mainly for syntax sugar and shallow precompile optimisations, but mostly to avoid vendor-specific HLL bugs that have plagued GLSL and HLSL (those billion d3dx_1503.dll on your system are bugfixes). Plus, to give the community access to one or several opensource HLL compilers that they can find issues with and submit for everyone to benefit. So, it's mostly to get a flawless opensource GLSL compiler. Dlang's strengths are simply not applicable directly. Though with a bit of work can actually be applied completely. (I've done them in/with our GLSL/backend compilers) - malloc. SpirV and such don't have malloc. Fix: Preallocate a big chunk of memory, and implement a massively-parallel allocator yourself (it should handle ~2000 requests to allocate per cycle, that's the gist of it). "atomic_add" on a memory location will help. If you don't want to preallocate too much, have a cpu thread poll while a gpu thread stalls (it should stall itself and 6 other threads) until the cpu allocates a new chunk for the heap and provides a base address. (hope the cpu thread responds quickly enough, or your gpu tasks will be mercilessly killed). - function-pointers, largely a no-no. Extensions might give you that capability, but implement as big switch-case tables. With the extensions, you will need to guarantee an arbitrary number (64) of threads all happened to call the same actual function. - stack. I don't know how to break it to you, there's no stack. Only around 256 dwords, that 8-200 threads get to allocate from. Your notion of a stack gets statically flattenized by the compilers. So, your whole program has e.g. 4 dwords to play around and have 64 things hide latency, or 64 dwords but only 4 threads to hide latency - and is 2-4x slower for rudimentary things (and utterly fail at latency hiding, becoming 50 times slower with memory-accesses), or 1 thread with 256 dwords, which is 8-16 times slower at rudimentary stuff and 50+ times slower if you access memory even if cached. Add a manually-managed programmable memory-stack, and your performance goes poof. - exceptions. A combined issue of the things above. Combine the limitations of function-pointers and stack, and I hope you get the point. Or well, how pointless the exercise to get Dlang as we know and love it on a gpu. A single-threaded javascript app on a cpu will beat it at performance on everything that's not trivial.
Re: Targeting Vulkan and SPIR-V
On 12 March 2015 at 15:57, John Colvin via Digitalmars-d wrote: > On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: >> >> On 6 Mar 2015 23:30, "Joakim via Digitalmars-d" >> >> wrote: >>> >>> >>> The ground-up redesign of OpenGL, now called Vulkan, has been announced >> >> at GDC: >>> >>> >>> http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv >>> >>> Both graphics shaders and the latest verson of OpenCL, which enables >> >> computation on the GPU, will target a new IR called SPIR-V: >>> >>> >>> >> >> http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl >>> >>> >>> Rather than being forced to use C-like languages like GLSL or OpenCL in >> >> the past, this new IR will allow writing graphics shaders and OpenCL code >> using any language, including a subset of C++14 stripped of exceptions, >> function pointers, and virtual functions. >>> >>> >>> This would be a good opportunity for D, if ldc or gdc could be made to >> >> target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally >> based on LLVM IR before diverging with SPIR-V. >> >> Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is >> high level enough that you don't need to think (nor care) about your >> backend target. >> >> GCC itself will need a backend to support it though. ;) >> >> Iain > > > Relevant: https://gcc.gnu.org/ml/gcc/2015-03/msg00020.html David is an awesome guy. Would be great if he picks up the baton on this. I reckon most things would be hashed out via GCC builtins, in which someone writes a library for.
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: On 6 Mar 2015 23:30, "Joakim via Digitalmars-d" wrote: The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V. Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is high level enough that you don't need to think (nor care) about your backend target. GCC itself will need a backend to support it though. ;) Iain Relevant: https://gcc.gnu.org/ml/gcc/2015-03/msg00020.html
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 09:05:03 UTC, Paulo Pinto wrote: Of course, this doesn't matter when using engines, which every sane developer should do anyway. Any applications coded straight to graphics APIs ends up being a use case specific mini engine. We'll see, but the downside to having a slim driver is that you risk ending up writing the application engine N times for each GPU rather than once. With a buffering high level driver you get some optimization for free, done by the manufacturer using inside knowledge.
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 11:35:59 UTC, ponce wrote: On Friday, 6 March 2015 at 23:25:40 UTC, Joakim wrote: The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V. Sure, you might target SPIR-V with a C-like language, but how will you generate the IR corresponding to: - texture accesses - local memory vs global memory vs mapped pinned host memory. Looks like you need annotations for your pointers. - sub-blocks operations made core in OpenCL 2.x All things that OpenCL C or GLSL are aware of. Having a GPU backend doesn't make general code fit for high level of parallelism. GPUs are not designed to work-around the poor efficiency of the programs they run. The same way the Haskell, Java, Python and .NET implementations targeting CUDA PTX and HSAIL do. -- Paulo
Re: Targeting Vulkan and SPIR-V
"Russel Winder via Digitalmars-d" wrote in message news:mailman.7408.1425716535.9932.digitalmar...@puremagic.com... Which would mean that anyone interested in CPU/GPU computing will have to eschew DMD in favour of LDC and GDC. Yes. Or for any of the other dozens of platforms that dmd will never support.
Re: Targeting Vulkan and SPIR-V
On Friday, 6 March 2015 at 23:25:40 UTC, Joakim wrote: The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V. Sure, you might target SPIR-V with a C-like language, but how will you generate the IR corresponding to: - texture accesses - local memory vs global memory vs mapped pinned host memory. Looks like you need annotations for your pointers. - sub-blocks operations made core in OpenCL 2.x All things that OpenCL C or GLSL are aware of. Having a GPU backend doesn't make general code fit for high level of parallelism. GPUs are not designed to work-around the poor efficiency of the programs they run.
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 08:41:26 UTC, Ola Fosheim Grøstad wrote: On Saturday, 7 March 2015 at 07:44:18 UTC, Russel Winder wrote: It is not clear how quickly Vulkan compliant hardware will appear, a lot It already exits. Even PowerVR has an (experimental) implementation already... Also, of course, there is the huge problem of moving the AAA games world over to all this. Not really, since it is a lot like Mantle... Vulkan isn't particularly innovative, it is a trip back in time where you have to target the hardware and not the API. Manufacturers like it because there is no point in having high powered GPUs if the applications are CPU bound and Vulkan get's around that. But not having an abstraction over the hardware means that devs will suffer, do manual memory management on the GPU, write their own mipmap format routines etc. And you bet the vendors will add all kinds of extensions to it to stay competitive and we will end up with a mess. I saw a comment in a random forum entry that I cannot recall, that stated an Hello World (triangle) is around 800 lines of C code. Of course, this doesn't matter when using engines, which every sane developer should do anyway. Any applications coded straight to graphics APIs ends up being a use case specific mini engine. -- Paulo
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 07:44:18 UTC, Russel Winder wrote: It is not clear how quickly Vulkan compliant hardware will appear, a lot It already exits. Even PowerVR has an (experimental) implementation already... Also, of course, there is the huge problem of moving the AAA games world over to all this. Not really, since it is a lot like Mantle... Vulkan isn't particularly innovative, it is a trip back in time where you have to target the hardware and not the API. Manufacturers like it because there is no point in having high powered GPUs if the applications are CPU bound and Vulkan get's around that. But not having an abstraction over the hardware means that devs will suffer, do manual memory management on the GPU, write their own mipmap format routines etc. And you bet the vendors will add all kinds of extensions to it to stay competitive and we will end up with a mess.
Re: Targeting Vulkan and SPIR-V
On Sat, 2015-03-07 at 19:16 +1100, Daniel Murphy via Digitalmars-d wrote: > "Russel Winder via Digitalmars-d" wrote in message > news:mailman.7407.1425714258.9932.digitalmar...@puremagic.com... > > > No-one other than the D community will do this for DMD. > > No-one anywhere will do this for DMD. Which would mean that anyone interested in CPU/GPU computing will have to eschew DMD in favour of LDC and GDC. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Targeting Vulkan and SPIR-V
"Russel Winder via Digitalmars-d" wrote in message news:mailman.7407.1425714258.9932.digitalmar...@puremagic.com... No-one other than the D community will do this for DMD. No-one anywhere will do this for DMD.
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 03:57:15 UTC, deadalnix wrote: On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is high level enough that you don't need to think (nor care) about your backend target. GCC itself will need a backend to support it though. ;) Iain Why is that unlike LDC ? LLVM IR is fairly high level (for a compiler IR), is there some specific blocker you are aware of ? Bitcode has target-depedent opcodes. http://llvm.org/devmtg/2011-09-16/EuroLLVM2011-MoreTargetIndependentLLVMBitcode.pdf
Re: Targeting Vulkan and SPIR-V
On Sat, 2015-03-07 at 02:18 +, Iain Buclaw via Digitalmars-d wrote: […] > > Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is > high level enough that you don't need to think (nor care) about your > backend target. > > GCC itself will need a backend to support it though. ;) All Apple's effort will go into Clang, and I suspect they are one of the driving forces behind Vulkan as they were the initiators and driving force behind OpenCL. Thus LDC should be able to get all the work about as "for free" as it gets. The question is whether NVIDIA and Intel will put effort into GCC. If they do then GDC get this about as "for free" as it gets. No-one other than the D community will do this for DMD. It is not clear how quickly Vulkan compliant hardware will appear, a lot faster than the compilers most likely, but they will get hamstrung with OpenGL and OpenCL compliance – which may end up very annoying, albeit necessary. Also, of course, there is the huge problem of moving the AAA games world over to all this. So I suspect we have a few weeks of time (*) to mull over this before it is all in everyone face. But I can see this being big because it is a new thing that games and hardware manufacturers can use for marketing. There is nothing so useful to marketing as something that is genuinely new (**). (*) well tens of weeks probably. (**) OK so Vulkan is only new-ish, but the marketers won't care. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Targeting Vulkan and SPIR-V
On 7 Mar 2015 04:00, "deadalnix via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: >> >> Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is >> high level enough that you don't need to think (nor care) about your >> backend target. >> >> GCC itself will need a backend to support it though. ;) >> >> Iain > > > Why is that unlike LDC ? LLVM IR is fairly high level (for a compiler IR), is there some specific blocker you are aware of ? The necessity of the changes in PR 768 - infact just the fact that LDC needs them raises eyebrows. :) Iain
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is high level enough that you don't need to think (nor care) about your backend target. GCC itself will need a backend to support it though. ;) Iain Why is that unlike LDC ? LLVM IR is fairly high level (for a compiler IR), is there some specific blocker you are aware of ?
Re: Targeting Vulkan and SPIR-V
On 6 Mar 2015 23:30, "Joakim via Digitalmars-d" wrote: > > The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: > > http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv > > Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: > > http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl > > Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. > > This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V. Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is high level enough that you don't need to think (nor care) about your backend target. GCC itself will need a backend to support it though. ;) Iain
Targeting Vulkan and SPIR-V
The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V.
