| Summary: | Write PowerPC64 backend for Cranelift | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Jacob Lifshay <programmerjake> |
| Component: | Source Code | Assignee: | Jacob Lifshay <programmerjake> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | libre-soc-bugs, lkcl, programmerjake, vivekvpandya |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| NLnet milestone: | NLnet.2019.02.012 | 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: | 54, 140 | ||
|
Description
Jacob Lifshay
2020-06-25 17:39:32 BST
See comment on Cranelift's repo: https://github.com/bytecodealliance/wasmtime/issues/1183#issuecomment-649711135 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 (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? (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 Got a reply on github from Cranelift project: https://github.com/bytecodealliance/wasmtime/issues/1183#issuecomment-650116429 (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. |