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

[Luke Kenneth Casson Leighton]

On Thursday, January 9, 2020, Jason Ekstrand <jason at jlekstrand.net> wrote:

> Drive-by comment:
>

really appreciate the feedback.


>  I don't think you actually want to base any decisions an a vec4
> architecture. Nearly every company in the graphics industry thought that
> was a good idea and designed vec4 processors. Over the course of the last
> 15 years or so they have all, one by one, realized that it was a bad idea
> and stopped doing it. Instead, they all parallelize the other way and their
> SIMD instructions and on scalar values across 8, 16, 32, or 64 invocations
> (vertices, pixels, etc.) Of the shader program.
>

for simplicity (not outlining nearly 18 months of Vector Architecture ISA
development) i missed out that we have designed a vector-plus-subvector
architecture, where the subvectors may be of any length between 1 and 4,
and there is an additional vector loop around that which may be from length
1 (scalar) to 64

individual predicate mask bits may be applied to vector however they may
only be applied (one bit) per subvector.

discussions have been ongoing for around 2 years now on the LLVM dev lists
to support this type of concept.

on the libre soc lists we have also had detailed discissions on how to do
swizzles at the subvector level.

AMDGPU, NVIDIA, MALI, they all support these capabilities.

to be clear: we have *not* designed an architecture or an ISA which
critically and exclusively depends on vec4 and vec4 alone.

now, whether it is a bad idea or not to have vec2, vec3 snd vec4
capability, the way that i see it is that Vulkan supports them, as does the
SPIRV compiler in e.g. AMDVLK, and we would be asking for trouble
(performance penalties, compiler complexity due to having to add predicated
autovectorisation) if we did not support them.

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)

2. as a flexible Vector Processor, soft-programmable, then over time if the
industry moves to dropping vec4, so can we.



> That isn't too say that Mesa is there wrong choice or that there aren't
> other reasons why SwiftShader would be a bad fit. However, I would
> recommend against making major architectural decipmentsions for the sole
> reason that it allows you to repeat one of the biggest architectural
> mistakes that the graphics industry as a whole managed to make and is only
> recently (last 5 years) finally gotten over.
>

consequently i am extremely grateful as the last thing we need is to spend
NLNet funds on repeating industry mistakes.

this is why i love libre hardware.  can you imagine the hell it would have
taken to get you signing an NDA just to be able to provide the insight that
you did?

:)

warmest,

l.



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