[Libre-soc-bugs] [Bug 725] Research Naga to see if it will help un-stall #161

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=725

--- Comment #3 from Jacob Lifshay <programmerjake at gmail.com> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.