[libre-riscv-dev] porting AMDVLK to the Libre RISC-V 3D GPU: NLNet EUR 50, 000 Grant application

Michael Pham pham.michael.98 at gmail.com
Sun Sep 22 21:36:21 BST 2019

On Sun, Sep 22, 2019 at 11:25 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:

Hi Luke, I would like to ask for some clarification on this proposal
(see below).

> after speaking to Michiel from NLNet, i am looking to put in an
> additional grant application for EUR 50,000, so that charitable
> donations to developers are available in order to convert AMD's AMDVLK
> driver, replacing its amdgpu LLVM IR backend with one that outputs
> RISC-V assembler instead.  in stages, that will become vectorised
> assembler, and, later, will have special accelerated custom 3D opcodes
> (texturisation, OpenCL opcodes such as atan2 etc.) added as well.

> the technical details - starting point and plan - is as follows:
> * the code start-point is here: https://github.com/GPUOpen-Drivers/AMDVLK

Is there a specific reason you are basing it on the AMDVLK vulkan
driver instead of Mesa's RADV vulkan driver for amdgpu instead?

I'm asking because AMDVLK has a much smaller community around it and
the main developers are AMD themselves.
On the other hand, Mesa has a huge community of developers and users
around it. Many people working in the Linux graphics stack work on
RADV has many more users than AMDVLK because, well, Mesa ships by
default with it on many distributions. Also, many game developers
target and test
on RADV instead of AMDVLK because of the fact that RADV is the default
amd vulkan driver for linux and therefore has many more users.

So besides the qualities of being more widely-used (which means more
tested as an effect), it also gets all the optimizations and shared
code in Mesa.

If you're wondering why AMDVLK even exists, well it's because AMD
wanted to share driver code with their windows vulkan driver.

Also, as previously discussed on the mailing list, there were plans to
get OpenGL capabilities on Libre RISC-V by running Zink on top of
However, I found a source that says Zink only works on top of RADV
(and Intel's ANV) but not AMDVLK.
Source (page 5):

So from my limited understanding of the Linux graphics stack (please
feel free to correct my misunderstandings), it would be better to port
RADV instead of AMDVLK.
And if we do port RADV instead, it would supposedly be easier to
modify Zink to work with our driver.

> so we are *starting* from a software-only 3D driver, and then adding
> hardware-accelerated opcodes *to* that driver.  note very very
> specifically that there will *NOT* be an associated kernel driver
> involved here, nor will those instructions require special
> "privileges".  they will be literally callable just like any other
> opcode such as FMUL, FADD, and FDIV and so on.

Again, I have a very limited understanding of this low level graphics
stuff, but I thought all gpu's need a kernel driver? Is Libre RISC-V
different in that way?

Thanks in advance for clarifying.


More information about the libre-riscv-dev mailing list