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

[Jacob Lifshay]

I will be commenting on this once I can use my computer -- currently
traveling.

On Sun, Sep 22, 2019, 14:37 Michael Pham <pham.michael.98 at gmail.com> wrote:

> 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
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>