Bug 725 - Research Naga to see if it will help un-stall #161
Summary: Research Naga to see if it will help un-stall #161
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Jacob Lifshay
Depends on:
Blocks: 161
  Show dependency treegraph
Reported: 2021-10-12 07:28 BST by Jacob Lifshay
Modified: 2021-10-12 18:16 BST (History)
3 users (show)

See Also:
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:


Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2021-10-12 07:28:15 BST
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.


SPIR-V control flow parsing:
Comment 1 Jacob Lifshay 2021-10-12 07:58:28 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:

> 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?
Comment 2 Luke Kenneth Casson Leighton 2021-10-12 12:03:03 BST
(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.
Comment 3 Jacob Lifshay 2021-10-12 18:16:23 BST
> 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...)

> 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.

> 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.

> 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

> (sounds like RISC-V Larrabee)

> I see. That seems very reasonable (and exciting!)

> 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?

> this channel isn't bridged anywhere right now

> k, thx