
Allwinner VPU support for the Linux kernel - throwaway000002
https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel
======
jagger27
Allwinner would be pretty foolish not to fully fund this endeavour (including
stretch goals). They couldn't do it themselves this cheap. They'd make up the
costs in new sales faster from FOSS-minded devs in no time flat and they'll
have minimal recurring dev costs in the long run.

To me this is a no-brainer.

~~~
ZenoArrow
> "Allwinner would be pretty foolish not to fully fund this endeavour"

Why would they fund it? If they saw the potential benefits, they could
probably open source their own closed source drivers and avoid this
Kickstarter being needed, or at the very least provide documentation to speed
this work along.

~~~
amluto
If I were Allwinner, I'd be quite nervous about open-sourcing my code. Who
knows what patents it infringes?

~~~
ZenoArrow
Patents for what? Algorithms? I've heard similar arguments/excuses made
before, I'd like to understand if there's any legal precedence for them, or if
it's more of a hypothetical risk.

Lastly, with the 'supply of documentation' approach, does this (to your
knowledge) carry the same legal risks?

~~~
joezydeco
The API would expose what IP cores are inside the GPU.

A competitor could easily dissect the code and figure out what blocks and/or
techniques are violating their patent rights.

~~~
ZenoArrow
> "The API would expose what IP cores are inside the GPU."

How would an open-source driver developed by a third party be less effective
at doing so?

~~~
joezydeco
The third-party is probing into a black box. They have no idea what is or
isn't there. So it could be plausible deniability on the side of the
chipmaker.

~~~
ZenoArrow
How about documentation then? Let's say Allwinner releases C header files,
plus high level descriptions of what each function does. Do they still
maintain plausible deniability if the hardware design infringes on patents?

------
WhitneyLand
Why do more work on mpeg-2?

Couldn’t that path just be left without acceleration, being it’s a less
complex codec to begin with, usage is not growing, and the data sources are
likely smaller to begin with (no 4k for example)?

~~~
bonyt
It's still useful for some applications. ATSC digital broadcasts in the U.S.,
for example, are in MPEG-2, as are the signals provided by many cable
companies. I have an HDHomeRun Prime, and purchased the MPEG-2 HW Decoder
license[1] for my Raspberry Pi 3 to make things a bit smoother.

[1]: [http://www.raspberrypi.com/mpeg-2-license-
key/](http://www.raspberrypi.com/mpeg-2-license-key/)

~~~
Narishma
Isn't the Raspberry Pi 3 powerful enough to do MPEG-2 decoding in software?

~~~
dsr_
Not if you want it to do anything else at the same time, and not if you need
de-interlacing of the 1080i streams that half the over-the-air channels use.

------
pedrocr
What kind of hardware is this that makes it usable for encoding/decoding
mpeg2/h264/h265? Is this something that should be exposed as a general
programming target instead of a set of video specific APIs?

~~~
revelation
It's a DSP firmware turned into silicon. If you look at for example the VP8
decoder registers for a Rockchip VPU here:

[https://patchwork.kernel.org/patch/8118991/](https://patchwork.kernel.org/patch/8118991/)

You can see it's quite specific to the primitives the codec needs. If you want
general purpose, we now have Vulkan for that.

(And this one is reasonably low-level. On some like the Raspberry Pi, you
throw bitstream over the wall to a coprocessor which gives you YUV back)

~~~
snaky
On Raspberry Pi it's not clear who is _co_ processor, actually.

