[libre-riscv-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

[Luke Kenneth Casson Leighton]

On 1/9/20, Jason Ekstrand <jason at jlekstrand.net> wrote:

> Hopefully that makes the trade-off make more sense.  One other important
> factor is that, even if vec4 could, in theory, be more efficient, it's way
> easier to write a compiler if you scalarize everything.

hi jason, really appreciated the additional insight.  to explain:
we're going with an entirely innovative microarchitecture that has
(i'm leaving out a lot of details here) a Cray-style variable-length
vector front-end, a SIMD back-end (with predication), and multi-issue
decode which can *automatically* allocate and translate between the
two under a lot of conditions.

i got some kind assistance from Mitch Alsup at the beginning of last
year, where he outlined for me how the CDC 6600 really works, and how
to turn it into a multi-issue engine with very little extra effort
(basically apart from ramping up the ALUs, memory bandwidth and
register file ports, then unlike with the Tomasulo algorithm, to add
multi-issue to a a pure 6600 style Dependency Matrix is trivial)

if it's ok with you i'll let Jacob Lifshay explain, as he has been
designing and writing the Kazan driver for some time (Kazan is a
from-scratch SPIR-V to LLVM IR Shader Compiler, in rust).

> however, there are two nice things:
>>
>> 1. we are at an early phase, therefore we *can* evaluate valuable
>> "headsup" warnings such as the one you give, jason (so thank you)
>>
>
> Hooray!

:)


>> 2. as a flexible Vector Processor, soft-programmable, then over time if
>> the industry moves to dropping vec4, so can we.
>>
>
> That's very nice.  My primary reason for sending the first e-mail was that
> SwiftShader vs. Mesa is a pretty big decision that's hard to reverse after
> someone has poured several months into working on a driver and the argument
> you gave in favor of Mesa was that it supports vec4.

not quite :)  i garbled it (jacob spent some time explaining it, a few
months back, so it's 3rd hand if you know what i mean).  what i can
recall of what he said was: it's something to do with the data types,
particularly predication, being maintained as part of SPIR-V (and
NIR), which, if you drop that information, you have to use
auto-vectorisation and other rather awful tricks to get it back when
you get to the assembly level.

jacob perhaps you could clarify, here?

>  Personally, I'm still a fan of Mesa. :-)  I also won't
> hold it against anyone if they like SwiftShader; it's a neat project too.

it is... it's just... google is the number one contributor.  if there
were more (large) independent contributors, i'd be much more inclined
to view it favourably.  if they decided unilaterally that they "didn't
like our contributions", we'd have a hard fork on our hands.

l.