[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 #28 from Jacob Lifshay <programmerjake at gmail.com> ---
(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.
> 
> if we already agree that mesa llvmpipe has limitation then we may want to
> fix that.

that could be as complicated as writing a whole new Gallium driver, since a lot
of llvmpipe assumes that some parts are single threaded AFAIK.

> On side thought I would really like to evaluate that we really need all
> benefits from NIR optimizations. (if that is the only reason to bring NIR in
> flow)
> 
> Our enticipated flow:
> 
> Vulkan/OGL -> spirv -> (someIR)* -> LLVM -> LLVM Optimization and Codegen.

A future flow that could provide some major benefits:
(like the ACO backend for RADV which can provide >10% performance increase)
Vulkan/OpenGL -> NIR -> NIR optimizations -> Cranelift or similar (like ACO)

Cranelift and ACO are both waay faster than LLVM since they are designed more
for generating pretty good code quickly, rather than LLVM's approach of taking
waay longer to generate the best code.

In this case, NIR optimizations are critical for good performance since neither
Cranelift or ACO do any of the higher-level optimizations.

> so without having solid numbers on performance that we required NIR
> optimization I really would like to go AMDVLK fork that can generate ppc
> assembly.

There are other reasons not to go with an AMDVLK fork, such as Mesa being well
known to accept contributions, being friendly to Libre-software, having a good
community, generally being developed in the open (transparency), and being
installed on most Linux distros in the default install.

AMDVLK, by contrast, has effectively zero contribution other than AMD
employees, is developed in a closed manner (they publish new code every once in
a while, but the actual development process is mostly private), and it is
unknown if they will accept a port to a non-AMD GPU upstream (I'm guessing
not).

There is the other factor that RADV, when combined with ACO, is usually faster
than AMDVLK.

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