[libre-riscv-dev] presentation on graphics drivers & doing it right the first time

Jacob Lifshay programmerjake at gmail.com
Fri Oct 4 06:08:04 BST 2019


On Thu, Oct 3, 2019, 21:52 Michael Pham <pham.michael.98 at gmail.com> wrote:

> On Fri, Oct 4, 2019 at 12:44 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > more interesting things are likely to come out of xdc2019,
> unfortunately, I
> > can't spend 9hr a day watching the live stream.
>
> agreed, looking at the slides is more efficient use of time.
>
> By the way, I was reading some of the comments on that new Intel
> backend graphics compiler, and this comment specifically
>
> https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1130580-intel-has-been-quietly-developing-a-new-backend-compiler-for-their-opengl-vulkan-drivers?p=1130602#post1130602
> , made me wonder how Kazan fits into this? So using the terminology in
> that comment, is Kazan the driver model or backend compiler? Or both?
>

none of the above.

Vulkan is basically the driver model (API), it's actually quite similar to
Gallium.

Kazan is an implementation of both:
1. the translation layer from Vulkan to the internal memory structures and
shader invocations
2. the front end of the shader compiler

the backend compiler is part of LLVM, Cranelift, and/or GCC (the three
compilers I am planning on Kazan being able to use).

OpenGL is at a higher level of abstraction and very complex to implement
due to about 20 years of backwards compatibility and feature agglomeration,
so Mesa translates it to Gallium, which is what the drivers implement.

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.

Jacob


More information about the libre-riscv-dev mailing list