# Status so far, Jan 2019

So it's time, really, to do a "here's where we are so far" update.

In essence we plan to do an Out-of-Order multi issue engine that
happens to have a hardware-version of a "Vector API" on it, and to throw
elements of the vector at the instruction queue, then let the OoO engine
sort it out.  We are just past the phase of capturing the design
requirements, and are now onto the
[requirements specification](https://libre-riscv.org/3d_gpu/requirements_specification/).  This is the phase in Software Engineering prior to beginning
actual coding.

[Spectre Mitigation](https://groups.google.com/forum/#!topic/riscv-boom/yxDwmpjtQrE)
is to be dealt with through the creation of 
[speculation "fence" (hint) instructions](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000346.html), which will need to be called
by (privileged) software at any point it is about to begin the execution
of untrusted code, whether that be in a syscall, a javascript execution
environment, an interrupt, exception or context-switch: all these
points need to ensure that the untrusted code gets to see an absolutely
uniform (quiescent) state, every time.

We decided recently to use
[migen](https://github.com/m-labs/migen) /
[nmigen](https://github.com/m-labs/nmigen) , as the class-based
Object Orientated features of python will be essential to keeping us
sane. Verilog just does not have the flexibility we need, chisel is not
mature enough, and python's software development and maintenance tools
and paradigm are extremely comprehensive and well-established.
We don't just want to design a 3D GPU: we'd like to design one that
can be maintained, indefinitely, as well as be an educational tool.

After several months designing the Vector API
[Simple-V](https://libre-riscv.org/simple_v_extension/specification/),
and implementing it in
[spike-sv](https://git.libre-riscv.org/?p=riscv-isa-sim.git;a=shortlog;h=refs/heads/sv),
Jacob pointed out that the anticipated instruction
code size reduction is unlikely to occur, as the "setup" cost is too high.
In addition, the paradigm of a "stack-based" arrangement that alters
the behaviour of future instructions, as opposed to a simpler "prefix"
paradigm, is too innovative, whereas the "prefix" one is something
that has been in use for some time in compiler technology.  We are
in the process of working out a complementary
[prefix scheme](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000316.html).

Jacob is doing a software LLVM driver implementing the Vulkan API,
called [Kazan](http://salsa.debian.org/Kazan-team/kazan). This
both guides and constrains what we do. For example there is an API Call
that takes 4 32 bit ARGB floats and converts it to integer ARGB32. We
will add a custom opcode that does the conversion, conforming to the
API. Other aspects are, clearly, not as straightforward!

The key difference between this and commercial GPUs is that it is **not** a
separate processor. Normally on MALI400, Vivante GC800, NVIDIA or AMDGPU
you have an RPC mechanism that packs up the OpenGL arguments, ships them
to the GPU and so on. We are **not** doing that: the 3D processing is done
*by* the CPU [and the same CPU will do Video Processing as well].

Actually, it is the Vulkan SPIRV OpenCL compiler that does the heavy
lifting. Someone in the Vulkan Working Group noticed that OpenCL (SPIRV)
would be perfect to represent 3D shader algorithms. So Jacob is currently
working on a SPIRV to LLVM IR compiler.  The fact that this driver (mostly
a compiler) is written in Rust is irrelevant to performance, as the
key parts (the 3D Shader Engine) are **directly** compiled to LLVM IR, which
is then handed over to the LLVM JIT, which produces native assembly code.
Contrast this with Gallium3D-LLVMpipe which **interprets** the 3D execution,
and it becomes clear why we went with Vulkan instead of Gallium3D.

Daniel Benusovich is contributing part-time to the project: he has a
couple of key interests as an HDL Engineer: an FPU, and an MMU that
implements Virtual Memory (TLB).  These are self-contained projects
that we can do without until later in the project: they are not on
the critical path, and, interestingly, if properly designed, could
be used by other projects as well.

We also have a new person who contacted us recently: Aleksander.  He is
a self-taught engineer who decided he wanted to make a 3D GPU, and found
this project.  Rather than do one on his own, he'd like to help out, which
is great news.

The privacy aspects of this project - full transparency, full libre source
for the software **and hardware** (with the possible exception of a
DDR3/4 PHY), enabled us to apply for a special E.U. Grant from the nlnet
Foundation.  The current call is
["Privacy and Trust Enhancing Technologies"](https://nlnet.nl/PET/).
The call is sufficiently general that even though this is primarily a
hardware project, the fact that it is being done entirely transparently
and the HDL and full documentation and discussion is available **as it happens**
is what enables us to apply.

Compare and contrast this even to many project labelled "Open" Source,
that are run along the lines of, "We'll Release The Version 1.0 When It's
Finished, No You Cannot Collaborate Or Help, Or See What Is Going On".
How can it be trusted if we cannot see how it is being developed, and
how decisions are being made?

So that's basically where things stand.  Lots going on, in a very short
space of time.