Thoughts on making Slang a "full language"

[LouChiSoft]

Apologies if this has been asked elsewhere, I did a search and couldn't find anything.

The more I use Slang the more I want to be able to use it for all code in an application, with a proper main function and standard library. Writing shaders in Slang is just way simpler and more enjoyable an experience than basically any of the other languages, but then having to go back to C/C++ (or realistically any language that support the graphics API the user wants to use) is kinda a chore.

If the language itself focused on including the sort of things that GPU APIs need, like pipelines, memory management, and maybe even file management (e.g. on platforms that support direct to GPU loading, having that done automatically in the background would be excellent), I think it would be head and shoulders above anything else in the GPU programming space. Another thing I can think of is things like alignment and extending the already very good automatic bindings since the compiler could be designed to know all the information on both the CPU and GPU side of the program to tie those together automatically

It would be great if we had a true 1 language solution with a project management tool (think Cargo for Rust) that allows the user to write a whole application in Slang, and then just like slangc does now where it compiles the source to something else like SPIR-V or DXIL for runtime, it would transpile the non-GPU parts of the code to something like C or C++. E.g. slang-proj build --windows would make a C++/DX12 application and use DirectStorage on devices that support it, but slang-proj build --linux on the same code would make a C++/Vulkan and potentially use the NV GPU decompression layer

I realise that this isn't a small or easy task and there's a whole list of things that should be considered before an implementation could even begin. I just wanted to know if this has been considered by anyone on the time/ruled out already.

[natevm]

If I understand right, we’re very close to having this working. I kinda see the possibility of a CUDA-like workflow with slang, where host and device code can intermix. But then I also think having vectors / matrices included as a first class citizen of the language is also a unique benefit that CUDA misses the mark a bit on. For certain differentiable workloads, having a unified language could also enable some interesting new options for computing gradients.

[LouChiSoft]

This is good to hear. I agree with pretty much everything you've said with regards to making vector/matrices a first class citizen and being able to intermix code. I use Cuda for my job and it was the inspiration for this post. But while Cuda is great for what it offers it still doesn't offer everything, like graphics stages or non-Nvidia support (for obvious reasons).

I do think this is where Slang can shine by essentially being "the Cuda for graphics applications" on any platform via transpiling to the code that will actually be run (C++/C, DX/VK/TML, etc.)

If I understand right, we’re very close to having this working.

Is this something that's been working on internally or currently available? I think that I remember reading that you do have some kind of executable mode, but when I made the original post I tried to find it again but couldn't. But in either case, I don't remember there being a way to straight up write a main function as if it was single threaded CPU code. Maybe I am just bad at reading the docs 🤣

[natevm]

I've seen @csyonghe compiling / running a single threaded CPU program, as a quick way to test a slang feature. But I don't remember how he was able to get that to work. We should definitely look into having it documented somewhere

[LouChiSoft]

That's cool to know, documentation on it would be great yeah

[natduca]

I'd love to hear @tangent-vector's thoughts on this!

[csyonghe]

@LouChiSoft As you have discovered, there has been experimental work going on to make slang a good CPU language, such as the COM interface support, try error handling, Optional<T> type etc.

The long term vision is to make Slang a desirable option for writing heterogeneous CPU/GPU code. When designing the language, we are taking this vision into account. However our current engineering resource is still very limited and we can't invest a lot of time to bring up all the required the CPU programming features to reach product level matureness, but we are slowly working towards this goal!

Please feel free to share your thoughts, and we always welcome contributions in any form!

[LouChiSoft]

Thank you for the update. I do appreciate the effort going into it and I completely understand limited engineer resource limits. Things like try and Optional<T> are super important in a modern language these days. Not a huge fan of COM myself, but I understand it's inclusion.

As for sharing my thoughts, I am not sure what I could offer short of a 'wishlist' of language features if you find that useful. Like I said I am not a compiler dev so I don't know what I could suggest from a technical level.

[csyonghe]

We certainly welcome your ideas! Feel free to share them in the discussion channel.

[LouChiSoft]

Also sort of related to this topic because it might change prioritites. Has the recent announcement from MS that moving forward the IL of choice for DX12 applications will be SPIR-V change anything? I don't know the intricacies of DX specific SPIR-V vs Vulkan SPIR-V. But it sounds like it might make things easier in the future by getting two APIs to share 1 IL

[csyonghe]

On the slang side nothing will be changed in the short term, but we definitely like that decision from Microsoft! This means that Slang should be able to target future d3d APIs without going through HLSL, and this in turn means faster compiles and better debug info for slang users. And put slang aside, this will greatly benefit the whole ecosystem because we will have more people working together to make spirv better.