From: Luke Kenneth Casson Leighton Date: Sat, 19 Jan 2019 11:43:43 +0000 (+0000) Subject: add summary update X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=6f73fee42a281bd74404a0fc852ad5574f266414;p=crowdsupply.git add summary update --- diff --git a/updates/012_2019jan19_summary.mdwn b/updates/012_2019jan19_summary.mdwn new file mode 100644 index 0000000..b3eab8f --- /dev/null +++ b/updates/012_2019jan19_summary.mdwn @@ -0,0 +1,97 @@ +# 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.