G-API 背后的动机

G-API 模块为 OpenCV 引入了基于图的执行模型。本章简要介绍了这种新模型如何在两个方面帮助软件开发者：优化和移植图像处理算法。

使用图 API 进行优化

传统上，OpenCV 提供了许多独立的图像处理函数（参见模块core和imgproc）。许多这些函数都经过了很好的优化（例如，针对特定 CPU 的矢量化、并行化等），但是现成的优化范围仅限于单个函数——构建在这些函数之上的整个算法的优化仍然是程序员的责任。

OpenCV 3.0 引入了透明 API（或T-API），它允许将 OpenCV 函数调用透明地卸载到 OpenCL 设备，并使用cv::UMat节省主机/设备数据传输——这是一个巨大的进步。但是，T-API 是一个动态 API——用户代码仍然不受约束，OpenCL 内核以任意顺序排队，因此消除了进一步的流水线级别优化潜力。

G-API 为 OpenCV 4.0 带来了隐式图模型。图模型捕获所有操作及其在流水线中的数据依赖关系，从而为 G-API 框架提供额外信息以进行流水线级别优化。

基于图的优化的基石是平铺。平铺允许将处理分解成更小的部分，并重新组织操作以启用数据并行性、提高数据局部性并节省内存占用。由于现代计算机体系结构中内存访问成本的不同，数据局部性是软件优化的一个特别重要的方面——一级缓存中重用的数据越多，流水线效率就越高。

当然，可以手动应用上述技术——但这需要额外的技能和目标平台的知识，并且算法实现会不可逆地发生变化——变得更具体、更不灵活，更难扩展和维护。

G-API 承担了用户的这项责任和复杂性，并自行完成了大部分工作，使算法代码保持简洁，无需考虑设备或优化细节。但是，这种方法也有其自身的局限性，因为图模型是一个受约束的模型，并非所有算法都可以表示为图，因此 G-API 的范围仅限于常规图像处理——各种滤波器、算术运算、二元运算和定义明确的几何变换。

使用图 API 进行移植

G-API 的本质是声明要运行的一系列操作，然后执行该序列。G-API 是一个受约束的 API，因此它对哪些操作可以形成管道以及这些操作之间可以交换哪些数据施加了一些限制。

这种形式化实际上有助于使算法可移植。G-API 清晰地区分了操作的接口及其实现。

一个操作（内核）即使对于单个设备也可能有多种实现（例如，基于 OpenCV 的“参考”实现和一个平铺优化的实现，两者都在 CPU 上运行）。图（或 G-API 术语中的计算）仅使用操作接口构建，而不是实现——因此，同一个图可以在不同的设备上执行（当然，可以使用不同的优化技术），而图本身几乎无需更改。

G-API 支持插件（后端），这些插件汇总了关于在特定平台上执行的最佳方法的逻辑和智能。一旦使用 G-API 构建了流水线，就可以对其进行参数化以使用任何后端（或其组合），因此可以轻松地将图移植到新平台。

另请参阅: 高级设计概述