[libre-riscv-dev] 3D Open Graphics Alliance

[lkcl]

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 
regard.

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

yes.

> So I agree with you that we should look at SPIR-V and the Vulkan ISA 
seriously. 
> 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 
space.

> 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 
proposal.

> From the SIGGRAPH BOF it was clear there are competing interests. Some 
people
> wanted explicit texture mapping instructions while others wanted HPC type
>  threaded vector extensions. 

interesting.

> Although each of these can be accommodated we need to adjudicate the 
location
> in the process pipeline where they belong - atomic ISA, higher-level ISA 
or 
> 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 
vectors.

l.