[libre-riscv-dev] 3D Open Graphics Alliance
luke.leighton at gmail.com
Mon Aug 12 04:17:12 BST 2019
On Sunday, August 11, 2019 at 6:35:05 PM UTC+1, Jacob Lifshay wrote:
Atif Zafar asked me to post the following observations:
> A couple of observations reading the past set of emails:
> 1. Vulkan is the future of 3d graphics. It provides the lowest level
access to graphics hardware of any API
and was originally just OpenCL. 3D support was added as an extension.
> 2. Much of the functionality of other APIs - WebGL, OpenGL, OpenGL/ES,
DirectX etc. can be built on top of Vulkan and there are efforts to this
there have been two libre/open projects spotted that provide "gateways" via
Vulkan to OpenGL. one, interestingly, is a Vulkan-to-Gallium3D adapter, the
other is a straight (direct) OpenGL-to-Vulkan adapter.
both are strategically important in that they significantly reduce the
coding effort required to make any industry-standard open effort
"immediately useful". later efforts can build on the gateways, optimising
them to get better performance whilst still being able to sell product.
> 3. High level features such as graphics pipeline commands - i.e. single
plane 3d clipping of triangles - need to be built in a higher level API
> So I agree with you that we should look at SPIR-V and the Vulkan ISA
> Now that ISA is very complex and many of the instructions may possibly be
> reconstructed from simpler ones.
yes. as the slides from SIGGRAPH2019 show, the number of opcodes needed is
enormous. Texturisation, mipmaps, Z-Buffers, texture buffers,
normalisation, dotproduct, LERP/SLERP, sizzle, alpha blending,
interpolation, vectors and matrices, and that's just the *basics*!
further optimisations will need to be added over time, as well.
the pressure on the OP32 space is therefore enormous, given that "embedded"
low-power requirements cannot be met by moving to the 48 and 64 bit opcode
> We need to thus perhaps look at a "minimized" subset of the Vulkan ISA
> instructions that truly define the atomic operations from which the full
> ISA can be constructed. So the instruction decode hardware can implement
> this "higher-level ISA" - perhaps in microcode - from the "atomic ISA"
> at runtime while hardware support is only provided for the "atomic ISA".
yes. a microcode engine is something that may be useful in other
implementations as well (for other purposes) so should i feel be a separate
> From the SIGGRAPH BOF it was clear there are competing interests. Some
> wanted explicit texture mapping instructions while others wanted HPC type
> threaded vector extensions.
> Although each of these can be accommodated we need to adjudicate the
> in the process pipeline where they belong - atomic ISA, higher-level ISA
> higher-level graphics library.
OpenCL compliance is pretty straightforward to achieve. it could be done
by any standard supercomputer Vector Compute Engine.
a good Vector ISA does ***NOT*** automatically make a successful GPU (cf:
MIAOW, Nyuzi, Larrabee).
3D Graphics is ridiculously complex and comprehensive, and therefore
requires careful step-by-step planning to meet the extremely demanding and
heavily optimised de-facto industry-standard expectations met by modern
GPUs, today (fixed-functions are out: shader engines are in).
we took the strategy with the Libre RISC-V SoC to do a Vulkan SPIR-V to
LLVM-IR compiler for very good reasons.
firstly: that our first milestone - operational compliance on *x86* LLVM -
removes the possibility of hardware implementation dependence or bugs, and
gets us to a "known good" position to move to the next phase. like MesaGL,
it also makes a good Reference Implementation.
secondly: to begin an *iterative* process of adding in hardware
acceleration, associated SPIR-V opcode support and associated LLVM-IR
compiler support for the same, one opcode or opcode group at a time.
by evaluating the performance increase at each phase, depending on Alliance
Member customer requirements, we can move forward quickly and in a useful
and quantitatively-measureable fashion, meeting (keeping) the Khronos
Group's Conformance in mind at *every* step.
some of the required opcodes are going to be blindingly obvious (the
transcendentals and trigonometrics), others are going to be both harder to
implement, requiring significant research to track down, more than
anything. Vulkan's "Texture" features are liberally sprinkled throughout
the spec, for example, and the data structures used in the binary-formatted
texture data need to be tracked down.
other opcodes will be critically and specifically dependent on the
existence of Vector and in some cases Matrix support. Swizzle is
particularly challenging as in its full form it requires a whopping 32 bits
of immediate data, in order to cover a 3-arg operand if used with 4-long
More information about the libre-riscv-dev