# NL.net proposal

* [[questions]]
* NLNet Project Page <https://nlnet.nl/project/LibreSoC-Video/>
* 2019-10-031
* Top Level bugreport <http://bugs.libre-riscv.org/show_bug.cgi?id=137>

## Project name

The Libre-RISCV SoC, Video Acceleration

## Website / wiki 

<https://libre-riscv.org/nlnet_2019_video>

Please be short and to the point in your answers; focus primarily on
the what and how, not so much on the why. Add longer descriptions as
attachments (see below). If English isn't your first language, don't
worry - our reviewers don't care about spelling errors, only about
great ideas. We apologise for the inconvenience of having to submit in
English. On the up side, you can be as technical as you need to be (but
you don't have to). Do stay concrete. Use plain text in your reply only,
if you need any HTML to make your point please include this as attachment.

## Abstract: Can you explain the whole project and its expected outcome(s).

The Libre RISC-V SoC is being developed to provide a privacy-respecting
modern processor, developed transparently and as libre to the bedrock
as possible.  

One of the main "hardware accelerated blocks" of any processor intended for user applications is Video Encode and Decode. This usually means an opaque, proprietary piece of hardware, and it usually comes with proprietary firmware as well.

In a privacy-respecting world neither of these are acceptable, therefore the goal is to develop - in an iterative fashion - not just the software but the actual hardware instructions (similar to ARM NEON) which, if fully integrated into libswscale, ffmpeg, gstreamer and other software, would make RISC-V a truly commercially competitive peer of ARM and x86 systems when it comes to video acceleration.

With such capability freely available for any implementor, there would be no excuse for the inclusion of spying hardware blocks or coprocessors in modern RISC-V processors, and certainly not in the Libre RISC-V SoC.

# Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?

Luke Leighton is an ethical technology specialist who has a consistent
24-year track record of developing code in a real-time transparent
(fully libre) fashion, and in managing Software Libre teams.  He is the
lead developer on the Libre RISC-V SoC.


# Requested Amount    

EUR 50,000.

# Explain what the requested budget will be used for? 

The tasks, which will need to be iteratively applied, are as follows:

* to identify closely the key areas in video decode, across a wide range of algorithms, where a non-accelerated processor spends considerable CPU time and power consumption.
* to propose and then evaluate the instructions which, if included in RISC-V, would speed up video decode and reduce power consumption to within commercially competitive levels.
* to simulate those proposed instructions and confirm their viability
* to implement those instructions in actual hardware, for running in an FPGA
* to follow through with the upstream submission and acceptance of customisation of relevant software libre video decode projects and toolchains.

This needs to be done iteratively because it is only when a certain high level of functionality is reached (FPGA, full simulation) will it be possible to properly determine if the proposed instructions actually meet the full requirements. In addition it may turn out that further optimisation is needed.

# Does the project have other funding sources, both past and present?

The overall project has sponsorship from Purism as well as a prior grant
from NLNet.  However that is for specifically covering the development
of the RTL (the hardware source code).

There is no source of funds for the work on Video ISA development (only for its hardware implementation) or the follow through work which involves getting support for that ISA extension upstream in relevant software (ffmpeg, vlc, gstreamer) and toolchains (gcc, llvm, binutils)

# Compare your own project with existing or historical efforts.

There do exist on opencores a number of video encode and decode blocks: these are typically MPEG and h.264. However, the problem is that these are dedicated blocks, specific to those algorithms. They do not help with h.265, Theora, Dirac, vp8, vp9 and anything else that may come out.

Any instructions which exist for OpenRISC1200 or MIPS will not help either, because the instructions need to be evaluated specifically for RISC-V.

So the answer is: this initiative is unique, and there are no peer projects: the RISC-V initiative itself is too recent.

## What are significant technical challenges you expect to solve during the project, if any?

The actual process is technically quite straightforward, and given that
ffmpeg and so on are quite well established and platform independent,
the hotspot areas are typically already identified (CABAC, DCT,
Motion-estimation, YUV2RGB) and have NEON or SSE/AVX etc assembly
routines.

The main challenges will be communications, particularly as this is a huge cross project initiative, covering patches and additions to at least seven separate independent software projects, as well as requiring hardware development and simulations.

## Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?

The Libre RISC-V
SoC has a full set of resources for Libre Project Management and development:
mailing list, bugtracker, git repository and wiki - all listed here:
<https://libre-riscv.org/>

In addition, we have a Crowdsupply page
<https://www.crowdsupply.com/libre-risc-v/m-class> which provides a public
gateway, and heise.de, reddit, phoronix, slashdot and other locations have
all picked up the story.  The list is updated and maintained here:
<https://libre-riscv.org/3d_gpu/>

It will also be necessary to coordinate transparently across the RISC-V community resources, particularly when it comes to developing the ISA Extensions.

# Extra info to be submitted

* <http://libre-riscv.org/3d_gpu/>
* <https://nlnet.nl/project/Libre-RISCV/>
* <https://chips4makers.io/blog/>