[libre-riscv-dev] whole stack of vulkan llvm spirv stuff

[Luke Kenneth Casson Leighton]

The question of whether there is something unusual about either SV or SPIRV
which *requires* whole function vectorisation at the SPIRV levrl is
critical because:

1. scalar IR also needs to be an option.  This for ultra small embedded
systems that do not have vectorisation at all

2. The test environment, [ARM and/or] x86 assembler is one of the
milestones, this so we can incrementally move to RISCV assembler

3. The next phase is *scalar* RISCV assembler (related to 1) so that,
again, we do not have to fo too much at once. This phase to integrate
lowRISC LLVM backend work

4. The next phase, given that Robin Kruppe is being paid to do RVV, and it
almost *certainly* includes whole function vectorisation, and given that
RVV and SV are conceptually similar, is to replace RVV assembly code with
SV equivalents in a by-the-numbers fashion.

Right back at the beginning of this, the functions (vulkan compliance) that
AMD put in which ultimately go through to PAL, these are all REPLACED with
DIRECT functions written in straight c/c++/whatever, no messing about
sending RPC calls to a separate GPU.

These as a separate static/dynamic precompiked library that is linked to
the SPIRV compiled shader at runtime.

This approach I would be really genuinely surprised if we could not have
something up and running (scalar) in about 8 weeks flat, starting from the
amdgpu source.

Two unknowns are: how many functions need to be written which replace
libPAL with straight c/c++/whatever

and how much of llvm's other backends AMD left untouched from the cherry
picking that they have been doing.

They have added immediates for example which were only proposed in february
2019.

So that question is extremely important Jacob as it could cut the time to
first prototype literally by about 12 months.

L.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68