Bug 405 - Write PowerPC64 backend for Cranelift
Summary: Write PowerPC64 backend for Cranelift
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: All All
: --- enhancement
Assignee: Jacob Lifshay
URL:
Depends on:
Blocks: 54 140
  Show dependency treegraph
 
Reported: 2020-06-25 17:39 BST by Jacob Lifshay
Modified: 2020-08-16 07:13 BST (History)
4 users (show)

See Also:
NLnet milestone: NLnet.2019.02
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2020-06-25 17:39:32 BST
One task that would be quite useful is adding a PowerPC64 backend to Cranelift.

https://github.com/bytecodealliance/wasmtime/issues/1183

Mozilla, IBM, Raptor Computing, and others might help with funding since this would also benefit them since Cranelift is planned to be a backend for WebAssembly in Firefox, as well as a debug backend for Rustc, and is the backend for wasmtime and lucet, two widely used non-browser implementations of WebAssembly.

Kazan with Cranelift would be similar to RADV with ACO with the additional benefit that both Kazan and Cranelift are written in Rust.

One additional benefit is that, when combined with Cranelift, Kazan might be able to run under an RTOS instead of requiring Linux, since both Kazan and Cranelift have mostly-complete support for #![no_std]. This seems like a huge advantage over a lot of other graphics drivers.
Comment 1 Jacob Lifshay 2020-06-25 18:16:44 BST
See comment on Cranelift's repo:
https://github.com/bytecodealliance/wasmtime/issues/1183#issuecomment-649711135
Comment 2 Jacob Lifshay 2020-06-26 01:56:27 BST
Luke (and others), what do you think of prioritizing using Cranelift as the shader compiler backend over LLVM?

I'm planning on adding support for Cranelift even if we add LLVM support first, because of Cranelift's massive shader compile-time advantage.

Cranelift is much more similar to the ACO backend for RADV in Mesa.

Advantages:
- simplicity
- written in Rust
- the shader compiler would run much more quickly -- important for graphics drivers
- can architect the backend to work with our processor better since we'd be writing the code
- works on embedded systems without a full Linux OS
- can probably get additional funding from other interested parties since Cranelift having a PowerPC64 backend is quite useful beyond the bounds of our project
- can easily use existing/add new C bindings for use from Mesa-based graphics driver

Disadvantages:
- need to write whole new backend since Cranelift currently doesn't support PowerISA -- can be done in a very incremental fashion.
- we can't use LLVM's additional optimizations, though those are not that likely to be very useful anyway
Comment 3 Luke Kenneth Casson Leighton 2020-06-26 02:55:59 BST
(In reply to Jacob Lifshay from comment #2)
> Luke (and others), what do you think of prioritizing using Cranelift as the
> shader compiler backend over LLVM?

would there be any overlap for the MESA driver, to save time/code there?
Comment 4 Jacob Lifshay 2020-06-26 03:20:57 BST
(In reply to Luke Kenneth Casson Leighton from comment #3)
> (In reply to Jacob Lifshay from comment #2)
> > Luke (and others), what do you think of prioritizing using Cranelift as the
> > shader compiler backend over LLVM?
> 
> would there be any overlap for the MESA driver, to save time/code there?

yes, both Cranelift and LLVM can be used from Mesa:

> > - can easily use existing/add new C bindings for use from Mesa-based graphics driver
Comment 5 Jacob Lifshay 2020-06-26 23:17:56 BST
Got a reply on github from Cranelift project:
https://github.com/bytecodealliance/wasmtime/issues/1183#issuecomment-650116429
Comment 6 Luke Kenneth Casson Leighton 2020-06-26 23:28:30 BST
(In reply to Jacob Lifshay from comment #5)
> Got a reply on github from Cranelift project:
> https://github.com/bytecodealliance/wasmtime/issues/1183#issuecomment-
> 650116429

that's quite encouraging.  one of the important things to bear in mind
and make clear: we always need to have the non-accelerated software-version
working, first, as an intermediary stepping-stone.  where that used to
be RISC-V RV64GC, it's now POWER9 (PowerISA v3.0B)

then on top of that, once that's stable, we can begin adding accelerated
3D / VPU opcodes.

so kinda by default we become the de-facto maintainers of the POWER9
version.  and consequently, yes, it's appropriate for that to be upstream.