[Libre-soc-bugs] [Bug 251] Initial 3D MESA non-accelerated software-only driver is needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=251

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
one of the important things to understand about the hardware and therefore
the driver is that the GPU opcodes and the Vectorisation is part of the
*native* CPU instruction set.

here is what swiftshader "looks" like:

* SPIR-V IR
* total removal of all predication, vectorisation "pass"
* handing over to LLVM-IR
* compilation of LLVM-IR to *native* CPU binary (NEON/SSE SIMD etc)
* execution of the resultant binary in the *CPU* space


here is what AMDVLK / Intel GPU / NVidia GPU looks like:

* SPIR-V IR
* preservation of predication, vectorisation
* handing over to LLVM-IR (or other vector-preserving IR)
* compilation of IR to **GPU** binary instruction set
* massively-complex inter-processor communication system (via kernel drivers)
  ...
  ...
* finally at long last execution of the resultant vectorised binary on the GPU


here is what *we* need (ultimately - as part of issue #140):

* SPIR-V IR
* preservation of predication, vectorisation
* handing over to LLVM-IR (or other vector-preserving IR)
* compilation of IR to *NATIVE CPU BINARY WHICH HAPPENS TO HAVE GPU OPCODES*
* execution of the resultant binary in the >>***CPU***<< space


however what we decided to do is to break this down into separate phases.
the first phase is to *not* try to add GPU opcodes... yet.  the first
phase is to make a driver that is ***like*** google SwiftShader but is
*not* google SwiftShader, i.e. it is this:

* SPIR-V IR
* preservation of predication, vectorisation
* handing over to LLVM-IR (or other vector-preserving IR)
                       vvvvvvv this is the only difference vvvv
* compilation of IR to NATIVE CPU BINARY which does **NOT** have GPU OPCODES
                       ^^^^^^^                             ^^^^
* execution of the resultant binary in the >>***CPU***<< space


the only difference between the "software-only" version and the "final" version
is that we may use *upstream* stock and standard LLVM for x86, ARM, POWER9 and
consequently have far less work to do.

zero optimisations of any kind.  zero work on LLVM itself.

however - and this is the important bit - the initial "software-only" driver
preserves the predication and vectorisation information *right* up until
it is handed to that stock-and-standard LLVM.

*later* - under a separate bugreport - we will replace that stock-and-standard
LLVM with a special version of LLVM that has been augmented to understand
the GPU opcodes, vectorisation and predication that we will be adding.

i anticipate and expect that if correctly designed (the predication and
vectorisation correctly preserved right up until hand-over to LLVM-IR) that
when we do this later task, there should be zero (or negligeable, or trivial)
modifications required to the 3D MESA driver developed under this bugreport.


the reason why we decided already not to go with SwiftShader is because the
entire codebase is specifically targetted at removing the SPIR-V predication
and vectorisation (including vec2/3/4) as quickly as possible.

modifying SwiftShader or trying to use it would result in constant fights with
google's engineers along the lines of "why are you submitting patches for a
hardware 3D GPU, this is a software GPU driver, please go away" and we would
have to do a full hard fork of it and become the only maintainers.

the intention here is that this code be *fully* upstream in MESA.

-- 
You are receiving this mail because:
You are on the CC list for the bug.