Shared Virtual Memory (SVM) Functions

本文轉載自查看原文 2019-12-22 13:55 1459 Heterogeneous/ IA

深入GPU硬件架構及運行機制

What differences and relations between SVM, HSA, HMM and Unified Memory?

Could someone explain differences and relations between the SVM(Shared Virtual Memory, by Intel), HSA(Heterogeneous System Architecture, by AMD), HMM(Heterogeneous Memory Management, by Glisse from redhat) and UM(Unified Memory, by NVIDIA) ? Are these in the substitutional relation?

As I understand it, these aim to solve the same thing, sharing pointers between CPU and GPU(implement with ATS/PASID/PRI/IOMMU support). So far, SVM and HSA can only be used by integrated gpu. And, Intel declare that the root ports doesn’t not have the required TLP prefix support, resulting that SVM can’t be used by discrete devices. So could someone tell me the required TLP prefix means what specifically? With HMM, we can use allocator like malloc to manage host and device memory. Does this mean that there is no need to use SVM and HSA with HMM, or HMM is the basis of SVM and HAS to implement Fine-Grained system SVM defined in the opencl spec?

有人可以解釋一下SVM（英特爾共享虛擬內存），HSA（異構系統架構，AMD），HMM（異構內存管理，Glisse）和UM（統一內存，NVIDIA）之間的區別和關系嗎？這些是替代關系嗎？

據我了解，它們旨在解決同一問題，在CPU和GPU之間共享指針（通過ATS / PASID / PRI / IOMMU支持實現）。到目前為止，SVM和HSA只能由集成GPU使用。而且，英特爾宣布根端口不具備必需的TLP前綴支持，從而導致分立設備無法使用SVM。那么有人可以告訴我所需的TLP前綴是什么意思嗎？使用HMM，我們可以使用malloc之類的分配器來管理主機和設備內存。這是否意味着不需要將SVM和HSA與HMM一起使用，還是HMM是SVM和HAS的基礎，以實現opencl規范中定義的精細系統SVM？

I can't provide an exhaustive answer, but I have done some work on SVM. Take it with a grain of salt though, I am not an expert.

* HSA is an architecture that provides a common programming model for CPUs and accelerators (GPGPUs etc). It does have SVM requirement (I/O page faults, PASID and compatible address spaces), though it's only a small part of it.

* Similarly, OpenCL provides an API for dealing with accelerators. OpenCL 2.0 introduced the concept of Fine-Grained System SVM, which allows to pass userspace pointers to devices. It is just one flavor of SVM, they also have coarse-grained and non-system. But they might have coined the name, and I believe that in the context of Linux IOMMU, when we talk about "SVM" it is OpenCL's fine-grained system SVM.

* Nvidia Cuda has a feature similar to fine-grained system SVM, called Unified Virtual Adressing. I'm not sure whether it maps exactly to OpenCL's system SVM. Nividia's Unified Memory seems to be more in line with HMM, because in addition to unifying the virtual address space, they also unify system and device memory.

So SVM is about userspace API, the ability to perform DMA on a process address space instead of using a separate DMA address space. One possible implementation, for PCIe endpoints, uses ATS+PRI+PASID.

* The PASID extension adds a prefix to the PCI TLP (characterized by bits[31:29] = 0b100) that specifies which address space is affected by the transaction. The IOMMU uses (RequesterID, PASID, Virt Addr) to derive a Phys Addr, where it previously only needed (RID, IOVA).

* The PRI extension allows to handle page faults from endpoints, which are bound to happen if they attempt to access process memory.

* PRI requires ATS. PRI adds two new TLPs, but ATS makes use of the AT field [11:10] in PCIe TLPs, which was previously reserved.

So PCI switches, endpoints, root complexes and IOMMUs all have to be aware of these three extensions in order to use SVM with discrete endpoints.

While SVM is only about virtual address space, HMM deals with physical storage. If I understand correctly, HMM allows to transparently use device RAM from userspace applications. So upon an I/O page fault, the mm subsystem will migrate data from system memory into device RAM. It would differ from "pure" SVM in that you would use different page directories on IOMMU and MMU sides, and synchronize them using MMU notifiers. But please don't take this at face value, I haven't had time to look into HMM yet.

我無法提供詳盡的答案，但是我已經在SVM上做了一些工作。雖然我有些經驗，但我不是專家。

* HSA是為CPU和加速器（GPGPU等）提供通用編程模型的體系結構。它確實具有SVM要求（I / O頁面錯誤，PASID和兼容的地址空間），盡管它只是其中的一小部分。

*同樣，OpenCL提供了用於處理加速器的API。 OpenCL 2.0引入了精細系統SVM的概念，該概念允許將用戶空間指針傳遞給設備。這只是SVM的一種，它們還具有粗粒度且非系統的特性。但是他們可能是個名字，我相信在Linux IOMMU的背景下，當我們談論“ SVM”時，它就是OpenCL的細粒度系統SVM。

* Nvidia Cuda具有類似於細粒度系統SVM的功能，稱為統一虛擬地址。我不確定它是否完全映射到OpenCL的系統SVM。 Nividia的統一內存似乎更符合HMM，因為除了統一虛擬地址空間外，它們還統一系統和設備內存。

因此，SVM與用戶空間API有關，即在進程地址空間上執行DMA而不是使用單獨的DMA地址空間的能力。對於PCIe端點，一種可能的實現方式是使用ATS + PRI + PASID。

* PASID擴展名在PCI TLP上添加了一個前綴（由bit [31:29] = 0b100表征），該前綴指定事務影響哪個地址空間。 IOMMU使用（RequesterID，PASID，Virt Addr）派生一個Phys Addr，以前僅在此位置（RID，IOVA）。

* PRI擴展允許處理來自端點的頁面錯誤，如果它們試圖訪問進程內存，這些錯誤肯定會發生。

* PRI需要ATS。 PRI添加了兩個新的TLP，但是ATS利用了先前保留的PCIe TLP中的AT字段[11:10]。

因此，PCI交換機，端點，根聯合體和IOMMU都必須了解這三個擴展，才能將SVM與離散端點一起使用。

雖然SVM僅與虛擬地址空間有關，但是HMM處理物理存儲。如果我理解正確，則HMM允許透明地使用用戶空間應用程序中的設備RAM。因此，在發生I / O頁面故障時，mm子系統會將數據從系統內存遷移到設備RAM。它與“純” SVM的不同之處在於，您將在IOMMU和MMU端使用不同的頁面目錄，並使用MMU通知程序對其進行同步。但是請不要一味看待這個，我還沒有時間研究HMM。

So aim of all technology is to share address space between a device and CPU. Now they are 3 way to do it:

A) all in hardware like CAPI or CCIX where device memory is cache coherent from CPU access point of view and system memory is also accessible by device in cache coherent way with CPU. So it is cache coherency going both way from CPU to device memory and from device to system memory

B) partially in hardware ATS/PASID (which are the same technology behind both HSA and SVM). Here it is only single way solution where you have cache coherent access from device to system memory but not the other way around. Moreover you share the CPU page table with the device so you do not need to program the IOMMU. Here you can not use the device memory transparently. At least not without software help like HMM.

C) all in software. Here device can access system memory with cache coherency but it does not share the same CPU page table. Each device have their own page table and thus you need to synchronize them.

HMM provides helper that address all of the 3 solutions.
A) for all hardware solution HMM provides new helpers to help with migration of process memory to device memory
B) for partial hardware solution you can mix with HMM to again provide helpers for migration to device memory. This assume you device can mix and match local device page table with ATS/PASID region
C) full software solution using all the feature of HMM where it is all done in software and HMM is just doing the heavy lifting on behalf of device driver

In all of the above we are talking fine-grained system SVM as in the OpenCL specificiation. So you can malloc() memory and use it directly from the GPU.

Hope this clarify thing.

因此，所有技術的目的都是在設備和CPU之間共享地址空間。現在，他們是三種實現方法：

A）所有在CAPI或CCIX之類的硬件中，從CPU訪問的角度來看，設備內存是緩存連貫的，並且設備也可以通過緩存與CPU連貫的方式來訪問系統內存。因此，緩存一致性是從CPU到設備內存以及從設備到系統內存的兩種方式

B）部分包含在硬件ATS / PASID中（這是HSA和SVM背后的相同技術）。在這里，這是唯一的單向解決方案，您可以緩存從設備到系統內存的一致性訪問，而沒有相反的方法。此外，您與設備共享CPU頁表，因此無需對IOMMU進行編程。在這里，您不能透明地使用設備存儲器。至少並非沒有像HMM這樣的軟件幫助。

C）全部在軟件中。在這里，設備可以訪問具有緩存一致性的系統內存，但是它不共享同一CPU頁表。每個設備都有自己的頁表，因此您需要對其進行同步。

HMM提供了可解決所有3個解決方案的助手。
  A）對於所有硬件解決方案HMM提供了新的幫助程序，以幫助將過程內存遷移到設備內存
  B）對於部分硬件解決方案，您可以將其與HMM混合使用，以再次提供用於遷移到設備內存的幫助器。假設您的設備可以將本地設備頁面表與ATS / PASID區域混合並匹配
  C）完整的軟件解決方案，使用了HMM的所有功能，其中所有功能都是通過軟件完成的，而HMM只是代表設備驅動程序進行了繁重的工作

在以上所有內容中，我們都在談論像OpenCL規范中的細粒度系統SVM。因此，您可以malloc（）內存並直接從GPU使用它。

希望這可以澄清事情。

Description

Shared Virtual Memory (SVM) (Glossary): An address space exposed to both the host and the devices within a context. SVM causes addresses to be meaningful between the host and all of the devices within a context and therefore supports the use of pointer based data structures in OpenCL kernels. It logically extends a portion of the global memory into the host address space therefore giving work-items access to the host address space.

There are three types of SVM in OpenCL.

Coarse-Grained buffer SVM: Sharing occurs at the granularity of regions of OpenCL buffer memory objects.

Fine-Grained buffer SVM: Sharing occurs at the granularity of individual loads/stores into bytes within OpenCL buffer memory objects.

Fine-Grained system SVM: Sharing occurs at the granularity of individual loads/stores into bytes occurring anywhere within the host memory.

共享虛擬內存（SVM）（詞匯表）：在上下文中向主機和設備公開的地址空間。SVM 使主機和上下文中的所有設備之間的地址有意義，因此支持在 OpenCL 內核中使用基於指針的數據結構。它在邏輯上將全局內存的一部分擴展到主機地址空間，因此使工作項能夠訪問主機地址空間。

OpenCL 中有三種類型的 SVM：

粗粒度緩沖區 SVM: 共享 OpenCL 緩沖區對象的區域粒度。

細粒度緩沖區 SVM：共享在OpenCL 緩沖區內存對象中的單個字節加載/存儲。

細粒度系統 SVM：共享在主機內存中任意位置的單個字節加載/存儲。

前兩種模式需要使用OpenCL clSVMAlloc函數顯式分配SVM緩沖區，並且當將該緩沖區的指針傳遞給內核時，必須將其顯式聲明為SVM指針。相反，細粒度的系統SVM提供了最高級別的抽象，因為設備上的每個內核都可以訪問任何指針：使用clSVMAlloc和由常規malloc / new函數返回的那些。

OpenCL™ 2.0 Shared Virtual Memory Overview

One of the remarkable features of OpenCL™ 2.0 is shared virtual memory (SVM). This feature enables OpenCL developers to write code with extensive use of pointer-linked data structures like linked lists or trees that are shared between the host and a device side of an OpenCL application. In OpenCL 1.2, the specification doesn't provide any guarantees that a pointer assigned on the host side can be used to access data in the kernel on the device side or vice versa. Thus, data with pointers in OpenCL 1.2 cannot be shared between the sides, and the application should be designed accordingly, for example, with indices used instead of pointers. This is an artifact of a separation of address spaces of the host and the device that is addressed by OpenCL 2.0 SVM.

OpenCL 2.0 的顯著功能之一™共享虛擬內存（SVM）。此功能使 OpenCL 開發人員能夠編寫代碼，廣泛使用指針鏈接的數據結構，如在 OpenCL 應用程序的主機和設備端之間共享的鏈接列表或樹。在 OpenCL 1.2 中，規范不提供任何保證，保證在主機端分配的指針可用於訪問設備端內核中的數據，反之亦然。因此，在 OpenCL 1.2 中具有指針的數據不能在兩者之間共享，並且應用程序應相應地進行設計，例如，使用索引而不是指針。這是由OpenCL 2.0 SVM尋址的主機和設備地址空間分離的產物。

Figure 1: OpenCL 1.2和常規緩沖區中的地址空間及其映射內容的示意圖

OPenCL 2.0 Shared Virtual Address Space

OpenCL 2.0中地址空間的示意圖及其在分配SVM緩沖區的區域中的重疊。顯示了常規緩沖區及其映射的內容以進行比較。

OpenCL 2.0中支持系統SVM的地址空間的示意圖

結論和要點

借助OpenCL 2.0，對共享虛擬內存（SVM）的支持為編程模型引入了最重要的改進之一。以前，主機和OpenCL設備的內存空間是不同的，這增加了OpenCL主機邏輯的復雜性。現在，SVM彌合了差距，因此主機和OpenCL設備都可以使用單個指針訪問內存。

SVM最重要的是一種生產力功能，它使將現有C / C ++代碼移植到OpenCL更加簡單，尤其是對於指針鏈接的數據結構。但是SVM不僅要消除多余的主機OpenCL代碼，它還可以通過使用原子對SVM內存的細粒度一致訪問來實現主機和OpenCL設備之間更緊密的同步。

根據OpenCL平台的硬件功能，有不同級別的SVM支持。對於開發人員而言，了解SVM類型之間的差異並相應地設計主機邏輯非常重要。

SVM支持的級別更高-從粗粒度的緩沖區SVM遷移到細粒度的系統SVM-它提供的主機邏輯組織的生產方式更加有效。同時，使用高級級別的SVM支持會降低主機OpenCL代碼的可移植性，因為並非所有OpenCL 2.0平台都提供所有SVM功能。因此，為OpenCL應用程序選擇目標SVM類型是生產力和可移植性之間的權衡。

The Compute Architecture of Intel® Processor Graphics Gen9

Intel® Processor Graphics

Architecture Overview for Intel® Processor Graphics Gen11

Optimizing Matrix Multiply for Intel® Processor Graphics Architecture Gen9

Shared Virtual Memory

Pass a Pointer: Exploring Shared Virtual Memory Abstractions in OpenCL Tools for FPGAs

Developer and Optimization Guide for Intel® Processor Graphics Gen11 API

all Compute+Architecture+of+Intel+Processor+Graphics

相關論文，lect10.pdf FelixFPT17.pdf

The-Compute-Architecture-of-Intel-Processor-Graphics-Gen9-v1d0.pdf

The-Architecture-of-Intel-Processor-Graphics-Gen11_R1new.pdf

OpenCL 1.x中的主機設備通信（左）；通過OpenCL 2.0細粒度系統SVM進行通信（右）

自定義SVM基礎結構

OpenCL細粒度系統SVM需要三個基准功能。首先，主機指針帶有操作系統通過系統調用malloc和new分配的虛擬地址。但是，通過內核總線接口在寄存器傳輸級別（RTL）進行的內存訪問使用物理地址。因此，需要從虛擬地址到物理地址的轉換，以使主機指針在設備地址空間中有意義。

其次，虛擬到物理地址轉換必須嵌入到內存管理單元中，該內存管理單元處理內核對SVM的訪問並執行實際的數據傳輸。

第三，通過原子加載/存儲操作進行並發內存訪問的細粒度主機設備同步需要一種機制，以確保防止主機或內核對共享數據的訪問受到另一方的干擾，直到另一方訪問同一位置為止。訪問已完成（訪問的原子性）。

我們的OpenCL SVM框架的目標平台是一個Intel Cyclone V SoC，它由可編程邏輯和運行Linux和Intel FPGA OpenCL運行時環境（版本16.0）的雙核32位ARM處理器組成。

雖然我們的框架將來可以移植到不同的體系結構，但是下面描述的一些基礎結構細節是特定於Cyclone V體系結構的。

具體來說，這適用於虛擬到物理地址轉換（由於ARM特定的虛擬內存系統架構）和將ARM內核與FPGA連接的物理總線接口（SoC片上總線架構）。

虛實地址轉換

使用ARM系統架構中的頁表進行地址轉換

傳遞給內核的主機指針包含操作系統分配的虛擬內存地址。當ARM內核執行內存訪問時，它會通過在Linux頁表中進行查找，從虛擬地址中獲取物理內存地址。頁表駐留在系統內存中，並存儲活動內存頁的物理地址。 ARM體系結構使用兩級轉換表層次結構，如圖3所示。第一級轉換表的基地址存儲在CPU系統寄存器（TTBR0）[16]中，可以在Linux內核中讀取該寄存器。模式。

通過指針值的高12位（32位虛擬地址）對第一級表進行索引，然后通過查找來獲取相應第二級頁表的基址。后者由虛擬地址位的第二部分索引。然后第二次查找將得出4 KB頁面的物理地址。

請求數據的物理內存地址由頁面地址和虛擬地址的低12位組成。在我們的框架中，FPGA內核與CPU處於同等地位，並且應具有獨立於主機程序啟動對CPU系統內存本身的訪問的能力。因此，內核必須擁有以FPGA邏輯實現的自己的虛擬地址到物理地址的轉換。

轉換過程先於內核進行的每個SVM訪問。轉換單元通過主總線橋直接訪問系統內存中的Linux頁表，該總線橋通過ACP連接ARM內核和可編程邏輯。為了通知內核第一級頁表的基地址，在主機程序中的OpenCL初始化代碼期間（使用我們框架提供的驅動程序模塊）讀取TTBR0系統寄存器的值並進行傳遞作為默認參數添加到內核。利用該基地址，翻譯單元執行兩次系統存儲器讀取，以遍歷第一和第二級頁表並獲得請求字的物理地址。在極少數的頁面錯誤事件中，即不存在有效物理頁面的虛擬地址，在地址轉換過程中會檢測到這些虛擬地址並觸發CPU中斷（使用Cyclone V中的備用FPGA至主機中斷請求端口）。軟件中斷例程獲取丟失的頁面，然后重復內核的地址轉換。默認情況下，頁表遍歷以32位字的粒度執行。地址轉換單元的實現是以下部分的一部分。

自定義SVM基礎結構

OpenCL細粒度系統SVM需要三個基准功能。

首先，主機指針帶有操作系統通過系統調用malloc和new分配的虛擬地址。但是，通過內核總線接口在寄存器傳輸級別（RTL）進行的內存訪問使用物理地址。因此，需要從虛擬地址到物理地址的轉換，以使主機指針在設備地址空間中有意義。
其次，虛擬到物理地址轉換必須嵌入到內存管理單元中，該內存管理單元處理內核對SVM的訪問並執行實際的數據傳輸。
第三，通過原子加載/存儲操作進行並發內存訪問的細粒度主機設備同步需要一種機制，以確保防止主機或內核對共享數據的訪問受到另一方的干擾，直到另一方訪問同一位置為止。訪問已完成（訪問的原子性）。
我們的OpenCL SVM框架的目標平台是一個Intel Cyclone V SoC，它由可編程邏輯和運行Linux和Intel FPGA OpenCL運行時環境（版本16.0）的雙核32位ARM處理器組成。雖然我們的框架將來可以移植到不同的體系結構，但是下面描述的一些基礎結構細節是特定於Cyclone V體系結構的。
具體來說，這適用於虛擬到物理地址轉換（由於ARM特定的虛擬內存系統架構）和將ARM內核與FPGA連接的物理總線接口（SoC片上總線架構）。

內存管理單元

內存管理單元（MMU）集成了虛擬地址到物理地址的轉換以及加載/存儲功能，以執行實際的數據訪問。該單元是一個RTL模塊，已添加到FPGA內核邏輯中。

地址轉換由兩次系統內存讀取組成，而實際的數據訪問是對系統內存的讀取或寫入訪問。圖4示出了基本存儲器管理單元的實現。它與其余內核邏輯的接口是類似FIFO的Avalon流輸入和輸出接口，其信號指示新數據（valid_in和valid_out）和反壓（stall_out和stall_in）以及數據輸入和輸出的可用性。該單元由一個加載/存儲單元（LSU）組成，該單元處理對系統總線的內存訪問請求。 LSU連接到FPGA到處理器的片上總線橋（存儲器映射的Avalon-MM接口）

為了使高速緩存通過ACP對CPU系統存儲器進行一致的訪問，請在Cyclone V SoC上進行訪問。 LSU包含一個FIFO緩沖區，該緩沖區緩沖輸出數據，直到下游節點可以拾取它為止。有限狀態機（FSM）控制LSU並管理停頓和有效信號，以與內核邏輯的其余部分進行交互。在內存管理單元的基本版本中，用於地址轉換和實際數據訪問的兩個頁表查找在單個LSU上進行時間復用。

我們探索內存管理單元的幾種設計選擇。圖5顯示了圖4中單元的流水線版本。它不是對三個總線訪問進行時分多路復用，而是在空間上展開所需的LSU和FSM，以便內核模塊在完成第一個流水線階段后立即接受新請求。並實時處理多個SVM請求。對FPGA到處理器總線橋的並發訪問的仲裁被分流到Avalon總線互連。雖然這兩個版本在FPGA區域之間交換了吞吐量，但我們可以配置LSU使其包含進一步影響這一折衷的功能。首先，可以更改LSU處理一系列請求的方式：

◦基本：LSU一次處理一個請求。它使上游節點停止運行，直到完成內存請求為止。

◦靜態突發合並：如果已知n個請求序列中的地址嚴格連續，則將這些地址編譯為長度為n的突發訪問（假設n小於最大突發長度），通常比獨立的順序訪問更有效。 LSU將停止上游節點，直到突發訪問已完成。

◦動態突發合並：如果不知道n個請求序列中的地址總是嚴格連續的，但是在大多數情況下都是連續的，則動態突發合並會很有效。只要到達的請求具有相對於先前請求的連續地址，LSU就會在將請求以突發形式發送給總線之前保持收集請求，並旨在編譯可能的最大突發。

其次，各個LSU可以配置為包括直接映射的片上高速緩存。在LSU用於“虛擬到物理轉換”（圖5中的LSU 0和LSU 1）的情況下，高速緩存對應於轉換后備緩沖區（TLB），　存儲頁表查找的最新歷史記錄。

FPGA內核通常包含與OpenCL代碼中的SVM加載/存儲指令一樣多的存儲器管理單元。所有單元都通過Avalon總線互連連接到FPGA至處理器的總線橋。以下部分描述了SVM基礎結構的擴展，以啟用細粒度的主機設備同步。

系統內存原子訪問

除了支持共享地址空間外，我們的內存管理單元還可以配置為包括主機設備的同步機制，以實現原子加載/存儲操作。該機制是通過使用鎖定服務（在提供給程序員的原子內存指令的高級視圖下）實現的。為此，內存管理單元具有一個附加的Avalon總線接口，以請求鎖的所有權。圖6（左）顯示了鎖定服務的體系結構。鎖服務器從其核心服務於從主機程序以及FPGA內核中的一個或幾個MMU兩者獲取和釋放鎖的請求。后者通過Avalon總線互連連接到服務器。來自主機端的鎖定請求命令是通過Cyclone V架構中的另一個CPU-FPGA總線橋接收的：
輕量級的處理器到FPGA的橋接器，專為低吞吐量，小批量傳輸而設計。

圖6（右）顯示了鎖服務器內部的狀態機。命令host_acquire，host_release，dev_acquire_x和dev_release_x緩存在請求隊列中，分別指示主機和設備希望獲取或釋放鎖的願望。鎖定服務器確認已成功完成對客戶端的請求。在發出實際的內存操作之前，內存管理單元將暫停直到收到此請求。在主機方面，原子內存操作在等待確認的同時輪詢內存映射的處理器到FPGA總線橋接器。
輕量級的處理器到FPGA接口也用於交換數據以進行頁面錯誤處理

Comparison with OpenCL 1.x

除了內存訪問單元，流水線內核實現在所有設計中都是相同的。內核時間的主要區別僅源於不同的內存訪問時間。圖9顯示了四種設計的系統執行時間細分。由於Cyclone V [13]上CPU和FPGA之間不存在直接存儲器訪問（DMA）功能，因此設計1在將樹形緩沖區復制到設備存儲器上花費了大量時間（> 8 s）。設計2完全避免了加載時間。其他沒有共享物理內存但具有DMA支持的平台將在設計2處使用OpenCL命令clEnqueueMapBuffer而不是常規的new / malloc命令在主機端分配“樹數組”，這將導致主機對樹的訪問速度變慢在植樹期間。兩個非SVM內核都直接訪問DDR內存，因此內核執行速度很快。相比之下，這兩種SVM設計由於對樹數據的訪問速度較慢而具有更長的內核執行時間，但它們也避免了整個樹的初始副本。

對於設計3，必須保證存儲在樹節點上的14個32位字位於物理上連續的內存位置。這使樹節點的內存分配變得復雜，從而給主機和設備的內存訪問帶來了時間損失。

Design 4動態地聚合突發，並不嚴格要求此保證。該設計可以使用常規的new / malloc命令來構建樹，並且在所有SVM設計中都具有最佳性能。我們在Design 4中使用流水線式動態突發合並MMU的SVM實現比標准OpenCL 1.x實現的性能高2倍，並且執行時間與共享物理內存的OpenCL 1.x實現的性能接近。

工具整合　　

我們的SVM框架是作為用於OpenCL的英特爾FPGA SDK的附加組件實現的。上面描述的SVM構建塊已添加到工具流程中，並由用戶在OpenCL主機和內核代碼中調用。在主機端，提供了一個應用程序編程接口（API），使程序員可以使用我們的SVM功能並與之交互。我們的框架還為內核提供了API。程序員通過內核代碼中的函數調用實例化SVM加載/存儲指令。除了常規內核邏輯之外，這些調用還觸發了FPGA邏輯中自定義RTL模塊的實例化。圖7顯示了OpenCL SDK生成的硬件設計。圖7中帶有灰色陰影的部分（即內存管理單元，鎖定服務器，附加的Avalon總線配置和ACP配置）自動添加到OpenCL的構建流程中。為此，在系統設計生成后停止OpenCL流程，並通過自動的源到源轉換來修改生成的RTL，以包括自定義SVM功能。下一節評估了我們的SVM基礎架構的性能，並提出了一個設計空間探索，涵蓋了IV-B節中描述的內存管理單元的不同實現選項。

結論

OpenCL SVM通過賦予FPGA內核無縫地取消對在主機軟件中創建的指針的引用的能力以及在主機和設備之間並行共享數據結構的情況下提供確保數據一致性的機制，極大地簡化了異構CPU-FPGA系統的編程。我們提供了一個開放源代碼的框架，該框架會自動將SVM功能添加到使用面向Cyclone V SoC的針對OpenCL的英特爾FPGA SDK開發的實現中。使用此框架，我們將為底層的SVM構建塊提供設計空間探索。通過實際的基准測試應用程序，我們可以證明，與基於OpenCL 1.x的等效實現方式相比，這種設計空間探索的最快變體可以將端到端系統的執行時間減少1.5倍至2.3倍。

如果訪問的主機數據部分與最壞情況相比較小，則我們的SVM實現將使用共享的物理內存來估計特殊情況的執行時間。我們得出的結論是，除了易於編程之外，在OpenCL SVM的支持下，避免了人為地調整動態共享數據結構和僅在需要時才獲取數據的要求，這可能會導致性能提升。未來的工作將包括探索更大的基准集，我們希望對基准的SVM構建基塊實現展現不同的權衡。我們還計划部署靜態程序分析，以實現這些實現的特定於應用程序的優化。