[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 #30 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to vivekvpandya from comment #26)
> Writing complete MESA driver which uses LLVM to codegen seems very large
> effort. It is only worth if this driver is not just for experimental use.

can you expand on this insight a little?  the reason i ask is twofold

firstly, we have to be comprehensive in our analysis of existing software and
ecosystems (taking into consideration longterm maintenance).

therefore even if the answer turns out to be obvious, due to the audit and
transparency requirements we need to go over all options.

secondly, the reason why we picked to do a nonaccelerated nonvectorised general
purpose software-only shader is because apart from the lack of vectorisation
and custom 3D opcodes such a driver is relatively close to what is needed for a
hybrid CPU-GPU (a lot closer than dual ISA architectures, that is)

consequently whilst experimental, jacob and i when evaluating this driver
development strategy considered it a reasonable incremental stepping stone.

what we do not want to have to do is to develop the ISA *and* an ISA simulator
*and* the HDL *and* the driver *and* the LLVM IR backend all at the same time.

if instead we can get a working 3D nonaccelerated MESA driver that runs on
stable hardware we have an incremental code-morphing path where portions may be
independently developed and brought in one at a time.

* first target: MESA driver on x86
* second target: MESA driver on POWER9
* next: add 3D opcodes to POWER9 simulator
* next: augment LLVM to use new 3D opcodes
* next: alter MESA driver to generate LLVM intrinsics that will use new
opcodes.

if we attempt a nonincremental strategy the chances of success are extremely
remote.  a bug occurs and we have no idea whether it is in LLVM, or the MESA
driver, or the POWER9 simulator or the HDL, or even the 3D opcode.

if therefore it requires extra passes/steps or requires adding translation
layers to e.g. LLVM to get the AMDGPU vectorised intrinsics translated to
scalar x86 (or POWER9) and this code is later discarded then annoying as that
may be, so be it.

however i suspect that there will be quite some interest in the nonaccelerated
software vulkan compatible MESA driver in its own right, particularly given
that its job could effectively supplant SwiftShader if picked up by another
maintainer and suitably optimised to use SSE/AVX/NEON/VSX

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