[Libre-soc-dev] Intro

[Luke Kenneth Casson Leighton]

On Mon, Mar 8, 2021 at 2:42 PM vivek pandya <vivekvpandya at gmail.com> wrote:
>
> Hello Eduardo,
>
> I am happy to help you get started!
>
> Here is source code
> https://git.libre-soc.org/?p=mesa.git;a=shortlog;h=refs/heads/libresoc_dev
>
> From this bug (Thanks to Cole!)
> https://bugs.libre-soc.org/show_bug.cgi?id=472 you should get all required
> help to setup development environment I am using.
>
> At very high level the project aims ( Luke please correct if required) to
> experimental driver which can allow testing libresoc instruction on desktop
> environment till a simulator/silicon is available.

actually, ultimately i want it to run *in* a simulator (power-gem5)
where we will then experiment by implementing *actual* (simulated)
opcodes that the NIR/LLVM-IR/ppc64 would *actually* use.

for example, we would add a hardware-simulated SIN opcode, then modify
LLVM-IR to emit that, then (going back down the chain) modify the
MESA-3D Vulkan driver that you're doing to emit that too, and so on.

*then* we check, in the simulator, if performance actually increases
or not.  if it does, we implement it in HDL and, ultimately, try it
out in an FPGA.  that's all under future bugs, listed here:
https://bugs.libre-soc.org/show_bug.cgi?id=140#c0

repeat, repeat, repeat.

> So this is software rasterizer based on mesa environment.

the critically important thing here is that the Vectorisation Contexts
(predication, swizzle, vec2/3/4) are preserved *right* the way through
to LLVM-IR.  this is really really important.  all the other Vulkan
Soft-Shader Compilers (google SwiftShader) **DESTROY** that
information as quickly as possible.

the roadmap is, here:

* software renderer in LLVM-IR/x86
* software renderer in LLVM-IR/ppc64 (OpenPOWER v3.0)
* software renderer in LLVM-IR/ppc64-with-Simple-V including
predication, Cray-style Vectors, swizzle and vec2/3/4
* software renderer in LLVM-IR/ppc64-with-Simple-V *with custom 3D opcodes*

at *all times* it appears to be a software renderer.  but it is
actually a software renderer with a 3D augmented Vector ISA

> where currently
> everything is just done on CPU (like storing image memory in simple array
> rather than access it on actual HW through linux abstraction)
> And hopefully when this becomes more mature we have switches at few places
> like MapMemory etc so that we can execute things on actual HW.

at some point we will need to add special Texture Cache and LOAD/STORE
instructions to the custom OpenPOWER opcodes.  this because Texture
LD/ST is so data heavy it will overload the normal L1 and L2 cache for
no good reason.

> Current Status:
> I am trying to run
> https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-3.html
> and as of now I can run part 2 which just displays a simple color in the
> window.
> The Driver can generate NIR/LLVM/x86  assembly for very simple shaders.

fantastic!  this is brilliant, and worthwhile of a "declared completed
milestone" for which we can put in an NLnet donation for you.  can you
put in a bugreport under here:
https://bugs.libre-soc.org/show_bug.cgi?id=251

just put a single sentence and cross-reference this... y'know what?
i'll do it :)
https://bugs.libre-soc.org/show_bug.cgi?id=613

what - rouglhy - would you say percentage-wise we're towards 251 (the parent)?
https://bugs.libre-soc.org/show_bug.cgi?id=251

> We also need to think how actual HW will be represented and interact with
> the Linux environment (but yes that can be done later).

i'd like to get power-gem5 into shape enough so that compilation and
simulations can actually be done under that, even if it is horribly
slow, either producing images in the VM or firing up X-Windows
remotely, something, anything.


> Hope this helps!

this is great, Vivek.


l.