The Kazan Vulkan CPU/Software-Based Implementation Being Rewritten In Rust

[phoronix]

Phoronix: The Kazan Vulkan CPU/Software-Based Implementation Being Rewritten In Rust

Remember Kazan, the project originally known as Vulkan-CPU? That was the Google Summer of Code 2017 project to implement a CPU/software-based Vulkan driver. It had been dormant since GSoC 2017 ended, but now work on it has been restarted...

http://www.phoronix.com/scan.php?page=news_item&px=Kazan-Vulkan-Rust

[GunpowaderGuy]

Does that mean risc v based GPUs vulkan implementation Will be a c wrapper to a Rust version of the api ?

[schmidtbag]

Considering Vulkan's reduced CPU overhead, I suspect this will have noticeably better performance than LLVMpipe (though, I'm sure it'll still be crappy).

Michael: think you'll try benchmarking this on some of your Epyc or dual-Xeon platforms? I suspect this could have some pretty interesting results.

[Michael]

Considering Vulkan's reduced CPU overhead, I suspect this will have noticeably better performance than LLVMpipe (though, I'm sure it'll still be crappy).

Michael: think you'll try benchmarking this on some of your Epyc or dual-Xeon platforms? I suspect this could have some pretty interesting results.

Once it matures and actually runs stuff, will try it out on some dual EPYC and dual Xeon hardware... But for now I don't think Kazan is even running simple demos.

[Vistaus]

No need to make rewrite-into-rust jokes this time! lol

[Weasel]

No need to make rewrite-into-rust jokes this time! lol

Yeah because this time the code itself is the joke, since it's Rust.

[cl333r]

Yeah because this time the code itself is the joke, since it's Rust.

I don't think Rust code is that bad since the phoronix benchmarking test suite is being rewritten in Rust.

[Weasel]

I don't think Rust code is that bad since the phoronix benchmarking test suite is being rewritten in Rust.

If that's true, then what a waste of effort for an inferior end result.

[lkcl]

Phoronix: The Kazan Vulkan CPU/Software-Based Implementation Being Rewritten In Rust

Remember Kazan, the project originally known as Vulkan-CPU? That was the Google Summer of Code 2017 project to implement a CPU/software-based Vulkan driver. It had been dormant since GSoC 2017 ended, but now work on it has been restarted...

i'm sponsoring jacob to work on the project, having donated 50% of my personal income from work in the past 2 months to him, as he has had to take a year out from university. if anyone else would like to help with donations that would be great: i can be reached by email [email protected]

the project's primary focus is to create - at last - an actual libre-licensed GPU (and later a VPU), targetting mobile-level performance as the first milestone. RISC-V was chosen because it is gaining a lot of momentum (for very good reasons); jacob recommended vulkan3d over llvmpipe because the design of llvmpipe is single-threaded in a performance-critical area.

we specifically chose a software-driven focus and to add custom 3D primitives where needed because it is an approach that a small team can handle, and achieve a high bang-per-buck ratio. vulkan3d because it will not be necessary to write an OpenGL driver. LLVM because parallelism (vectorisation) may be transparently (and much more easily) added to that than to gcc. Rust because of the security and other gurarantees that it provides.

jacob will be working initially on an x86 non-accelerated version so that we can get started. if LLVM for x86 provides reasonable performance for anyone interested in it, that is great: x86 however is not the primary focus, it is just a way to ensure a stable codebase. i.e. the reason for doing x86 is so that any bugs in a RISC-V LLVM port, or in the custom RISC-V 3D hardware, may be triaged and isolated as "unlikely to be in the vulkan3d implementation itself".

there is a lot to do: if anyone would like to help out please do get in touch: the mailing list is here http://lists.libre-riscv.org/mailman...ibre-riscv-dev

[lkcl]

I don't think Rust code is that bad since the phoronix benchmarking test suite is being rewritten in Rust.

jacob informs me that rust has call-outs (JIT for example) via a c API, so any performance-critical loops will be implemented in assembler. particularly those that will require the use of any custom RISC-V opcodes that will need to be added, not just to get best performance, but because adding support for custom RISC-V instructions to LLVM or to Rust may end up slowing the development cycle. so it's not just a straight software-only project, it's a hybrid hardware-software project that's only really possible thanks to RISC-V (can anyone imagine a small team adding libre-licensed custom instructions to an intel or AMD processor or to ARM?)