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 构建管道后，可以对其进行参数化以使用任何后端（或它们的组合），因此，可以轻松地将图形移植到新平台。

另请参见: 高级设计概述