[libre-riscv-dev] presentation on graphics drivers & doing it right the first time
programmerjake at gmail.com
Fri Oct 4 07:10:11 BST 2019
On Thu, Oct 3, 2019, 22:37 Michael Pham <pham.michael.98 at gmail.com> wrote:
> On Fri, Oct 4, 2019 at 1:08 AM Jacob Lifshay <programmerjake at gmail.com>
> > Vulkan is basically the driver model (API), it's actually quite similar
> > Gallium.
> > Kazan is an implementation of both:
> > 1. the translation layer from Vulkan to the internal memory structures
> > shader invocations
> > 2. the front end of the shader compiler
> For your second point, how does SPIR-V/NIR factor into the front end?
SPIR-V is the language shaders are specified in for Vulkan, Kazan
translates from SPIR-V to LLVM IR (for the LLVM compiler version). NIR in
Mesa takes on basically the same role that LLVM IR does in Kazan: it's
where most of the optimization happens.
> > the backend compiler is part of LLVM, Cranelift, and/or GCC (the three
> > compilers I am planning on Kazan being able to use).
> It's interesting how you are planning on Cranelift being one of the
> Very interesting project, but compilers are a lot of hard work.
we're planning on Cranelift being the fast compiler for cases where the
program just wants to start drawing without waiting for optimizations to
run. LLVM and GCC are designed to take a lot more time to optimize the
> > OpenGL is at a higher level of abstraction and very complex to implement
> > due to about 20 years of backwards compatibility and feature
> > so Mesa translates it to Gallium, which is what the drivers implement.
> And this is where Zink comes into the picture
> > The Vulkan drivers in Mesa don't use Gallium (for at least RADV and ANV,
> > don't know for the others) since Vulkan is at about the same level of
> > abstraction, they instead translate directly to the different drivers'
> > internal calls.
> I get what you're saying but if I remember correctly from previous
> discussion on mailing list, you will have to use a modified backend
> compiler for Libre RISC-V right?
yes, we're planning on modifying LLVM to support all the new vector
instructions and probably some new ABIs for faster shader execution. This
will be going into upstream LLVM.
> I found this complicated chart on an irc channel:
> (honestly, the linux graphics stack evolves super fast every year,
> it's hard for me to keep up with all the developments)
> So from your description, Kazan is about the same place as radv on
> that chart?
yes, except we're not using NIR and Kazan goes before where NIR is as well
as where the graphics hardware is, since Kazan handles stuff that is taken
care of by the command stream executor (or whatever they call that) on
And the backend is a separate thing from Kazan if I
> understand you.
yes, though closely related.
More information about the libre-riscv-dev