[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 #32 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to vivekvpandya from comment #31)
> (In reply to Luke Kenneth Casson Leighton from comment #30)
> > (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
> > 
> This is due to my very little knowledge about Mesa sw structure.
> 
> When I said complete MESA driver what I mean is everything from scratch.
> But I tried to get some information about MESA system.

it provides a common "meeting place" of disparate ideas, presenting a uniform
top level API and redirecting to different subsystems with translators that
again share common APIs.



> Now to me it seems that if we want to use MESA based driver, we must use
> open source code that gets upto NIR (or Gallium).

a better way to put it is that MESA *provides* that code, already written, so
that we do not have to.

(in addition for example there is someone else working on a library that
converts OpenGL to Vulkan.  it is i believe a MESA plugin).



> After that we have few options:
> 
> LLVMPipe (note official document claims to be multi-threaded and fastest,
> also that it can generate code for ppc):

> x86-64, or ppc64le machine code. Also, the driver is multi-threaded to take
> advantage of multiple CPU cores (up to 8 at this time). 

hmmm so jacob, where is the limitation that you noted in llvmpipe?

> OpenSWR:
> For OpenSWR its official FAQ page claims that to get it generate PPC code
> non trivial amount of work is required.

it also says that it is an OpenGL driver, and we definitely want to do Vulkan.


> Option3:
> Write a NIR to LLVM IR translator (or we can use code from above two
> components)
> and use LLVM's JIT to run that code on x86/PPC.

option 4

start from an existing NIR to LLVM IR translator (RADV), take out amdgpu
specific intrinsics and replace them

option 5

keep the existing RADV NIR to LLVM IR translator as-is as much as possible and
augment LLVM IR with translation passes that turn special amdgpu vector
intrinsics into generic scalar ones.

later (Phase 2) replace those special translation passes into
POWER9-SimpleV-augmented ones


> So we must note limitations of LLVMPipe so that we have record for why not
> choosing that.

indeed.  in particular we need to establish (and this is highly likely) if the
same design assumptions were made in llvmpipe that were also made in
SwiftShader.

namely: the hypothesis is that the inherent assumption was that because the
target was a software-only renderer where all target hardware was known to be
incapable of supporting vectors, vec2/3/4, predication, swizzle, texturisation
operations and more, llvmpipe was designed to eliminate these capabilities as
quickly as possible and to "fall" onto standard SIMD and scalar capability.

jacob has established that NIR preserves these types of 3D specialist
intrinsics, and as a gallium driver i would be very surprised if llvmpipe also
preserved them.

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