gpu编译技术
㈠ 关于GPU的问题！
目录：
第一章：第二代及以后的GPU工作流程简介
第二章：DirectX8和DirectX9 GPU的传统流水线
第三章：顶点和像素操作指令
第四章：传统GPU指令的执行
第五章：统一渲染架构
第六章：G80和R600的统一渲染架构实现
第七章：G80与R600效能对比
第八章：尴尬的中端--Geforce8600简析
前面4章 我将先简要介绍下DirectX8/9显卡的核心----图形处理单元GPU的工作流程和指令处理情况
从第5章开始讨论统一渲染架构、新一代DirectX10 GPU的特性，G80/Geforce8800与R600/RadeonHD2900XT的架构具体实现及其区别。最后将会对中端最受关注的Geforce8600进行相应的简单分析。
第一章：第二代及以后的GPU工作流程简介
简单（而不一定绝对科学）的说：GPU主要完成对3D图形的处理--图形的生成渲染。
GPU的图形（处理）流水线完成如下的工作：（并不一定是按照如下顺序）
顶点处理：这阶段GPU读取描述3D图形外观的顶点数据并根据顶点数据确定3D图形的形状及位置关系，建立起3D图形的骨架。在支持DX8和DX9规格的GPU中，这些工作由硬件实现的Vertex Shader（定点着色器）完成。
光栅化计算：显示器实际显示的图像是由像素组成的，我们需要将上面生成的图形上的点和线通过一定的算法转换到相应的像素点。把一个矢量图形转换为一系列像素点的过程就称为光栅化。例如，一条数学表示的斜线段，最终被转化成阶梯状的连续像素点。
纹理帖图：顶点单元生成的多边形只构成了3D物体的轮廓，而纹理映射（texture mapping）工作完成对多变形表面的帖图，通俗的说，就是将多边形的表面贴上相应的图片，从而生成“真实”的图形。TMU（Texture mapping unit）即是用来完成此项工作。
像素处理：这阶段（在对每个像素进行光栅化处理期间）GPU完成对像素的计算和处理，从而确定每个像素的最终属性。在支持DX8和DX9规格的GPU中，这些工作由硬件实现的Pixel Shader（像素着色器）完成。
最终输出：由ROP（光栅化引擎）最终完成像素的输出，1帧渲染完毕后，被送到显存帧缓冲区。
总结：GPU的工作通俗的来说就是完成3D图形的生成，将图形映射到相应的像素点上，对每个像素进行计算确定最终颜色并完成输出。
第二章：DirectX8和DirectX9 GPU的传统流水线
前面的工作流程其实已经说明了问题。本章来总结一下，承前启后。
传统的GPU功能部件我们不妨将其分为顶点单元和像素流水线两部分。
顶点单元由数个硬件实现的Vertex Shader组成。
传统的像素流水线由几组PSU(Pixel Shader Unit)+TMU+ROP组成。
于是，传统的GPU由顶点单元生成多边形，并由像素流水线负责像素渲染和输出。
对于像素流水线需要做的说明是：虽然传统的流水线被认为=1PSU+1TMU+1ROP，但这个比例不是恒定的，例如在RadeonX1000（不包括X1800）系列中被广为称道的3:1黄金架构，PSU:TMU:ROP的数量为3：1：1。一块典型的X1900显卡具有48个PSU，16个TMU和16个ROP。之所以采用这种设计方法，主要考虑到在当今的游戏中，像素指令数要远远大于纹理指令的数量。ATI凭借这个优秀的架构，成功击败了Geforce7，在DX9后期取得了3D效能上的领先。
总结：传统的GPU由顶点单元生成多边形，像素流水线渲染像素并输出，一条像素流水线包含PSU，TMU，和ROP(有的资料中不包含ROP)，比例通常为1:1:1，但不固定。
第三章：顶点和像素操作指令
GPU通过执行相应的指令来完成对顶点和像素的操作。
熟悉OpenGL或Direct3D编程的人应该知道，像素通常使用RGB三原色和alpha值共4个通道（属性）来描述。而对于顶点，也通常使用XYZ和W 4个通道（属性）来描述。因而，通常执行一条顶点和像素指令需要完成4次计算，我们这里成这种指令为4D矢量指令（4维）。当然，并不是所有的指令都是4D指令，在实际处理中，还会出现大量的1D标量指令以及2D，3D指令。
总结：由于定点和像素通常用4元组表示属性，因而顶点和像素操作通常是4D矢量操作，但也存在标量操作。
第四章：传统GPU指令的执行
传统的GPU基于SIMD的架构。SIMD即Single Instruction Multiple Data，单指令多数据。
其实这很好理解，传统的VS和PS中的ALU（算术逻辑单元，通常每个VS或PS中都会有一个ALU，但这不是一定的，例如G70和R5XX有两个）都能够在一个周期内（即同时）完成对矢量4个通道的运算。比如执行一条4D指令，PS或VS中的ALU对指令对应定点和像素的4个属性数据都进行了相应的计算。这便是SIMD的由来。这种ALU我们暂且称它为4D ALU。
需要注意的是，4D SIMD架构虽然很适合处理4D指令，但遇到1D指令的时候效率便会降为原来的1/4。此时ALU 3/4的资源都被闲置。为了提高PS VS执行1D 2D 3D指令时的资源利用率，DirectX9时代的GPU通常采用1D+3D或2D+2D ALU。这便是Co-issue技术。这种ALU对4D指令的计算时仍然效能与传统的ALU相同，但当遇到1D 2D 3D指令时效率则会高不少，例如如下指令：
ADD R0.xyz , R0,R1 //此指令是将R0,R1矢量的x,y,z值相加 结果赋值给R0
ADD R3.x , R2,R3 //此指令是将R2 R3矢量的w值相加 结果赋值给R3
对于传统的4D ALU，显然需要两个周期才能完成，第一个周期ALU利用率75% ，第二个周期利用率25%。而对于1D+3D的ALU，这两条指令可以融合为一条4D指令，因而只需要一个周期便可以完成，ALU利用率100%。
但当然，即使采用co-issue，ALU利用率也不可能总达到100%，这涉及到指令并行的相关性等问题，而且，更直观的，上述两条指令显然不能被2D+2D ALU一周期完成，而且同样，两条2D指令也不能被1D+3D ALU一周期完成。传统GPU在对非4D指令的处理显然不是很灵活。
总结：传统的GPU中定点和像素处理分别由VS和PS来完成，每个VS PS单元中通常有一个4D ALU，可以在一个周期完成4D矢量操作，但这种ALU对1D 2D 3D操作效率低下，为了弥补，DX9显卡中ALU常被设置为1D+3D 2D+2D等形式。
第五章：统一渲染架构
相对于DirectX 9来说，最新的DirectX 10最大的改进在于提出了统一渲染架构，即Unified Shader。
传统的显卡GPU一直采用分离式架构，顶点处理和像素处理分别由Vertex Shader和Pixel Shader来完成，于是，当GPU核心设计完成时，PS和VS的数量便确定下来了。但是不同的游戏对于两者处理量需求是不同的，这种固定比例的PS VS设计显然不够灵活，为了解决这个问题，DirectX10规范中提出了了统一渲染架构。
不论是顶点数据还是像素数据，他们在计算上都有很多共同点，例如通常情况下，他们都是4D矢量，而且在ALU中的计算都是没有分别的浮点运算。这些为统一渲染的实现提供了可能。
在统一渲染架构中，PS单元和VS单元都被通用的US单元所取代，nVidia的实现中称其为streaming processer，即流处理器，这种US单元既可以处理顶点数据，又可以处理像素数据，因而GPU可以根据实际处理需求进行灵活的分配，这样便有效避免了传统分离式架构中VS和PS工作量不均的情况。
总结：统一渲染架构使用US（通常为SP）单元取代了传统的固定数目的VS和PS单元，US既可以完成顶点操作，又可以完成像素操作，因而可以根据游戏需要灵活分配，从而提高了资源利用率。
第六章：G80和R600的统一渲染架构实现
以下我们着重讨论G80和R600的统一着色单元而不考虑纹理单元，ROP等因素。
G80 GPU中安排了16组共128个统一标量着色器，被叫做stream processors，后面我们将其简称为SP。每个SP都包含有一个全功能的1D ALU。该ALU可以在一周期内完成乘加操作（MADD）。
也许有人已经注意到了，在前面传统GPU中VS和PS的ALU都是4D的，但在这里，每个SP中的ALU都是1D标量ALU。没错，这就是很多资料中提及的MIMD（多指令多数据）架构，G80走的是彻底的标量化路线，将ALU拆分为了最基本的1D 标量ALU，并实现了128个1D标量SP，于是，传统GPU中一个周期完成的4D矢量操作，在这种标量SP中需4个周期才能完成，或者说，1个4D操作需要4个SP并行处理完成。
这种实现的最大好处是灵活，不论是1D,2D,3D,4D指令，G80得便宜其全部将其拆成1D指令来处理。指令其实与矢量运算拆分一样。
例如一个4D矢量指令 ADD R0.xyzw , R0,R1 R0与R1矢量相加,结果赋R0
G80的编译器会将其拆分为4个1D标量运算指令并将其分派给4个SP：
ADD R0.x , R0,R1
ADD R0.y , R0,R1
ADD R0.z , R0,R1
ADD R0.w, R0,R1
综上：G80的架构可以用128X1D来描述。
R600的实现方式则与G80有很大的不同，它仍然采用SIMD架构。
在R600的核心里，共设计了4组共64个流处理器，但每个处理器中拥有1个5D ALU，其实更加准确地说，应该是5个1D ALU。因为每个流处理器中的ALU可以任意以1+1+1+1+1或1+4或2+3等方式搭配（以往的GPU往往只能是1D+3D或2D+2D）。ATI将这些ALU称作streaming processing unit，因而，ATI宣称R600拥有320个SPU。
我们考虑R600的每个流处理器，它每个周期只能执行一条指令，但是流处理器中却拥有5个1D ALU。ATI为了提高ALU利用率，采用了VLIW体系(Very Large Instruction Word)设计。将多个短指令合并成为一组长的指令交给流处理器去执行。例如，R600可以5条1D指令合并为一组5DVLIW指令。
对于下述指令：
ADD R0.xyz , R0,R1 //3D
ADD R4.x , R4,R5 //1D
ADD R2.x , R2,R3 //1D
R600也可以将其集成为一条VLIW指令在一个周期完成。
综上：R600的架构可以用64X5D的方式来描述。
总结：G80将操作彻底标量化，内置128个1D标量SP，每个SP中有一个1D ALU，每周期处理一个1D操作，对于4D矢量操作，则将其拆分为4个1D标量操作。
R600仍采用SIMD架构，拥有64个SP，每个SP中有5个1D ALU，因而通常声称R600有320个PSU，
每个SP只能处理一条指令，ATI采用VLIW体系将短指令集成为长的VLIW指令来提高资源利用率，例如5条1D标量指令可以被集成为一条VLIW指令送入SP中在一个周期完成。
第七章：G80与R600效能对比
从前一章的讨论可以看出，R600的ALU规模64X5D=320明显比G80的128X1D=128要大，但是为何在实际的测试中，基于R600的RadeonHD2900XT并没有取得对G80/Geforce8800GTX的性能优势？本章将试图从两者流处理器设计差别上来寻找答案，对于纹理单元，ROP，显存带宽则不做重点讨论。事实上，R600的显存带宽也要大于G80。
我们将从频率和执行效能两个方面来说明问题：
1、频率：G80只拥有128个1D流处理器，在规模上处于绝对劣势，于是nVidia采用了shader频率与核心频率异步的方式来提高性能。Geforce8800GTX虽然核心频率只有575MHZ，但shader频率却高达1375MHZ，即SP工作频率为核心频率的两倍以上，而R600则相对保守地采用了shader和核心同步的方式，在RadeonHD2900XT中，两者均为740MHZ。这样一来，G80的shader频率几乎是R600的两倍，于是就相当于同频率下G80的SP数加倍达到256个，与R600的320个接近了很多。在处理乘加（MADD）指令的时候，740MHZ的R600的理论峰值浮点运算速度为：740MHZ*64*5*2=473.6GFLOPS 而shader频率为1350MHZ的G80的浮点运算速度为：1350MHZ*128*1*2=345.6GFLOPS，两者的差距并不像SP规模差距那么大。
2、执行效能：G80虽说shader频率很高，但由于数量差距悬殊，即使异步也无法补回理论运算速率的差距。于是，要寻找答案，还要从两者流处理器的具体设计着手。
在G80中，每个矢量操作都会被拆分为1D标量操作来分配给不同的SP来处理，如果不考虑指令并行性等问题，G80在任何时刻，所有SP都是充分利用的。而R600则没这么幸运，因为每个流处理器只能同时处理一条指令，因而R600要将短指令合并为能充分利用SP内5DALU运算资源的VLIW指令，但是这种合并并不是总能成功。目前没有资料表明R600可以将指令拆开重组，也就是说，R600不能每时每刻都找到合适的指令拼接为5D指令来满载他的5D SP，这样的话我们假设处理纯4D指令的情况，不能拆分重组的话，R600每个SP只能处理一条4D指令，利用率80%，而对于G80，将指令拆开成1D操作，无论何时都能100%利用。而且，R600的结构对编译器的要求很高，编译器必须尽可能寻找Shader指令中的并行性，并将其拼接为合适的长指令，而G80则只需简单拆分即可。
另外还需要说明的一点是，R600中每个SP的5个1D ALU并不是全功能的，据相关资料，每组5个ALU中，只有一个能执行函数运算，浮点运算和Multipy运算，但不能进行ADD运算，其余的4各职能执行MADD运算。而G80的每个1D ALU是全功能的，这一点也在一定程度上影响了R600的效能。
总结：虽然R600的ALU规模远大于G80，但G80的SP运行频率几乎是R600的两倍，而且G80的体系架构采用完全标量化的计算，资源利用率更高，执行效能也更高，因而总体性能不落后于R600。
第八章：尴尬的中端--Geforce8600简析
在新一代中端显卡中，最早发布也是最受关注的莫过于nVidia的G84---Geforce8600系列。
但是相比其高高在上的价格，它的性能表现实在不尽如人意，很多测试中均落后于价格低于它的老一代高端显卡Geforce7900GS。本章将利用前面讨论的结论对G84核心的SP处理能力作简要地分析。
G84是G80核心的高度精简版本，SP数量从G80的128个锐减为32个，显存位宽也降为1/3--128bit。
抛开显存位宽和TMU ROP，我们着重看SP，G84的SP频率与核心频率也不相同，例如8600GT，核心频率只有540MHZ，shader频率却高达1242MHZ，即核心频率的两倍多，我们粗略按两倍记，则G84核心相当于核心shader同步的64(个1D标量) SP，而传统的VS和PS中ALU是4D的，于是可以说G84的计算能力相当于传统VS和PS总数为64/4=16的显卡，粗略比较，它与Geforce7600（PS+VS=17）的计算能力相近。但当然，事实这样比较是有问题的，因为在G7X中，每个PS中有两个4D ALU，因而7600的运算能力高于传统PS+VS=17的显卡。下面的计算就说明了问题：（MADD操作）
对于7600GT ，VS为4D+1D PS为4D+4D 核心频率560MHZ 理论峰值浮点运算速度：
560MHZ*（12*（4+4）+5*（1+4））*2=135.52GFLOPS
而对于8600GT：1242MHZ*32*1*2=79.4GFLOPS
由此可见，8600GT的峰值运算速度甚至远低于上代的7600GT，更不用跟7900GS相比了。但是，实际情况下，迫于传统架构所限，G7X满载的情况基本不可能出现，G7X的实际运算速率要远低于理论值，而对于G8X架构，执行效率则高很多，实际运算速率会更加接近理论极限。而且支持SM4.0的G8X寄存器数目也要远多于G7X，众多效率优势，使得Geforce8600GT仅凭借少量的SP就足以击败上代中端7600GT。
但是作为DX10显卡，仅仅击败7600GT显然不是最终目标，仅32SP的它在计算量要求空前之高的DX10游戏中表现极差，根本不能满足玩家要求。
总结：8600GT性能上取代7600GT的目标凭借着高效的统一渲染架构总算勉强完成，但过少的SP数量使得其显然难以击败上代高端，更不用说流畅运行DX10游戏了，而高高在上的价位更使其处境不利，归根到底，nVidia对G84 SP数量的吝啬以及过高的价格定位造就了Geforce8600的尴尬，因此，就目前的情况来看，选用8600系列显然不如Geforce7900和RadeonX1950GT来的划算。
㈡ 电脑中GPU是什么啊
图形处理器(英语:Graphics Processing Unit，缩写:GPU)，又称显示核心、视觉处理器、显示芯片，是一种专门在个人电脑、工作站、游戏机和一些移动设备(如平板电脑、智能手机等)上图像运算工作的微处理器。
GPU是显示卡的“大脑”，它决定了该显卡的档次和大部分性能，同时也是2D显示卡和3D显示卡的区别依据。2D显示芯片在处理3D图像和特效时主要依赖CPU的处理能力，称为“软加速”。3D显示芯片是将三维图像和特效处理功能集中在显示芯片内，也即所谓的“硬件加速”功能。显示芯片通常是显示卡上最大的芯片(也是引脚最多的)。现在市场上的显卡大多采用NVIDIA和 AMD-ATI两家公司的图形处理芯片。
拓展资料：
GPU主流供应商
intel：intel不但是世界上最大的CPU生产销售商，也是世界最大的GPU生产销售商。 intel的GPU在现在完全是集成显卡，用于intel的主板和intel的笔记本。要是只按发售数量计算，intel随着他主板发售的集成GPU占据了整个GPU市场的60%以上。
nVidia：现在最大的独立显卡生产销售商，旗下有民用的Geforce系列，还有专业的Quadro系列。其GPU具有cuda通用运算，PureVideo高清视频技术，PhysX物理加速，Optimus智能显卡切换等。
AMD(ATI)：世界上第二大的独立显卡生产销售商，他的前身就是ATI。旗下有民用的Radeon系列，还有专业的FireGL系列等。就发售量和发售盈利方面，AMD显卡方面仍然略输于nv,不过两者不相伯仲，差距只是几个百分点。其GPU具有Stream通用运算，ATI Video Converter视频转码，UVD高清视频技术，Havok、Bullet和Pixelux DMM三种物理引擎等。
㈢ GPU编程常识求助：cg、opencv、opengl、cuda、glsl等
你好，
首先，cg，opengl，glsl都是跟计算机图形有关的。cg基本是做渲染的，opengl是一个开源图形库，和微软的direct3D是一样的。glsl是shading language ，专门用来写shader的，在GPGPU（ general purpose GPU）概念出来之前，好多人用glsl来做并行计算。
其次，CUDA和OpenCL是两个专门做GPU运算的库。CUDA非常好用，它有自己的NVCC编译器，和各个系统都兼容很好，但是仅限于用于NVIDIA自己的显卡。OpenCL虽然任何显卡都可以使用，但是它的GPU的代码要放到单独的一个文本文件中编译，操作上要比CUDA要复杂。
最后，其实CUDA和OpenCL学那个多一样，因为并行运算的思想是一样的。推荐你两本书：
Programming Massively Parallel Processors 2nd（入门）
CUDA Programming A Developer-'s Guide to Parallel Computing with GPUs （高级一点）
谢谢，望采纳
㈣ gpu二缓一致
gpu二缓一致，GPU的LLC是全部SM共享的，memory-side caching, 采用write-back policy,不存在一致性的问题，在异构架构中，我们可以在CPU和加速器之间暴露一个全局的共享内存接口，我们假设CPU、GPU等设备共享相同的物理内存（如手机上的SoC这种情况），如下图所示。在这种系统中，共享内存会引发一些新的问题，如什么是内存一致性模型？内存一致性模型如何实现？加速器和处理器的私有缓存如何保持一致？我们接下来首先讨论加速器内的内存一致性和缓存一致性，重点是GPU，然后讨论跨加速器的内存一致性和缓存一致性。
异构SoC系统模型
GPU的内存一致性和缓存一致性
早期GPU的架构余前与编程模型
早期GPU主要为并行图形工作负载设计，特点是数据并行度高，但数据共享、同步和通信程度低。
GPU架构
GPU通常有几十个内核，叫做流式多处理器（Streaming Multiprocessors，SM），每个SM都是高度多线程的，能够运行上千条线程，映射到SM上的线程共享L1缓存和本地scratchpad内存，所有的SM都共享一个L2缓存。GPU通常将线程分组执行，称为warps，一个warp中的所有线程共享PC和堆栈，可以使用掩码来执行独立的线程，表明哪些线程在执行，哪些线程没有在执行，这种并行方式就是我们常听说的SIMT。但是最近，GPU开始允许一个warp中的线程有独立的PC和堆栈，允许线程独立调度，我们接下来也假设线程是可以独立调度的。
由于图形工作负载并不经常共享数据或进行同步，早期GPU选择不在L1缓存实现硬件的缓存一致性。
GPU编程模型
和CPU类似，GPU也有一套虚拟仿配ISA，同时也有一套更高级别的语言框架，如CUDA和OpenCL，框架中的高级语言被编译成虚拟的ISA，并被翻译为本地的二进制文件。GPU虚拟ISA和高级语言框架通过被称为作用域（scope）的线程结构，向程序员暴露GPU架构的层次结构。和CPU相比，GPU线程被分组为叫做Cooperative Thread Arrays（CTA）的集群。CTA作用域指来自同一个CTA的线程集合，保证映射到相同的SM，并共享同一个L1huancun。GPU作用域指的是来自同一个GPU的线程集合，可以来自相同或不同的CTA，并共享L2缓存。最后，系统作用域指整个系统所有线程的集合，共享LLC缓存或统一的共享内存。
这种方式可以在没有硬件缓存一致性的情况下，用软件的方式实现数据同步和通信。
GPU内存一致性
GPU支持宽松一致性模型，通过FENCE指令进行同步，但是由于没有硬件缓存一致性，GPU的FENCE只针对属于同一CTA的其他线程。GPU的store指令也不保证原子性。
因此，早期GPU明确禁止在CTA组之间进行数据同步，但实践中可以通过绕过L1，在L2上进行同步。这种方案也有一些问题，绕过L1会导致性能下降，且程序员需要仔细地编写程序。
测验问题8：GPU不支持硬件缓存一致性，因此无法实现内存一致性模型。
答：错误。早期的GPU不支持硬件缓存一致性，但是支持作用域内的宽松内存一致性模型。
GPGPU的内存一致性和缓存一致性
GPGPU最好满足以下特点：
严格而直观的内存一致性模型，允许在所有线程之间进行同步
一个能够实现内存一致性模型的缓存一致性协议，允许高效的数据共享和同步，且保持常规GPU架构的简单性，因为GPU的主要任务仍然是图形工作负载
我们可以使用类似多核CPU的方法来实现缓存一致性，使用一种与内存模型无关的协议。然而这种方法并不适用于GPU，主要有两个原因。首先，类似于CPU的缓存一致性协议在GPU环境下会产生很高的通信开销，因为L1缓存的总容量通常与L2相当，甚至更大，会产生很大的面积开销，设计也非常复杂；其次，由于GPU保持着数千个活跃的硬件线程，因此需要跟踪相应数量的一致性事务，需要大量的硬件开销。
具体的技术细节可以参考原书（埋坑，GPU的部分确实现在看来有些难理解，等之后学习了GPU的架构之后再回来填坑）。
其他异构系统
我们开始进一步讨论如何在多个设备的系统中暴露一个全局的共享内存接口，难点在于每个设备都可能通过不同的一致性协议竖大清来实现不同的内存模型，当多个内存模型不同的设备被集成在一起时，异构系统的内存模型是什么样的？如何对这种系统进行编程？如何整合多个设备的缓存一致性协议？我们接下来简单讨论这些问题，并概述设计空间。
异构系统的内存模型
如果两个设备A和B连接在一起并共享内存，这种情况下的内存模型是什么样的？一个符合直觉的答案是选择其中较弱的一个作为整体的内存模型，但如果两个内存模型无法比较，这种答案就不可行了。即使两者可以比较，可能也会有更好的答案。
四个设备组成的异构系统
在如上所示的异构系统中，C1和C2内存模型为SC，C3和C4内存模型为TSO。考虑下面的例子，在第一个例子中，有可能r1和r2同时读到0，但在第二个例子中插入了FENCE后，r1和r2就不能同时读到0了，但需要注意的是在SC的线程上仍然不需要插入FENCE，这种系统实际上产生了一个不同于SC和TSO的复合内存模型。
Dekker算法的例子
在这种系统中变成也是比较困难的，很难直接精确定义复合内存模型，更好的办法可能是使用HSA或OpenCL等进行编程。
异构系统的缓存一致性协议
通过分层缓存一致性来集成多个设备
考虑两个多核设备A和B，每个设备都有自己的内存模型，并通过不同的缓存一致性协议来实现内存模型，如上图所示。我们应该如何将两个设备集成到一个共享内存异构系统中，并将两个缓存一致性协议正确连接在一起？答案取决于每个设备的内存操作是否满足自己的内存排序规则。
分层缓存一致性
在分层缓存一致性系统中，本地缓存一致性控制器收到请求后，首先试图在本地满足该请求，如果无法满足就转发到全局一致性控制器，再转发到另一个设备的本地缓存一致性控制器。在这种设计中，全局控制器必须有足够丰富的接口来满足各个设备本地控制器发起的请求，且每个本地控制器必须用shim来扩展，作为两个控制器之间的接口转换。相关的一些例子可以参考原文。
减少异构系统缓存一致性的带宽需求
在异构系统中，内核之间的缓存一致性通信带宽可能成为性能瓶颈。一种解决思路是采用粗粒度的缓存一致性，比如在GPU本地以page大小的粒度进行跟踪，如果缓存未命中且已知该位置对应的page对GPU来说是私有的或只读的，就不需要访问全局的目录，而是可以从高带宽的总线从内存直接访问。
CPU-GPU系统中缓存一致性的一个低复杂度解决方案
我们可以采用选择性的GPU缓存，任何被映射到CPU内存的数据都不会缓存在GPU中，任何来自GPU内存的数据，如果目前被缓存在CPU中，也不会被缓存在GPU中。这个简单的策略可以很好地实现缓存一致性。为了实现这种方法，GPU维护一个粗粒度的目录，维护当前由CPU缓存的数据，当CPU访问GPU内存中的一个缓存块时，这个缓存块所在的区域就被插入到目录中，目录中所有的位置都不会被缓存到GPU中。不过这种方法也有坏处，即任何被CPU缓存的数据都必须从CPU中取回，为了解决这个问题需要进行进一步的优化，如GPU对CPU的请求进行合并、在GPU上加入一个特殊的CPU侧的缓存等。