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

[Michael Pham]

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
>
(snip)

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
Mesa,
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
Vulkan.
However, I found a source that says Zink only works on top of RADV
(and Intel's ANV) but not AMDVLK.
Source (page 5):
https://archive.fosdem.org/2019/schedule/event/zink/attachments/slides/3311/export/events/attachments/zink/slides/3311/zink_fosdem19.pdf

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.

Michael