LWN：图像处理器领域的不快！

关注了就能看到更多这么棒的文章哦～

The growing image-processor unpleasantness

By Jonathan Corbet
August 18, 2022
DeepL assisted translation
https://lwn.net/Articles/904776/

曾几何时，如果想购买一些硬件来运行 Linux，那么在选择硬件时必须小心翼翼。近几十年来，这种情况已经有了很大的改善，不支持的硬件已经成为个例，而不再是普遍现象。这些年来，尤其是英特尔的硬件更是支持得很好；该公司一直致力于确保其产品能够与 Linux 兼容。因此，在人们发现随 Alder Lake CPU 出货的 IPU6 图像处理器（image processor）缺乏对 Linux 的支持、而且不太可能很快得到支持的情况时，有点出乎意料。不过，我们在本文中关注的问题不仅仅是英特尔。

跟其他多数图像处理器一样，IPU6 的存在目标是接受来自相机传感器的数据流，并将其转化为有用的视频流。这些处理器可以承担很多任务，包括旋转、裁剪、缩放、色彩空间转换、白平衡校正、去噪、调焦等等。它们是非常复杂的设备；内核社区也就相应地创建了一些同样复杂的 API，包括 Video4Linux2（V4L2）和媒体控制器（media controller），从而让用户空间可以对这些硬件进行管理。只要设备有合适的驱动，内核就可以让用户空间正常使用相机设备，而用户空间只要小心使用，就可以获得这些功能而不需要知道硬件的细节。

正如 Paul Menzel 最近在 linux-kernel 邮件列表中指出的，IPU6 没有这样的驱动，所以 mainline Linux 内核不能支持它。因此，内核就无法支持目前一些笔记本电脑上在使用的 MIPI 摄像头，比如 Thinkpad X1 Carbon 和 Dell XPS 13 的某些版本，这些产品在 Linux 用户中比较流行。而使用其他接口的摄像头（如 USB UVC）一般都可以支持。为了解决这个问题，戴尔在其为 XPS 13 提供的 Ubuntu 版本中提供了一个闭源的用户空间驱动程序。联想目前则根本没有销售预装 Linux 的这些笔记本。

Laurent Pinchart 提供了有关这一情况的更多细节。Ubuntu 上的 IPU6 支持是基于一个提供 V4L2 接口的内核驱动的，但它需要与一个专有的用户空间驱动交互才能实际完成工作。正如 Ubuntu 的戴尔页面所指出的，这种解决方案是有额外成本的："CPU 性能会受到为 v4l2 loopback device 进行 buffer copying 的 daemon 守护程序的影响"，而且相机只能提供 720p 的分辨率。Pinchart 继续说，IPU6 不会是目前唯一有问题的设备：

鉴于行业所采取的发展方向，这种情况在未来会越来越普遍。除了在开源相机支持方面处于领先地位的 Raspberry Pi 之外，今天没有任何一家 SoC 供应商愿意开放其成像算法（imaging algorithms）。

要改善这种状况，需要在几个方面下功夫。在用户空间方面，Pinchart 指出，创建 libcamera 项目的明确目的就是支持像 IPU6 这样的复杂设备；这个项目在 2019 年曾在 LWN 介绍过。此外，libcamera 设计时就确保在最大限度地使用自由软件的同时，也允许插入专有的图像处理代码。目前，它支持早期的 IPU3 处理器，无论是否使用专有插件都可以工作，但是如果没有用专有插件的话，可能无法使用全部所有功能。

应该可以给 IPU6 提供类似的支持，但这将需要相当多的工作。它还需要一个合适的 IPU6 的内核驱动，这会是一个问题。显然，这个设备的复杂性使得 V4L2 的 API 无法支持它，所以需要一个新的 API。据 Sergey Senozhatsky 说，有计划将其合并入内核，然后添加一个实现该 API 的 IPU6 驱动程序。Pinchart 回应说，合入这个 patch 不会是很快的事情，因为所提出的 API 在内核社区中并不被看好。

V4L2 API 需要经过多年的广泛开发和演变才能达到目前的水平；它不会在一夜之间被取代。如果提出来的替代方案是完全独立开发的、从未经过任何形式的公开讨论，那就更加难以取代原有方案了，这次的情况就是如此。Senozhatsky 贴出了一个包含了 CAM 实现的 repository 的路径，但该代码只是模糊有用。没有文档，也没有实际实现这个 API 的驱动程序。它是高度抽象的；正如 Sakari Ailus 所说。"如果没有人告诉我，我都猜不到这是一个摄像头的 API"。

正如 Ailus 所描述的那样，创建一个新的相机 API 将是 "一项重大而有风险的工作"；它会需要一个长期的对话交流，而且不清楚 CAM 是否已经在推进了。据 Senozhatsky 说，CAM 代码在 "几个月内 "不会被提交到 upstream。他后来建议，可以加快这个计划，但事实是，社区甚至还没有开始设计适合下一代图像处理器的 API 的工作。

因此，购买 Linux 系统的人将不得不在一段时间内要更加小心；许多本来很好的系统在没有专有相机驱动程序的情况下将无法提供完整的功能，因此，许多发行版都会缺乏对它的支持。要使这种硬件完全正常工作，就需要采用目前的解决方法，损失一部分 CPU 性能。解决所有这些问题可能需要数年时间，即便如此，也不清楚是否会有可行的免费软件的解决方案。这对英特尔、对 Linux、对整个行业来说都是一个重大的倒退。

后记：KCAM 的开发者要求我们补充以下声明，因为他们认为本文对该项目的描述并不完全公平：

自 2018 年以来，谷歌一直在与社区成员和硬件供应商紧密合作。包括组织了两次大型研讨会（在 2018 年和 2020 年）。

开发是公开进行的，并在公共论坛上进行了介绍，欢迎尽可能多的感兴趣的人。

我们期待着完成初步方案的开发，并在邮件列表中发布，以了解社区的意见。ChromeOS 在内核工作方面坚持采用 "upstream first"，并将继续朝着这个方向努力。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～