-Intriguing Ideas
+# Intriguing Ideas
Pixilica starts a 3D Open Graphics Alliance initiative;
We decide to go with a "reconfigurable" pipeline;
+Seven additional EUR 50,000 NLNet Grant proposals submitted.
# The possibility of a 3D Open Graphics Alliance
The current 3D GPU designs - NVIDIA, AMD, Intel, are hugely optimised
for mass volume appeal. Niche markets, by virtue of the profit
opportunities being lower or even negative given the design choices of
-the incumbents, are inherently penalised. Not only that but the source
-code of the 3D engines is proprietary, meaning that anything outside of
-what is dictated by the incumbents is out of the question.
+the incumbents, are inherently penalised. Not only that: whilst things are
+slowly changing due to ongoing multi-man-year reverse-engineering efforts,
+3D driver source code is often proprietary as well.
At the BoF, one attendee described how they are implementing *transparent*
shader algorithms. Most shader hardware provides triangle algorithms that
3D and kick start some real innovation.
These were the challenges discussed at the upcoming first
[meetup](https://www.meetup.com/Bay-Area-RISC-V-Meetup/events/264231095/)
-at Western Digital's Milpitas HQ. Experts in 3D at the Meetup were really
-enthusiastic and praised this approach.
+at Western Digital's Milpitas HQ. Experts at the Meetup, from the 3D
+Industry who have worked for decades for ATI, NVIDIA and Intel, were
+really enthusiastic and praised this approach, saying that it was exactly
+the kind of shakeup the 3D Industry needs.
# Reconfigureable Pipelines
escalator.
The problem comes when you want to vary the clock speed. This is desirable
-because if the pipeline is long and the clock rate is slow, the latency
+because if the pipeline is long and the clock rate is slow, clearly the latency
(completion time of an instruction) is also long.
Conversely, if the pipeline is short (large numbers of gates connected
together) then as mentioned above, this can inherently limit the maximum
-frequency that the processor could run at.
+frequency that the processor could run at, because due to the "ripple" effect
+in each pipeline stage, a longer chain of gates clearly has to have a longer
+time to stabilise.
What if there was a solution which allowed *both* options? What if you
-could actually reconfigure tge pipeline to be shorter or longer?
+could actually reconfigure the pipeline to be shorter or longer?
It turns out that by using what is termed "transparent latches" that it
is possible to do precisely that. The advantages are enormous and were
[this thread](https://groups.google.com/d/msg/comp.arch/fcq-GLQqvas/SY2F9Hd8AQAJ),
someone kindly pointed out that IBM published
papers on the technique. Basically, the latches normally present in the
-pipeline have a combinatorial "bypass" in the form of a Mux. The output
-is dynamically selected from either the input *or* the input after it
-has been put through a flip-flop. The flip-flop basically stores (and
-delays) its input for one clock cycle.
+pipeline have an additional combinatorial "bypass" in the form of a
+Mux. The output is dynamically selected from either the input *or* the
+input after it has been put through a flip-flop. The flip-flop basically
+stores (and delays) its input for one clock cycle, or it can be bypassed
+i.e. just be another part of that "ripple" effect mentioned earlier.
By putting these transparent latches on every other combinatorial stage
in the processing chain, the length of the pipeline may be halved, such
that when the clock rate is also halved the *instruction completion time
remains the same*.
-Normally if the processor speed were lowered it would have an adverse
-impact on instruction latency.
+As described earlier, normally if the processor speed were lowered it
+would have an adverse impact on instruction latency. With the transparent
+latches bypassed and with plenty of time to stabilise at the lower speed,
+two back-to-back stages now comprise a *single* pipeline stage, and thus,
+even if the processor speed is halved,
+*so is the length of the overall pipeline* and thus the instruction
+completion time remains the same.
It's a fantastic idea that will allow us to reconfigure the processor
-to reach a 1.5ghz clock rate for high performance bursts.
+either to reach a 1.5ghz clock rate for high performance bursts, or to
+run at 800mhz in reduced power mode.
# NLNet Funding proposals.
libswscale, libx264 etc. ultimately for use in VLC and ffmpeg and so on.
Best of all, two for actually doing a test ASIC: one working with
-chips4makers, the other with lip6.fr. It turns out that 180nm ASIC shuttle
+[chips4makers](http://chips4makers.io/blog), the other with
+[lip6.fr](https://www-soc.lip6.fr/en/). It turns out that 180nm ASIC shuttle
services cost only USD 600 per square mm, and we can get away with around
20 sq.mm which is about USD 12,000 and estimated 800,000 gates.
benefit from this project being a reality, sponsorship, via NLNet,
is tax deductible because it is a charitable donation.
+(Update: covered in a
+[Slashdot](https://hardware.slashdot.org/story/19/09/29/1845252/libre-risc-v-3d-cpugpu-seeks-grants-for-ambitious-expansion#comments)
+article)
projects / crowdsupply.git / blobdiff