[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 15 14:48:51 BST 2020


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

--- Comment #37 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to vivekvpandya from comment #36)
> I studies mesa source code for vulkan drivers and I have following very
> high-level plan (Note: we may face difficulties executing it)

that's ok.  evaluating and adjusting accordingly is fine.  this is a
research project.

> Step1: Testing Setup
>     This includes a Linux machine in which we can run vulkan tests through
> mesa built libvulkan_intel.so

we have sponsored access thanks to Raptor Engineering to a TALOS-II workstation
(24-core POWER9).  however being able to run generically - not depend on ppc
llvm - is partly a "nice side-goal" and partly "if there's something not
working on llvm ppc we don't want that to be a show-stopper"

> Step 2:
>     Start a simple project under mesa source tree which can create a simple
> libvulkan_ppc.so. However this lib will not actually do anything and on
> pipeline creation
>     it should just return some error code as VkResult. In this task we may
> start by just copying code for
> https://gitlab.freedesktop.org/mesa/mesa/-/tree/master/src/intel/vulkan abd
> then remove all files from meson.build and just keep minimal files which are
> required to create a broken pipeline. 

interesting.  i believe this was the approach taken originally on RADV,
and the Intel team - who designed NIR - are known to be very helpful and
approachable.

>     Here if possible we can create some mechanism such that we can move
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/amd/vulkan/
> radv_nir_to_llvm.c to common compiler folder.

this is a good idea, easily justified by the code-duplication that would
otherwise result.  a "temporary" solution which would help convince the
mesa developers of the need for that would be a file named
libresoc/vulkan/radv_nir_llvm.c containing this one line:

   "#include ../../amd/vulkan/radv_nir_llvm.c"

>     One possible thing is to have a simple file that maps NIR operations to
> target specific intrinsics for (AMDGPU, PPC) and use that in above code. 

oh that would be interesting.  trying AMDGPU as one of the (generic) targets
of libresoc-mesa.  it would involve adding the pipe system in (the system
which transfers LLVM-compiled binaries over to the radeon GPU) which is
not a high priority.  interesting all the same.


> Step6: Use LLVM's JIT capabilities to execute IR generated in Step5
> 
> After these steps we have a simple mesa driver working for COMPUTE shader.

fantastic.

one thing to note (for the record): unlike RADV (and AMDVLK), the resultant
binary, generated by Step 6, is *locally* executed, on the main processor
core (x86, ppc64).  RADV and AMDVLK use some sort of "pipe" library that
farms the (foreign architecture) binary over to the (separate) GPU.

jacob, what's your thoughts?

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


More information about the libre-soc-bugs mailing list