G-API 背后的动机

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

使用 Graph 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 的范围仅限于常规图像处理——各种滤波器、算术、二元运算以及定义良好的几何变换。

使用 Graph API 进行移植

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

事实上，这种形式化有助于使算法具有可移植性。G-API 清楚地将操作接口与其实现分开。

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

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

另请参见: 高级设计概述