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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Aug 8 12:14:28 BST 2020


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

--- Comment #20 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #19)
> (In reply to vivekvpandya from comment #18)
> > Why NIR is required?

it is not "required" however the amount if work to do something that does not
use NIR when it is integrated into MESA looks like it would be far longer a
project.


> > As per comment 3 we need to support a SPIR-V IR and
> > that can be through any API right? Also can we use something like
> > https://github.com/mesa3d/mesa/commits/master/src/gallium/drivers/llvmpipe
> > I have not checked it yet but that seems to have one more abstraction before
> > LLVM.

llvmpipe has severe design limitations which jacob is aware of the details, it
is hardcoded to single threaded in a critical area.  if we use it we will only
be able to use one single core, all others will run idle.


> 
> Because NIR has lots of GPU-specific optimization passes that LLVM doesn't,
> such as cross-shader optimizations. The rest of MESA is also already built
> to interact with NIR when it needs to read properties of the shaders.

so there basically already exists a full NIR parser, built-in to MESA.

what you are saying is, if we use llvm-spirv it would be necessary to do work
to *remove* the existing NIR support from MESA, it would then be necessary to
re-add the missing shader optimisation passes not present in llvm-spirv.

this tends to point in favour of starting from RADV, or the original intel 3D
driver.


> It is
> not built to do that with LLVM or with LLPC. Luke was oversimplifying
> somewhat.

yes, because i don't have a handle on the full details in ways that you do,
jacob.

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


More information about the libre-soc-bugs mailing list