[libre-riscv-dev] porting AMDVLK to the Libre RISC-V 3D GPU: NLNet EUR 50, 000 Grant application
pham.michael.98 at gmail.com
Wed Sep 25 05:14:49 BST 2019
While I'm waiting for Jacob to get back from his travels, Luke do you
On Sun, Sep 22, 2019 at 4:54 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
> I will be commenting on this once I can use my computer -- currently
> 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
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
More information about the libre-riscv-dev