Allwinner VPU support for the Linux kernel(kickstarter.com)
kickstarter.com
Allwinner VPU support for the Linux kernel
https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel
24 comments
> "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.
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.
If I were Allwinner, I'd be quite nervous about open-sourcing my code. Who knows what patents it infringes?
I think you've put forward an important point many don't consider when debating why companies won't open source.
We have a winner!
This is why the recent proposal by Bunnie of trading transparency against liability would be so important.
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?
Lastly, with the 'supply of documentation' approach, does this (to your knowledge) carry the same legal risks?
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.
A competitor could easily dissect the code and figure out what blocks and/or techniques are violating their patent rights.
> "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?
How would an open-source driver developed by a third party be less effective at doing so?
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.
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?
It means they don't need to get lawyers involved to check for any licencing gotchas from other non-free code in the tool chain. They might see it as a liability or reveals other tangentially related proprietary details of their tooling. There may not be much formal documentation, and if there is it would likely need to be combed through, updated, translated, etc.
Even without getting lawyers involved, I don't see how they could do any of the above tasks for less than the price of this Kickstarter.
Even without getting lawyers involved, I don't see how they could do any of the above tasks for less than the price of this Kickstarter.
> "It means they don't need to get lawyers involved to check for any licencing gotchas from other non-free code in the tool chain."
They don't need to open source the whole toolchain, just the parts of the code they own/wrote themselves. For the parts of the toolchain they can provide documentation (writing it out if this documentation needed to be created/revised) to fill in the missing pieces.
> "I don't see how they could do any of the above tasks for less than the price of this Kickstarter."
You seem to be overlooking that reverse engineering hardware drivers is a hugely inefficient process. People only do it out of necessity. Furthermore, the Kickstarter has set modest goals of enhancing the work that has already been done (MPEG2 acceleration, etc...), the end result is not a driver that can be used for more general purpose graphics acceleration (e.g. no OpenGL driver). That's not to say it isn't a good step forward, I welcome it, but you should be aware that there's a long road ahead after the work for the Kickstarter has been completed. If you don't believe me, look at the ongoing work being done by the Nouveau team.
They don't need to open source the whole toolchain, just the parts of the code they own/wrote themselves. For the parts of the toolchain they can provide documentation (writing it out if this documentation needed to be created/revised) to fill in the missing pieces.
> "I don't see how they could do any of the above tasks for less than the price of this Kickstarter."
You seem to be overlooking that reverse engineering hardware drivers is a hugely inefficient process. People only do it out of necessity. Furthermore, the Kickstarter has set modest goals of enhancing the work that has already been done (MPEG2 acceleration, etc...), the end result is not a driver that can be used for more general purpose graphics acceleration (e.g. no OpenGL driver). That's not to say it isn't a good step forward, I welcome it, but you should be aware that there's a long road ahead after the work for the Kickstarter has been completed. If you don't believe me, look at the ongoing work being done by the Nouveau team.
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)?
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)?
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/
[1]: http://www.raspberrypi.com/mpeg-2-license-key/
Since they want to do hardware x264, are there any patent issues they'll have to deal with, or will that be included in the cost? I didn't see anything listed on the Kickstarter page.
Looks like Bootlin is located in France. France doesn't recognize software patents (as I understand it), which is why VLC can exist.
(Though I noticed on VLC's website that the EC could try to change that: https://www.videolan.org/press/patents.html)
(Though I noticed on VLC's website that the EC could try to change that: https://www.videolan.org/press/patents.html)
DVDs, too, are almost all MPEG-2.
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?
As you can see from the documented reverse-engineering of the hardware here:
http://linux-sunxi.org/VE_Register_guide
the device is generally single-function for each codec, with the decoding pipeline implemented in actual hardware. Unless you were able to express your kernel as a data transform used in a common video codec and express your I/O data as pixels, you're unlikely to accelerate a general purpose task this way.
http://linux-sunxi.org/VE_Register_guide
the device is generally single-function for each codec, with the decoding pipeline implemented in actual hardware. Unless you were able to express your kernel as a data transform used in a common video codec and express your I/O data as pixels, you're unlikely to accelerate a general purpose task this way.
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/
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)
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)
On Raspberry Pi it's not clear who is coprocessor, actually.
To me this is a no-brainer.