updates/012_2019jan19_summary.mdwn

   1 # Status so far, Jan 2019
   2
   3 So it's time, really, to do a "here's where we are so far" update.
   4
   5 In essence we plan to do an Out-of-Order multi issue engine that
   6 happens to have a hardware-version of a "Vector API" on it, and to throw
   7 elements of the vector at the instruction queue, then let the OoO engine
   8 sort it out.  We are just past the phase of capturing the design
   9 requirements, and are now onto the
  10 [requirements specification](https://libre-riscv.org/3d_gpu/requirements_specification/).  This is the phase in Software Engineering prior to beginning
  11 actual coding.
  12
  13 [Spectre Mitigation](https://groups.google.com/forum/#!topic/riscv-boom/yxDwmpjtQrE)
  14 is to be dealt with through the creation of
  15 [speculation "fence" (hint) instructions](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000346.html), which will need to be called
  16 by (privileged) software at any point it is about to begin the execution
  17 of untrusted code, whether that be in a syscall, a javascript execution
  18 environment, an interrupt, exception or context-switch: all these
  19 points need to ensure that the untrusted code gets to see an absolutely
  20 uniform (quiescent) state, every time.
  21
  22 We decided recently to use
  23 [migen](https://github.com/m-labs/migen) /
  24 [nmigen](https://github.com/m-labs/nmigen) , as the class-based
  25 Object Orientated features of python will be essential to keeping us
  26 sane. Verilog just does not have the flexibility we need, chisel is not
  27 mature enough, and python's software development and maintenance tools
  28 and paradigm are extremely comprehensive and well-established.
  29 We don't just want to design a 3D GPU: we'd like to design one that
  30 can be maintained, indefinitely, as well as be an educational tool.
  31
  32 After several months designing the Vector API
  33 [Simple-V](https://libre-riscv.org/simple_v_extension/specification/),
  34 and implementing it in
  35 [spike-sv](https://git.libre-riscv.org/?p=riscv-isa-sim.git;a=shortlog;h=refs/heads/sv),
  36 Jacob pointed out that the anticipated instruction
  37 code size reduction is unlikely to occur, as the "setup" cost is too high.
  38 In addition, the paradigm of a "stack-based" arrangement that alters
  39 the behaviour of future instructions, as opposed to a simpler "prefix"
  40 paradigm, is too innovative, whereas the "prefix" one is something
  41 that has been in use for some time in compiler technology.  We are
  42 in the process of working out a complementary
  43 [prefix scheme](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000316.html).
  44
  45 Jacob is doing a software LLVM driver implementing the Vulkan API,
  46 called [Kazan](http://salsa.debian.org/Kazan-team/kazan). This
  47 both guides and constrains what we do. For example there is an API Call
  48 that takes 4 32 bit ARGB floats and converts it to integer ARGB32. We
  49 will add a custom opcode that does the conversion, conforming to the
  50 API. Other aspects are, clearly, not as straightforward!
  51
  52 The key difference between this and commercial GPUs is that it is **not** a
  53 separate processor. Normally on MALI400, Vivante GC800, NVIDIA or AMDGPU
  54 you have an RPC mechanism that packs up the OpenGL arguments, ships them
  55 to the GPU and so on. We are **not** doing that: the 3D processing is done
  56 *by* the CPU [and the same CPU will do Video Processing as well].
  57
  58 Actually, it is the Vulkan SPIRV OpenCL compiler that does the heavy
  59 lifting. Someone in the Vulkan Working Group noticed that OpenCL (SPIRV)
  60 would be perfect to represent 3D shader algorithms. So Jacob is currently
  61 working on a SPIRV to LLVM IR compiler.  The fact that this driver (mostly
  62 a compiler) is written in Rust is irrelevant to performance, as the
  63 key parts (the 3D Shader Engine) are **directly** compiled to LLVM IR, which
  64 is then handed over to the LLVM JIT, which produces native assembly code.
  65 Contrast this with Gallium3D-LLVMpipe which **interprets** the 3D execution,
  66 and it becomes clear why we went with Vulkan instead of Gallium3D.
  67
  68 Daniel Benusovich is contributing part-time to the project: he has a
  69 couple of key interests as an HDL Engineer: an FPU, and an MMU that
  70 implements Virtual Memory (TLB).  These are self-contained projects
  71 that we can do without until later in the project: they are not on
  72 the critical path, and, interestingly, if properly designed, could
  73 be used by other projects as well.
  74
  75 We also have a new person who contacted us recently: Aleksander.  He is
  76 a self-taught engineer who decided he wanted to make a 3D GPU, and found
  77 this project.  Rather than do one on his own, he'd like to help out, which
  78 is great news.
  79
  80 The privacy aspects of this project - full transparency, full libre source
  81 for the software **and hardware** (with the possible exception of a
  82 DDR3/4 PHY), enabled us to apply for a special E.U. Grant from the nlnet
  83 Foundation.  The current call is
  84 ["Privacy and Trust Enhancing Technologies"](https://nlnet.nl/PET/).
  85 The call is sufficiently general that even though this is primarily a
  86 hardware project, the fact that it is being done entirely transparently
  87 and the HDL and full documentation and discussion is available **as it happens**
  88 is what enables us to apply.
  89
  90 Compare and contrast this even to many project labelled "Open" Source,
  91 that are run along the lines of, "We'll Release The Version 1.0 When It's
  92 Finished, No You Cannot Collaborate Or Help, Or See What Is Going On".
  93 How can it be trusted if we cannot see how it is being developed, and
  94 how decisions are being made?
  95
  96 So that's basically where things stand.  Lots going on, in a very short
  97 space of time.