Dcompute on OpenGL / HLSL compute
I'm happy to announce that I've managed to generate OpenGL compute shaders from the OpenCL compilation pipeline. Through the use of https://github.com/KhronosGroup/SPIRV-Cross the means that we can generate GLSL, HLSL and MSL source The setup and compilation steps is very janky at the moment but does produce legit looking GLSL/HLSL. I say looks, because I lack the means to run it at the moment. This will hopefully become less janky in the future. To produce a compute shader source you will need: ldc built with https://github.com/KhronosGroup/SPIRV-LLVM-Translator as with the regular means of producing OpenCL SPIR-V, https://github.com/google/clspv/ with https://github.com/google/clspv/pull/764 applied to convert the OpenCL SPIR-V to OpenGL compute SPIR-V and https://github.com/KhronosGroup/SPIRV-Cross to convert the resulting GL compute SPIR-V to HLSL/MSL if desired. The full compilation steps are then (I did say it was janky): ``` ldc2 --mdcompute-targets=ocl-200 -m32 ./kernel.d other_files.d -Iother_imports llvm-spirv -r kernels_ocl200_32.spv llvm-dis kernels_ocl200_32.bc clspv -x=ir kernels_ocl200_32.ll # and optionally spirv-cross --hlsl a.spv --output a.hlsl ``` 32-bit mode for ldc is required because only 32-bit OpenCL SPIR-V can be converted into OpenGL compute SPIR-V. If `-m32` doesn't work the you may have to supply an equivalent `-mtriple`
Re: [Semi-OT] Sdlang Initiative
On Thursday, 9 September 2021 at 01:20:24 UTC, James Blachly wrote: I have finally come around to TOML as the best alternative for human-centered configuration. It seems to be really popular in Rust ecosystem. I see 3 D libraries; haven't tested them but will with my next D project: https://code.dlang.org/search?q=toml I was using `toml-foolery` for one of my projects. It's quite nice; however, there might be too many dependencies for some people, and a `RangeError` will be thrown up to you during parsing if there's an empty string for a key's value. While the latter is probably easy to remedy, I switched to using JSON since `asdf` was already a dependency, and I'm lazy. Still, a big thanks to Andrej for the work.
Re: [Semi-OT] Sdlang Initiative
On 9/6/21 2:01 PM, Steven Schveighoffer wrote: But I actually am using sdlang-d for configuration files on my web server. However, I do not like the interface for it very much. SDLang itself is OK, but I find actually that I don't love the format. Like yaml, I have to research how the file format works every time I want to use it (maybe just because I very rarely have need to edit sdl files). For that reason I prefer json, but I hate that json doesn't allow comments and is full of quote spam (for config files). I am planning at some point to replace the config system with a [json5](https://json5.org/) implementation (based on jsoniopipe), otherwise this would definitely interest me! I have finally come around to TOML as the best alternative for human-centered configuration. It seems to be really popular in Rust ecosystem. I see 3 D libraries; haven't tested them but will with my next D project: https://code.dlang.org/search?q=toml
Re: Surprise - New Post on the GtkD Coding Blog
On Tuesday, 7 September 2021 at 12:29:14 UTC, Dukc wrote: On Friday, 3 September 2021 at 18:52:13 UTC, Adam D Ruppe wrote: (i loathe and despise wayland but ill try not to rant) Have you written more about this on your blog? I have not (well not directly anyway, wayland flamewars is one of the things that directly inspired this post: http://dpldocs.info/this-week-in-d/Blog.Posted_2021_03_08.html#adam's-rant ). The short version is the wayland devs were hyperfocused on one use case and missed the big picture. This led them to wrongly believe that the majority of X is completely useless legacy bloat, so instead of patching up the one use case, they threw it all out. ...then they have spent 13 years slowly reinventing it doing extension after extension and revision after revision after revision, and still haven't actually even reliably fixed the one issue they complained about... while X actually did patch it up if you opt into it (via the dri2 and sync extensions) and it does a pretty good job. They also bring up spurious security complaints - which have been around since the 90's btw but never materialized into a real problem - which are also patched via X extensions or nested servers. It could certainly be better but a version 1.1 or 2.0 of the security extension could realistically fix that up, no need to throw everything out. (Notice how Microsoft made similar changes in Windows without a significant breakage of backward and interoperation compatibility.) So they broke everything for no benefit. Again. It is just like the broken audio stuff. And then it really annoys me that the wayland proponents are rarely well educated on X, saying things that are just untrue. So that ups the flamewars to 11.
Re: Surprise - New Post on the GtkD Coding Blog
On Tuesday, 7 September 2021 at 23:28:00 UTC, Imperatorn wrote: Welcome back! 🍀 Thanks, Imperatorn. BTW, if anyone has questions about any of the articles, GtkD Coding has a brand-spanking new commenting feature.
