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

[Luke Kenneth Casson Leighton]

On Sunday, September 15, 2019, Jacob Lifshay <programmerjake at gmail.com>
wrote:

> On Fri, Sep 13, 2019 at 1:38 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > 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
>
> I was planning on scalar being implemented as vectorizing to length=1
> vectors.
> >
> > 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
>
> I was planning on just basing the code on the upstream LLVM backend
> for RISC-V (which recently graduated from experimental).
>
> I was planning on relying on LLVM's vector-to-scalar lowering pass for
> handling vectorized code on just RV64GC (which we need anyway due to
> SPIR-V having it's own vectors).
> >
> > 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.
>
> One difference that there could be is that I've been designing Kazan
> around shaders that are always vectorized (needed for implementing
> control barriers and screen-space derivatives, which are required by
> Vulkan),


And the information has to be "dropped" or can LLVM handle it?


>
> whereas I would expect that Robin's code is more of
> opportunistic vectorization rather than guaranteed vectorization.


Ok.  Hmm hmm


>
>
> Adapting amdgpu would probably be even more work than writing it from
> scratch, since amdgpu's backend is tightly integrated into their ISA.


I wws thinking in terms of either replacing libpal or just replacing the
LLVM to amdgpu compilation phase entirely.

>
> > 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.
>
> Note that Mesa's amd drivers usually uses upstream LLVM, which works
> fine: RadeonSI (the Mesa OpenGL driver) is often faster than AMD's
> proprietary driver.


Funny :)


> >
> > 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.
>
> I think it would be much smaller than that, maybe 6-7 months once I
> resume working on Kazan full time.


Ok.  That's doable.


>
> Part of why I think it's better to have the vectorization in Kazan's
> codebase rather than LLVM, is that SPIR-V has some structural
> invariants that the vectorizer requires that LLVM doesn't maintain on
> non-GPU targets (x86 and RISC-V in particular).


Hmmmm


> Rebuilding those
> structural invariants could easily double the amount of work required.


Really? That's very interesting. It makes sense. It was probably why SPIRV
was done in the first place.

(the AMDGPU backend tells the rest of LLVM to maintain those
> invariants).


>
Why would our processor be considered a second rate citizen? As in, if AMD
can do it, so can we.

So if we chop the code off at just the SPIRV to LLVM compiler, it puts the
relevant invariant signals into the LLVM IR, by modifying the RISCV LLVM
JIT we get it to maintain them.

But not for a first version.

First version just "get something working".


I don't think LLVM would look kindly on doubling the
> number of x86 targets just because I want a GPU variant,


How would the number of x86 variants be increased by a RISCV processor?
Apologies, don't follow here.


>
> and Debian
> definitely wouldn't want to use a non-upstream version of LLVM.


Indeed.


>
> One other factor is that having the vectorization in Kazan allows
> vectorized code to be generated with different compilers as backends,
> such as GCC or Cranelift. Cranelift in particular I think is important
> to have as a backend down the road because it compiles code easily
> tens of times faster than LLVM, simply because LLVM is more targeted
> as a ahead-of-time compiler and therefore runs lots of expensive
> optimizations as part of code generation.


Whoops.


>
> Cranelift, by contrast, is
> more for fast compilation when you want to quickly get a shader binary
> that works and a slower compiler can be used in the background to make
> a better shader binary.


Interesting approach.


>
> This is important for program start-up time
> reduction (important enough that Valve(?) is currently developing
> another AMDGPU shader compiler specifically because LLVM is slow).



https://www.phoronix.com/scan.php?page=news_item&px=Valve-ACO-Radeon-Shader-Compile

What about using their work?  Or is it not Vulkan? I thought i saw,signs
that it is.

I am still in two minds on this one. I can see a case going either way.

Let's keep exploring ok?

L.



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