| Summary: | Research Naga to see if it will help un-stall #161 | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Jacob Lifshay <programmerjake> |
| Component: | Source Code | Assignee: | Jacob Lifshay <programmerjake> |
| Status: | IN_PROGRESS --- | ||
| Severity: | enhancement | CC: | libre-soc-bugs, lkcl, programmerjake |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| NLnet milestone: | --- | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
| Bug Depends on: | |||
| Bug Blocks: | 161 | ||
|
Description
Jacob Lifshay
2021-10-12 07:28:15 BST
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 |