digitalmars.D - Vulkan bindings
- Satoshi (3/3) Feb 16 2016 Hello Vulkan API 1.0 is here and I just wrapped it into D.
- Rikki Cattermole (3/6) Feb 17 2016 Btw you removed Khronos header/license declaration.
- Satoshi (3/11) Feb 17 2016 Fixed.
- Alex Parrill (5/8) Feb 17 2016 Please consider making it a Dub package!
- Kapps (6/16) Feb 17 2016 This is what I did with OpenGL for my own bindings. It had some
- Kapps (3/8) Feb 17 2016 And I should clarify, ahead of time to generate a .d file, not at
- Alex Parrill (7/17) Feb 18 2016 Yea, by "directly", I meant using D templates and CTFE, not a
- ParticlePeter (5/24) Feb 19 2016 What about all the other layers (currently) found in the LunarG
- ZombineDev (27/37) Feb 17 2016 I started working on that. I've been reading the Python C Header
- Nicholas Wilson (12/43) Feb 24 2016 Hey I've started work on a more D like vulkan
- Thomas Brix Larsen (4/18) Feb 24 2016 Did you look into adapting VkCppGenerator for the task?
- Mike Parker (2/5) Feb 17 2016 https://github.com/Dav1dde/glad
- ParticlePeter (3/6) Feb 19 2016 I think your usage of const pointer is wrong. E.g. c const char*
- Satoshi (3/11) Feb 21 2016 Thanks, I just fixed it.
Hello Vulkan API 1.0 is here and I just wrapped it into D. https://github.com/Rikarin/VulkanizeD Have fun!
Feb 16 2016
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.
Feb 17 2016
Satoshi <satoshi gshost.eu> On Wednesday, 17 February 2016 at 10:55:22 UTC, Rikki Cattermole wrote:On 17/02/16 8:01 AM, Satoshi wrote:Fixed.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.
Feb 17 2016
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)
Feb 17 2016
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: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.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)
Feb 17 2016
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
Feb 17 2016
On Thursday, 18 February 2016 at 03:39:30 UTC, Kapps wrote:On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote: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.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
Feb 18 2016
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: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?On Thursday, 18 February 2016 at 03:38:42 UTC, Kapps wrote: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.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
Feb 19 2016
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: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.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)
Feb 17 2016
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: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 Waaaaay 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[...]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.
Feb 24 2016
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:Did you look into adapting VkCppGenerator for the task? https://github.com/nvpro-pipeline/vkcpp[...]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 Waaaaay 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
Feb 24 2016
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
Feb 17 2016
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.
Feb 19 2016
On Saturday, 20 February 2016 at 07:59:13 UTC, ParticlePeter wrote:On Tuesday, 16 February 2016 at 19:01:58 UTC, Satoshi wrote:Thanks, I just fixed it.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.
Feb 21 2016