ILGPU
ILGPU copied to clipboard
m4rs-mt
SPIR-V Builder (1/6 SPIR-V Backend PRs)
This is the first of six planned PRs for the current state of the SPIR-V backend. It adds the two SPIR-V builder classes, StringSPIRVBuilder and BinarySPIRVBuilder, which provide an interface to generate SPIR-V in string representation and runnable binary respectively.
Note: I added tests for the builder utilities for my own convenience, if they should be removed I can do that.
Question: I added JetBrains Rider's cache folder to the .gitignore, as I personally use the education version. Should I remove it? It would be a little annoying to delete the cache each time I want to commit, but I understand that it's not an IDE that many use.
Question: What should we do about the massive SPIRV grammar file? I assume we don't want to just keep that laying around.
Hey, is it alright to ignore some warnings for generated code? For example enum members having the same value? Or CLS compliance? I could fix them but considering the code is generated it doesn't seem very worthwhile, except maybe the warnings about conflicting language keywords.
The last commit will compile and I can get it to compile on the CI with a little bit of work. Unfortunately, the work involves adding CLS compliance attribute. What I have done hasn't really solved the uint issue, it's just moved it further back. uint will always be involved in some capacity, the question is how far we want to push it back. I could go ahead and replace all of the uint parameters in our generated structs with SPIRVWord, but I'm not sure if this is the best course of action as it would mean having to call new SPIRVWord each time we want to construct one of those generated structs. We could add an implicit conversion to fix that, but again, not sure if there is a better way forward. Thoughts?
@m4rs-mt @MoFtZ don't mean to be pushy but is there any progress on this? If there are things that need to be discussed I'm open to that. Don't be afraid to tear the PR apart if the implementation is not up to standard!
Thanks
@Yey007 I'm not familiar with SPIR-V, so I don't think I'll be much help in reviewing that side of things.
One thing we need to consider is how to handle the file spirv.grammar.xml. Does this file need to live in a separate repository?
We originally had issues with processing the original JSON, and that's why we converted it to XML. Should we try to get the JSON processing working? That would potentially allow us to use a direct link to the original JSON. Alternatively, should we be linking to the JSON and converting to XML on-the-fly?
@Yey007 Thank very much you for your work and efforts you have put into this work. As @MoFtZ pointed out, we discussed several ways to integrate SPIR-V support into ILGPU. We concluded that it would be best to try to avoid importing the grammar files directly. As an alternative, we considered that we could fork the grammar repository and add a custom "builder generator" to that repository that would create all the bindings outside of the ILGPU repository. ILGPU can then use the pre-built bindings instead of regenerating them during the build process.
