We're probably on the same page about formal methods.
I wanted to point out a cool example I helped with: formalizing the structured control flow rules for SPIR-V.
https://dl.acm.org/doi/10.1145/3571253
This was a really nice blend of theory and practice to nail the details on a gnarly bit of the GPU intermediate language we know and love. And in the end the (prose) rules are easier to understand too.
There are now 48 registered SPIR-V generator tools.
Woohoo.
https://github.com/KhronosGroup/SPIRV-Headers/blob/main/include/spirv/spir-v.xml#L100
I'm getting the material ready for my upcoming #GPGPU course that starts on March. Even though I most probably won't get to it,I also checked my trivial #SYCL programs. Apparently the 2025.0 version of the #Intel #OneAPI #DPCPP runtime doesn't like any #OpenCL platform except Intel's own (I have two other platforms that support #SPIRV, so why aren't they showing up? From the documentation I can find online this should be sufficient, but apparently it's not …)
I've been writing quite a few SPIR-V modules by hand for testing lately. It's tolerable, but only barely.
My primary complaints are:
1. Verbosity. A test for a single instruction tends to be at least 20 lines and sometimes much more.
2. SSA is great for compilers, not so much for humans.
3. Getting all of the type declarations and capabilities right is annoying.
Is there a better way? #spirv
Vulkan 1.4:
Glslang, Shaderc, and SPIRV-Tools updates have landed to be able to target Vulkan 1.4.
No major changes to Vulkan SPIR-V, so this is mostly about being able to specify Vulkan 1.4 in options lists.
These will be rolled into the next Vulkan SDK.
Khronos' OpenCL Working Group has issued a Request for Proposal (#RFP) for OpenCL LLVM SPIR-V Backend. The goal of this project is to address and integrate specific functionalities that are currently available in the translator project but missing from the backend. All bids are due December 6, 2024.
Learn more: https://www.khronos.org/rfp/khronos-opencl-llvm-spir-v-backend
#LLVM #SPIRV #SPIR
The rust-gpu project now has two more maintainers. Happy to see the project gaining speed!
I'm using rust-gpu for most my Vulkan experiments these days. It's one of the enablers of my SDF-compiler toolchain. It lets you define linking points, which in turn allows me to link my SDF generated SPIR-V code into rust-gpu generated SPIR-V modules.
DirectX is adopting SPIR-V 
https://devblogs.microsoft.com/directx/directx-adopting-spir-v/
Finally got #HLSL -> #spirv -> running in #bevy! Just a simple compute shader for slope/normal/ocean detection at the moment. The spirv inpsector at https://www.khronos.org/spir/visualizer/ was a life saver! also, this is the first time ive use the build.rs in #rust suuuper handy for automatically recompiling the hlsl. Feels like bevy's Dx12 backend might need some love since i had to switch back to vulcan but so happy to have actually got it running.
I think people get tied up in knots when trying to parse SPIR-V with structured control flow.
You gotta do it in reverse structured post-order.
Once you lay out the basic blocks in that order, the nested control constructs map to *intervals* over that list. (:galaxy brain:)
For details, see Tint's SPIR-V to WGSL translator.
Does anyone know whether #SpirV supports closures?
By the spec, it seems like I can define a function inside a function.
Can the outer function return a pointer to the inner function?
And since we're here, is there a dedicated forum/community/chat where I can ask this kinds of questions?
The Khronos SPIR forum seems dead. =|
@ypujante
(And, those would be one of the unit tests of the SPIR-V to WGSL translator, converted to an end-to-end test so we can check the right thing will be emitted on all the backend languages.)
mkdir src/Targets/SpirV
It's happening.... _^
I'm finally starting the work to compile #Squarepants to #SpirV...
I never thought my language would get to this point! =D =D =D
I'm finally at the point where I have to start working on perhaps the main feature of my programming language Squarepants: the ability to compile to GPU Shaders.
The most attractive target would be #SpirV which is an intermediate representation that works almost everywhere... Except on browsers, and only because #Apple didn't want to give control of the standard to the group that develops SpirV.
Instead, Apple imposed #WGSL , which is a language instead than an intermediate representation, so it's a pain in the ass to target and will end up with the same problem as #javascript .
At some point there will be translators from SpirV to WGSL, but I can't rely on those now.
So, what am I going to target?
Right now Squarepants compiles to javascript, so can run easily in both browsers and #nodejs.
There is a project to run SpirV (via Vulkan) on node, but has been dead for years, which means that if I want to compile to a native application, I need Squarepants to compile to C or LLVM first.
OTOH if I go through the square-peg-in-round-hole and target WGSL, then I can target browsers.
-sigh-, I feel like I have no good option.
I know SPIR-V is not meant for human readability and all that, but damn. Is there not any way that the variables were named anything closer to useful than %13525? I understand that it's not a one-to-one match with my glsl variables, but like... This feels like it's actively trying to obfuscate the code 
Maybe there's some glslang option I don't know about that tries to make them a bit clearer?
The SPIR Working Group developed 2 new SPIR-V extensions to provide shader authors with more guarantees about the execution model of shaders: SPV_KHR_maximal_reconvergence and VK_KHR_shader_quad_control.
Learn more: https://www.khronos.org/blog/khronos-releases-maximal-reconvergence-and-quad-control-extensions-for-vulkan-and-spir-v
#SPIRV #Vulkan #Shaders
My small SDF language is working now!
It currently compiles this code in ~5ms into a new SPIR-V module that is linked into the sphere-tracing shader.
The `offset` parameter is wired to a push constant. So you can move the sphere/torus in this example without having to recompile the SDF.
wow this project is so cool, a sophisticated #shader IDE with its own #SPIRV virtual machine
https://shadered.org/
https://github.com/dfranx/SPIRV-VM
chipStar 1.0 released! It's a tool for compiling and running CUDA/HIP applications on SPIR-V-supported OpenCL or LevelZero platforms. v1.0 can already run various HPC applications correctly. See: https://github.com/CHIP-SPV/chipStar/releases/tag/v1.0
#opencl #levelzero #spirv #cuda #hip
I am giving a talk later today at the #oneAPI SIG Hardware Group about #TornadoVM and how it connects with #SPIRV and #LevelZero from the oneAPI software stack.
This is an opportunity for academics and Industry to motivate new changes for the LevelZero SPEC.
