--- /dev/null
+# 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.
projects / crowdsupply.git / commitdiff