作者博客: https://bootlin.com/blog/author/paul/
众筹地址: https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel
项目地址: https://github.com/bootlin/linux-cedrus
离线
https://bootlin.com/blog/final-weekly-status-update-allwinner-vpu-support/
8月底已经到来，结束了Paul在Bootlin的工程实习，专注于为Allwinner平台上的VPU提供主线Linux支持。在过去六个月中，我们努力实现项目众筹活动中宣布的目标，并且我们能够在上个月实现大部分主要目标。
自上个月交付以来，我们在支持H265编解码器方面取得了很大进展，这是在活动期间资助的延伸目标之一。一个专门的补丁系列引入了对它的支持，本周早些时候提交给linux-media邮件列表，以及基础Cedrus VPU驱动程序的新版本。由于Request API 即将集成Linux内核，我们的VPU驱动程序很快就会推出。
我们现在已经耗尽了通过众筹活动提供的预算：Maxime Ripard的时间（主要负责H264解码和帮助DRM主题）和Paul的实习已经结束，因此剩下的工作将在最好的情况下完成 -努力的基础，没有直接的资金。因此，这将是最后一次每周更新，但我们会在有趣的进展时偶尔发布更新。
以下是我们Kickstarter活动中承诺的现状的快速摘要：
确保编解码器适用于仍在广泛使用的较旧的Allwinner SoC：A10，A13，A20，A33，R8和R16。这个目标完全得到满足 ;
抛光现有的MPEG2解码支持，使其完全生产就绪。这个目标完全得到满足 ;
实现H264视频解码。实现此基本H264解码支持完全满足此目标。但是，尚未实施许多更先进的H264功能，因此可以进行其他改进;
修改Allwinner显示驱动程序，以便能够直接显示已解码的帧，而不是转换和复制这些帧。这个目标完全得到满足。
提供易于集成在流行的开源视频播放器中的用户空间库。部分满足了这个目标。我们提供了一个提供VA-API实现的用户空间库，但是与流行视频播放器的集成比预期更具挑战性，我们目前只提供Kodi集成。详见下文;
将这些更改上传到官方Linux内核。这个目标是在进步，双方的VPU驾驶员侧和DRM改进的一面;
支持更新的Allwinner SoC（H3，H5，A64）。部分满足此目标，因为支持H3，但尚未支持H5和A64;
H265视频解码支持。实现了基本H265解码支持，完全满足了这一目标。与H264一样，许多更高级的功能尚未实现，因此还有更多工作空间。
我们遇到的主要缺陷与将加速视频解码流程与多媒体播放器集成有关。他们将需要在VPU活动范围之外的额外工作才能达到生产就绪状态。
我们考虑了许多与Xorg下的桌面环境集成的选项，这对于VPU输出平铺YUV格式的最古老的Allwinner平台来说尤其棘手。所需操作链包括untiling，色彩空间转换（从YUV到RGB），缩放和合成。
我们首先使用主CPU来执行所有必需的操作（包括NEON支持的untiling例程），一旦进程涉及扩展，这将变得无法忍受。
我们尝试引入GPU以加速所涉及的无人值守，色彩空间转换，缩放和合成操作。虽然我们编写了一个基于着色器的untiler，但Mali blob不允许逐个字节地导入原始帧数据。这使得GPU加速在实践中无法用于我们的用例。仅为最终合成步骤引入GPU（应该可以使用支持GBM的blob）可以带来一些加速。
另一个主要是使用X11 API 的Xv扩展，这符合使用Display Engine硬件来加速这些操作的费用，但是这个界面现在已经很老了，而且越来越被弃用了。它还只允许次优用例，一次只有一个视频。
我们还调查了可以在没有显示服务器的情况下运行的媒体播放器的情况，这消除了对合成步骤的需要，并允许通过DRM接口直接使用显示引擎硬件。
我们通过添加所需的位来实现零拷贝管道，成功地为Kodi媒体中心提供了支持。
我们致力于让GStreamer正确地将基于VAAPI的解码管道传输到支持DRM的kmssink，而无需通过GPU，但最终没有任何功能结果，因此该领域仍有大量工作要做。
以下是我们打算在这个尽力而为模式下继续工作的主题，并在2018年底完成，正如我们的众筹活动所承诺的那样：
确保基础Cedrus Linux内核驱动程序合并;
确保Cedrus驱动程序中的H264解码支持合并;
确保Cedrus驱动程序中的H265解码支持合并;
确保DRM驱动程序改进合并;
在H5和A64上启用VPU支持。
以下是我们不打算在没有额外资金的情况下开展工作的其他主题。希望在这些主题上看到一些进展的个人被邀请参与并加入改进上游Linux中Allwinner VPU支持的工作。对这些功能感兴趣的公司也可以联系我们。
额外的H264和H265解码功能：隔行扫描视频支持（H264和H265），量化矩阵（H265），10位（H265），4K分辨率（H265）;
除MPEG2，H264和H265之外的其他编解码器，如VP8;
编码支持;
关于GStreamer集成或X.org集成的其他工作。
我们再一次感谢所有参与我们众筹活动的个人和公司，并使这个项目成为可能。我们非常高兴地看到，尽管所有软件开发项目都存在不确定性，但我们一直在预期的时间框架内实现绝大部分目标，同时每周更新我们的进度。这是Bootlin的全新体验，我们希望将来能够为其他Linux内核上游开发更新这一经验！
离线
https://bootlin.com/blog/allwinner-vpu-main-goals-delivery/
交付Allwinner VPU驱动程序的主要目标
经过几周的延迟，我们很自豪地宣布推出众筹活动的主要目标，致力于为Allwinner视频解码硬件增加上游Linux支持。
经过Bootlin工程师Maxime Ripard和实习生Paul Kocialkowski几个月的艰苦努力，我们现在有了一个Kodi的工作演示，我们的VPU驱动程序运行在主线4.18-rc内核之上。支持MPEG2和H264，在VPU和显示器侧之间具有完全优化的管道，不涉及任何缓冲器复制或硬件无法卸载的额外转换。由于linux-sunxi社区以前的努力，尤其是libvdpau-sunxi项目，这些结果是可能的。
在A33和H3上运行的Cedrus VPU驱动程序
以下是我们众筹活动中定义的主要目标，我们承诺将在2018年6月底交付，以及他们在交付时的状态：
确保编解码器适用于较旧的Allwinner SoC：A10，A13，A20，A33，R8和R16。。这个目标得到了充分的实现，功能超出了计划： Cedrus驱动程序在A10，A13，A20，A33和H3上被提升。因此，我们在此次交付中包含了H3支持，尽管它最初只是其中一个延伸目标的一部分。R8与A13相同，R16与A33相同，因此也支持它们。
抛光现有的MPEG2解码支持，使其完全生产就绪。完全实现了这一目标：我们对MPEG2解码进行了更多测试，支持MPEG2的Linux内核代码和用户空间代码都得到了显着的改进和清理。
实现H264视频解码，因为H264是迄今为止最受欢迎的视频编解码器之一。。完全满足了这一目标： Linux内核驱动程序和用户空间库都添加了 H264解码支持，包括高调的H264支持。但是，H264支持仍然是最新的，我们希望需要进行额外的调试和改进。
修改Allwinner显示驱动程序，以便能够直接显示已解码的帧，而不是转换和复制这些帧。完全满足此目标： Allwinner DRM驱动程序已收到许多补丁，以确保我们可以使用多个平面之一以VPU提供的格式直接显示视频帧。还修复了对硬件扩展的支持以使其正常工作。这些补丁已经被贡献给上游Linux内核。A20和A33显示驱动程序的工作由Bootlin完成，而H3的工作则由社区的其他开发人员完成。
提供易于集成在流行的开源视频播放器中的用户空间库。这个目标部分得到满足：虽然我们提供的libva-v4l2请求用户空间库理论上可供所有支持libva的视频播放器使用，但与视频播放器的实际集成目前仅与Kodi完全兼容。我们已经开始努力使其与VLC和GStreamer一起工作，但由于下面详述的各种挑战，工作尚未完成。这个区域肯定比我们最初的预期更具挑战性。
将这些更改上传到官方Linux内核。这个目标几乎已经实现：我们已经发布了5次Cedrus Linux内核驱动程序的迭代，每次都使用新版本的Request API补丁，从而帮助改进这个API。虽然我们的补丁尚未合并，但由于Request API本身尚未合并，因此他们已收到V4L开发人员的重要评论，我们认为我们的补丁距离合并不远。
总而言之，尽管过去几个月遇到了许多挑战，但我们很高兴看到我们已经能够完全实现大部分目标，而且我们对于尚未实现的少数目标并不太遥远。完全满足。正如我们将在下面讨论的那样，我们将在接下来的几个月继续完成未完成的步骤，以及获得足够资金的延伸目标。
达到这种水平的支持并不是一个简单的旅程，因为我们的道路铺设了下面列出的各种障碍。
媒体请求API
为了增加对Allwinner平台上的VPU的支持，在Video4Linux2（v4l2）框架（Linux中的视频框架）中需要一些内部管道。虽然V4L2获得了对特定类别VPU的支持，即所谓的“有状态”（由于Memory2Memory API，视频比特流直接传递给硬件控制器），但这对我们的硬件来说还不够。实际上，Allwinner平台带有一个“无状态”VPU，需要事先解析视频以提取帧数据及其相关元数据，然后传递给硬件。V4L2缺少用于同步帧数据和相关元数据的API，尽管它已经开发了很长时间并被称为Request API。
我们对Cedrus的研究有助于恢复该API的火焰，由于Alexandre Courbot，Hans Verkuil和Sakari Ailus等人的承诺，过去几个月它的发展得到了加速。我们有机会报告各种问题，并对其开发过程提出了修正建议，这些问题已经集成，以便我们的驱动程序现在都可以使用.API终于成熟并且看起来非常稳定，所以没有已知的阻止程序留在内核中进行集成。
Cedrus V4L2驱动程序
Cedrus驱动程序的第一个版本最初由Florent Revest于2016年开发，作为Bootlin实习的一部分，基于旧版本的Request API。因此，我们开始将其移植到最新版本的API，并在发生Request API时不断发布新版本。我们还在此过程中收到了社群的有用反馈。以下是Cedrus驱动程序的不同迭代，这些迭代已作为此众筹资金的一部分发送：
版本1，2018年3月9日
版本2，2018年4月19日
版本3，2018年5月7日
版本4，2018年6月18日
版本5，2018年7月10日
除了添加驱动程序本身的补丁系列之外，还发送了一个额外的补丁系列以支持H264。
虽然它带来了一些挑战，但驱动程序本身的开发并不是该过程中最麻烦的部分。例如，我们必须在发现硬件限制后重新进行缓冲区管理，其中目标缓冲区的亮度和色度平面需要在内存中保持接近。我们还必须引入一个工作队列（后来被线程IRQ取代）以满足M2M API的需求，这会带来性能上的缺陷，尽管这个问题正在解决之中。
独立测试
为了在完全受控的环境中测试VPU驱动程序，我们开发了一个独立的测试工具：v4l2-request-test（以前的cedrus-frame-test），它实现了我们VPU所需的所有V4L2用户空间API，包括M2M和请求API。此工具包括来自实际视频的帧数据和元数据转储，能够逐个解码这些帧。该工具非常有助于调试驱动程序以及添加对H264的支持。由于涉及的用户空间API正确地抽象了硬件，因此该工具可用于开发和开发依赖于V4L2 Request API的其他VPU驱动程序！
VAAPI后端
为了提供与实际视频播放器的集成，我们开发了libva-v4l2-request（以前称为libva-cedrus）：支持V4L2 M2M和Request API的VAAPI后端。它目前支持MPEG2和H264，并将在添加对新格式的支持时进行扩展。就像v4l2-request-test一样，libva-v4l2-request旨在以通用方式使用内核API，这应该适合其他基于Request API的VPU驱动程序。
从长远来看，玩家可能会集成对Request API的直接支持（例如，通过ffmpeg）。同时，这允许通过两个主要接口与媒体播放器连接：缓冲区派生，其中目标帧被复制（并且当VPU不能自己执行时转换为常规图像格式）或dma-buf，而没有任何副本。
与EGL（Mali GPU）的零拷贝流水线集成：VLC和GStreamer
为了达到我们所能达到的最佳性能，我们专注于不涉及缓冲区复制的流水线，流行的播放器：VLC和GStreamer。由于X.org显示服务器不容易将VPU输出管道连接到显示引擎端的专用平面，因此我们调查了GPU的使用情况。Allwinner平台上的GPU支持仍然需要专有的blob，例如Bootlin最近提供的那些。我们希望Lima项目能够很快带来一个完全免费的替代方案，该方案将与上游内核和上游用户空间组件集成。
在处理平铺的VPU输出格式时，我们没有太多运气，GPU无法直接处理。虽然我们编写了一个用于untiling的GPU着色器（适用于常规GL实现），但是在导入平铺输出帧时，Mali GPU blob的行为并不像预期的那样。有可能输出常规图像格式（A33及以后版本）的平台将能够处理VPU和GPU的加速扩展和色彩空间转换，但我们此时并未测试此选项。
与DRM（显示引擎）的零拷贝流水线集成：GStreamer和Kodi
尽管使用平铺的VPU输出格式将GPU纳入管道并不是现实的可能性，但是各种播放器支持直接DRM视频输出，其直接使用显示引擎来管道视频。唉，这意味着没有窗口组合是可能的，因此无法与桌面环境集成。相反，玩家在他们自己的虚拟终端中独立运行。
我们最初用这种方式看待使用GStreamer，但很快决定优先考虑流行的mediacenter应用程序Kodi（以前的XBMC）。虽然已经有DRM视频输出支持，但在Kodi中整合我们的管道（通过libva-v4l2-request，通过ffmpeg）是一项艰巨的任务。我们最终设法从中获得了可用的结果，尽管还有一些方面需要改进！
LibreELEC与Kodi一起发布图像
为了展示我们主要的VPU众筹活动目标，我们制作了一个支持A20，A33和H3 SoC的LibreELEC版本！它由一个LibreELEC根文件系统（不包括内核和启动软件）组成，它与我们最新的linux-cedrus内核树一起工作。
源代码当然可以通过我们的存储库获得，标记为release-2018-07标记。
有关在兼容板上部署软件的说明，请访问linux-sunxi社区维基！
剩余的任务
到目前为止，我们已经处理了许多任务，但仍有一些项目需要处理：
发布新系列的Cedrus驱动程序和H264支持，直到它合并为止;
在我们的驱动程序和用户空间组件中支持H265;
支持显示引擎设计版本2的ARM64 SoC，即H5和A64;
有助于我们的代码在上游Kodi和LibreELEC中的整合;
将dma-buf和DRM管道与GStreamer集成。
谢谢
我们要感谢所有支持这个项目的个人和公司，参与我们的众筹活动，以及linux-sunxi社区成员，他们对Cedrus VPU进行了最初的逆向工程，并在开发过程中与我们合作。驱动程序以及V4L2社区的成员，他们使用了Request API并查看了我们的补丁。
离线
看进度，估计明年在主线上面编解码就可以完全跑起来了.
有没有尝鲜过的朋友？
V3s 主线的 CSI 摄像头补丁也有了.
离线