Research Naga, to see if it can be used to parse SPIR-V's structured control flow with the correct API shape -- replacing the part of #161 that I'm stalled on, allowing easier progress. https://github.com/gfx-rs/naga SPIR-V control flow parsing: https://gfx-rs.github.io/2021/10/07/release-0.11.html#more-robust-shader-translation
It looks like it should work from an architecture perspective, since naga's IR is tree-based, like Kazan's ir, rather than flat-CFG-based, like SPIR-V. I asked on their matrix room: #naga:matrix.org > I'm writing Kazan, a Vulkan driver written in Rust for Libre-SOC's GPU (as > well as cross-platform sw rendering), and am currently stalled on parsing > SPIR-V's structured control flow, I was wondering if you all would be open > to my using naga to handle SPIR-V parsing for that...I would translate naga's > IR to Kazan's IR. Afaict this would require some work to be done by Libre-SOC > and/or naga for naga's SPIR-V front end to improve to eventually be Vulkan > compliant... Was wondering if that all sounds good to you?
(In reply to Jacob Lifshay from comment #1) > It looks like it should work from an architecture perspective, since naga's > IR is tree-based, like Kazan's ir, rather than flat-CFG-based, like SPIR-V. nice. looks really good. > I asked on their matrix room: > #naga:matrix.org if that can be bridged to libera i can point supybot at it.
kvark: > programmerjake: hi! > The spirv frontend was contributed to by multiple people. jcapucho > recently rewrote the most complex part of it. If you want to hook it up > to Kazan IR, you are welcome to do so. This "Kazan backend" would live > in your repository. Our IR is all public. You can see other backend code > for inspiration. > > So what is unclear to me is - what kind of assistance can we provide > to you? Just answering any questions is the obvious minimum. Is there > anything else you expect or would like? > > Btw, libre-SOC is super exciting. I'm not completely sure how/why Kazan is > trying to be both a software and a hardware implementation of Vulkan. Is > this to mimic Mesa, which has both? > (...several irrelevant messages omitted...) programmerjake: > kvark I'm mostly just checking to see if the naga community is up > to accepting pull requests (or more, tbd) for extending the SPIR-V > frontend...I wanted to avoid needing to fork naga if you all decided that > you only wanted to ever support the WebGPU subset, and that any additional > support was unwelcome. I'm going to be busy with other parts of Libre-SOC > for the near future, so don't know when I'll actually be able to work on > Kazan. Funding (through NLNet) may be available for improving naga where > justifiable, the current funding for Kazan expires in spring 2022 iirc. kvark: > programmerjake: right. In general, we aim to support more than just > what WebGPU needs. There is WebGPU core, there is wgpu native (which > needs stuff like descriptor arrays, or subgroups), and there is the rest > of Vulkan. > > Speaking of the rest of Vulkan. Supporting geometry/tessellation/mesh > shader parsing in SPIR-V frontend was not planned at all. I'm curious > about how we could squeeze it with minimal changes to the IR. Maybe > we could. > > It would be useful to know what functionality of Vulkan you are looking > to support. I.e. tessellation isn't required for Vulkan conformance. programmerjake: > Kazan is trying to be both a sw/hw Vulkan driver because Libre-SOC is > taking the approach of having our GPU cores also be CPU cores...rendering > happens by normal Linux threads. We are extending the OpenPower > instruction set with Vectors, Texture mapping instructions, transcendental > instructions, and other instructions as needed to make GPU workloads > fast enough Kangz: > (sounds like RISC-V Larrabee) kvark: > I see. That seems very reasonable (and exciting!) programmerjake: > I'd expect tesselation shaders to be relatively easy to add to the SPIR-V > frontend, since the only additional thing I'd require is to preserve > all the tesselation-specific annotations in the parsed shaders > > > <@kangz:matrix.org> (sounds like RISC-V Larrabee) > > yeah, kinda. We're planning on extending the ISA to be hopefully easier > to use and more efficient than AVX512, so hopefully we'll avoid the > larrabee disaster. One particular improvement, we will likely add triangle > rasterization instructions...iirc that really slowed down larrabee > > our vector ISA design: https://libre-soc.org/openpower/sv/ > > btw, is this matrix channel bridged to libera irc by any chance? cwfitzgerald: > this channel isn't bridged anywhere right now programmerjake: > k, thx