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