OpenVX使用案例分析
用例 1
第一个用例涉及 2 个vx_reference，一个已经为vx_reference分配了内存缓冲区，另一个没有。 （注意：有关何时发生内存缓冲区分配的更多信息，请参阅 TIOVX 中的内存管理。这些用例图描述了如何成功地将内存缓冲区从一个vx_reference导入到下一个，而不会导致内存泄漏。
下图描述了此用例的初始状态，其中 ref1 指向 buf1，而 ref2 尚未指向内存缓冲区。
此用例的下一步是首先将 buf1 从 ref1 导出到应用程序，然后将 buf1 导入到 ref2。此序列如下图所示。执行此操作后，ref2 将指向 buf1，而 ref1 仍指向 buf1。关于序列的这一部分的重要一点是，此时不应释放 ref1 和 ref2，因为这将导致未释放的引用指向已释放的缓冲区。
现在 ref2 指向 buf1，不再需要 ref1。然后释放 ref1 的正确方法是首先导入指向 ref1 的 NULL 指针，以确保它不再指向 buf1。完成此导入后，可以根据需要使用 ref2，并且 ref1 和 ref2 都处于允许释放它们的状态，而不会发生内存泄漏或无效内存访问。
用例 2
下一个用例涉及 2 个vx_reference，它们都已经为每个vx_reference分配了内存缓冲区（注意：有关何时进行内存缓冲区分配的更多信息，请参阅 TIOVX 中的内存管理。这些用例图描述了如何成功地将内存缓冲区从一个vx_reference导入到下一个，而不会导致内存泄漏。
下图描述了此用例的初始状态，ref1 指向 buf1，ref2 指向 buf2。
由于最终尝试将 buf1 导入到 ref2，因此首先从 ref2 导出 buf2。相反，如果在导出 buf2 的这一步之前将另一个缓冲区直接导入 ref2，则实现将抛出一条VX_ZONE_INFO消息，指示正在覆盖缓冲区。在这种情况下，此缓冲区将丢失，并且会出现内存泄漏。因此，需要此步骤来避免这种情况。
与前面的用例类似，下一步是首先将 buf1 从 ref1 导出到应用程序，然后将 buf1 导入到 ref2，如下图所示。与上面的用例类似，应该注意的是，此时不应释放 ref1 和 ref2，因为这会导致未释放的引用指向已释放的缓冲区。
下一步是使用 tivxMemFree API 释放从 ref2 导出中获得的 buf2。可以选择在上一步之前完成此步骤，而不会出现问题。但是，虽然 ref1 和 ref2 都指向 buf1，但它们仍然无法发布。
最后，与用例 1 类似，为了准备 ref1 以供发布，可以将 NULL 指针导入到 ref1。完成此导入后，可以根据需要使用 ref2，并且 ref1 和 ref2 都处于允许释放它们的状态，而不会发生内存泄漏或无效内存访问。
用例 3
下一个要考虑的用例是要交换引用所指向的缓冲区的情况。
下图描述了此用例的初始状态，ref1 指向 buf1，ref2 指向 buf2。
实现此交换的第一步是最初从 ref1 导出 buf1 和从 ref2 导出 buf2。
这些缓冲区现在可以导入到不同的参照中。在下图中，buf2 被导入到 ref1 中，覆盖了 buf1 与 ref1 的关联。在调用序列的此时，引用未处于允许正确释放的状态。
最后，将 buf1 导入到 ref2 中，完成交换。完成此导入后，ref1 和 ref2 都处于允许释放它们的状态，而不会发生内存泄漏或无效内存访问。
使用案例 4
这里考虑的最后一个用例是内存的导入，它没有通过框架直接通过数据对象构造函数进行分配。仍必须按照 tivxReferenceImportHandle API 文档使用 tivxMemAlloc API 分配内存。
在下图中，情况是这样的：创建了一个尚未分配缓冲区的vx_reference，而使用 tivxMemAlloc API 分配了一个单独的缓冲区。
为了让 ref1 指向这个新的 buf1，可以调用 tivxReferenceImportHandle API，从而创建 ref1 指向 buf1 的所需结果。现在，当 ref1 被释放时，buf1 也将被释放。
使用案例 5
此 API 的一个高级用例是在进程之间共享导出的缓冲区。下面的一组图表描述了如何在多进程方案中实现这一点。在较高级别上，在这种情况下必须遵守的语义是，最初分配缓冲区的进程必须最终释放缓冲区。
首先，让考虑两个进程，在这些进程中，创建了 2 个 OpenVX 引用，最终希望每个进程中的 OpenVX 引用指向相同的内存。在第一个过程中，确保缓冲区已分配，而在第二个过程中，有一个指向 NULL 缓冲区的 OpenVX 引用。（注意：如果 P2 中的引用已经分配，则必须首先发布与用例 2 类似的引用）。
接下来，想将缓冲区 buf1 从 ref1 跨进程边界导出到 ref2。（注意：有一些实用程序 API 可以帮助跨进程边界共享缓冲区。有关如何使用这些应用程序的示例，请参阅 PSDK RTOS 的视觉应用程序包中的“跨进程文件描述符交换”应用程序。在这些 API 的内部，物理缓冲区现在已跨进程边界共享，并已映射到进程。根据应用的不同，现在可能需要跨过程边界进行进一步的通信，特别是当这些引用中的每一个都是单独进程中图形的图形参数时。
申请完成后，必须按照以下顺序发布这些参考资料。缓冲区 （P2） 的使用者进程可以首先释放引用 “ref2”。这反过来又会从这个过程中映射 buf1。请注意，如果此 buf1 在 P2 中的多个引用之间共享，则除其中一个引用外，所有引用都可以将 NULL 缓冲区导入到引用中，并随后释放。
现在 buf1 已经从 P2 进行了 munmap，从 P1 <-> P2 建立的相同通信机制必须向 P1 发出信号，表明缓冲区已从 P2 中分离出来，因此可以最终从 P1 中释放出来。
现在 P1 已经收到来自 P2 的信号，表明 buf1 已被 munmapped，buf1 已准备好释放。这可以通过释放 ref1 来完成，从而释放 buf1。
需要注意的是，在每个进程中，缓冲区处理和释放遵循与上述用例中描述的相同语义，即内存的实际释放必须完成一次。对于在同一进程中接收导入缓冲区的其他引用，建议的释放过程是引用在释放之前导入了 NULL 引用。
参考文献链接
https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/tiovx/docs/user_guide/TIOVX_TARGET_EXECUTION.html
