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

[Luke Kenneth Casson Leighton]

On Wed, Sep 25, 2019 at 5:15 AM Michael Pham <pham.michael.98 at gmail.com> wrote:
>
> While I'm waiting for Jacob to get back from his travels, Luke do you
> mind commenting?

can do the best i can.

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

honestly: i'd trust what AMD did to be feature-complete over something
created through reverse-engineering.

> > > 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.

good point.

> > > 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.

it'll need close and full investigation.

> > > 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?

yes.  as a hybrid CPU/VPU/GPU, instead of shipping all the function
call arguments, all the data, all the shader information, all the
images, all the triangles, all, all, all, all, everything over and
over and over again, via a shared-memory pipe, you... simply...
call... the.... instruction.

proprietary GPUs (with the exception of Ingenic X-Burst and
ICubeCorp's GPGPU architecture) are totally separate CPUs with their
own totally separate memory (or, in some cases, particularly embedded
GPUs, shared memory).

if you try to execute radeon GPU opcodes on an x86 or ARM processor,
it's pretty obvious what would happen.

to "protect" the GPU's communication channel with the CPU, the only
"safe" way to do that is: a kernel driver.

it's a god-awful mess, basically.

in a hybrid CPU/GPU/VPU, you... just... execute... the... instruction.

l.