gpu编译器
Ⅰ cuda主要用于哪。具体是什么。
CUDA CUDA(Compute Unified Device Architecture)，显卡厂商NVidia推出的运算平台。 CUDA是一种由NVIDIA推出的通用并行计算架构，该架构使GPU能够解决复杂的计算问题。 它包含了CUDA指令集架构（ISA）以及GPU内部的并行计算引擎。 开发人员现在可以使用C语言来为CUDA架构编写程序，C语言是应用最广泛的一种高级编程语言。所编写出的程序于是就可以在支持CUDA的处理器上以超高性能运行。 将来还会支持其它语言，包括FORTRAN以及C++。 随着显卡的发展，GPU越来越强大，而且GPU为显示图像做了优化。在计算上已经超越了通用的CPU。如此强大的芯片如果只是作为显卡就太浪费了，因此NVidia推出CUDA，让显卡可以用于图像计算以外的目的。 目前只有G80、G92、G94和GT200平台的NVidia显卡才能使用CUDA，工具集的核心是一个C语言编译器。G80中拥有128个单独的ALU，因此非常适合并行计算，而且数值计算的速度远远优于CPU。 CUDA的SDK中的编译器和开发平台支持Windows、Linux系统，可以与Visual Studio2005集成在一起。 Geforce8CUDA（Compute Unified Device Architecture）是一个新的基础架构，这个架构可以使用GPU来解决商业、工业以及科学方面的复杂计算问题。它是一个完整的GPGPU解决方案，提供了硬件的直接访问接口，而不必像传统方式一样必须依赖图形API接口来实现GPU的访问。在架构上采用了一种全新的计算体系结构来使用GPU提供的硬件资源，从而给大规模的数据计算应用提供了一种比CPU更加强大的计算能力。CUDA采用C语言作为编程语言提供大量的高性能计算指令开发能力，使开发者能够在GPU的强大计算能力的基础上建立起一种效率更高的密集数据计算解决方案。 从CUDA体系结构的组成来说，包含了三个部分：开发库、运行期环境和驱动（表2）。 开发库是基于CUDA技术所提供的应用开发库。目前CUDA的1.1版提供了两个标准的数学运算库——CUFFT（离散快速傅立叶变换）和CUBLAS（离散基本线性计算）的实现。这两个数学运算库所解决的是典型的大规模的并行计算问题，也是在密集数据计算中非常常见的计算类型。开发人员在开发库的基础上可以快速、方便的建立起自己的计算应用。此外，开发人员也可以在CUDA的技术基础上实现出更多的开发库。 运行期环境提供了应用开发接口和运行期组件，包括基本数据类型的定义和各类计算、类型转换、内存管理、设备访问和执行调度等函数。基于CUDA开发的程序代码在实际执行中分为两种，一种是运行在CPU上的宿主代码（Host Code），一种是运行在GPU上的设备代码（Device Code）。不同类型的代码由于其运行的物理位置不同，能够访问到的资源不同，因此对应的运行期组件也分为公共组件、宿主组件和设备组件三个部分，基本上囊括了所有在GPGPU开发中所需要的功能和能够使用到的资源接口，开发人员可以通过运行期环境的编程接口实现各种类型的计算。 由于目前存在着多种GPU版本的NVidia显卡，不同版本的GPU之间都有不同的差异，因此驱动部分基本上可以理解为是CUDA-enable的GPU的设备抽象层，提供硬件设备的抽象访问接口。CUDA提供运行期环境也是通过这一层来实现各种功能的。目前基于CUDA开发的应用必须有NVIDIA CUDA-enable的硬件支持，NVidia公司GPU运算事业部总经理Andy Keane在一次活动中表示：一个充满生命力的技术平台应该是开放的，CUDA未来也会向这个方向发展。由于CUDA的体系结构中有硬件抽象层的存在，因此今后也有可能发展成为一个通用的GPGPU标准接口，兼容不同厂商的GPU产品 CUDA 工具包是一种针对支持CUDA功能的GPU（图形处理器）的C语言开发环境。CUDA开发环境包括: · nvcc C语言编译器 · 适用于GPU（图形处理器）的CUDA FFT和BLAS库 · 分析器 · 适用于GPU（图形处理器）的gdb调试器（在2008年3月推出alpha版） · CUDA运行时（CUDA runtime）驱动程序（目前在标准的NVIDIA GPU驱动中也提供） · CUDA编程手册 CUDA开发者软件开发包（SDK）提供了一些范例（附有源代码），以帮助使用者开始CUDA编程。这些范例包括: · 并行双调排序 · 矩阵乘法 · 矩阵转置 · 利用计时器进行性能评价 · 并行大数组的前缀和（扫描） · 图像卷积 · 使用Haar小波的一维DWT · OpenGL和Direct3D图形互操作示例 · CUDA BLAS和FFT库的使用示例 · CPU-GPU C—和C++—代码集成 · 二项式期权定价模型 · Black-Scholes期权定价模型 · Monte-Carlo期权定价模型 · 并行Mersenne Twister（随机数生成） · 并行直方图 · 图像去噪 · Sobel边缘检测滤波器 · MathWorks MATLAB® 新的基于1.1版CUDA的SDK 范例现在也已经发布了。 技术功能 ·在GPU（图形处理器）上提供标准C编程语言 · 为在支持CUDA的NVIDIA GPU（图形处理器）上进行并行计算而提供了统一的软硬件解决方案 · CUDA兼容的GPU（图形处理器）包括很多：从低功耗的笔记本上用的GPU到高性能的，多GPU的系统。 · 支持CUDA的GPU（图形处理器）支持并行数据缓存和线程执行管理器 · 标准FFT（快速傅立叶变换）和BLAS（基本线性代数子程序）数值程序库 · 针对计算的专用CUDA驱动 · 经过优化的，从中央处理器（CPU）到支持CUDA的GPU（图形处理器）的直接上传、下载通道 · CUDA驱动可与OpenGL和DirectX图形驱动程序实现互操作 · 支持Linux 32位/64位以及Windows XP 32位/64位 操作系统 · 为了研究以及开发语言的目的，CUDA提供对驱动程序的直接访问，以及汇编语言级的访问 NVIDIA进军高性能计算领域，推出了Tesla&CUDA高性能计算系列解决方案，CUDA技术，一种基于NVIDIA图形处理器（GPU）上全新的并行计算体系架构，让科学家、工程师和其他专业技术人员能够解决以前无法解决的问题，作为一个专用高性能GPU计算解决方案，NVIDIA把超级计算能够带给任何工作站或服务器，以及标准、基于CPU的服务器集群 CUDA是用于GPU计算的开发环境，它是一个全新的软硬件架构，可以将GPU视为一个并行数据计算的设备，对所进行的计算进行分配和管理。在CUDA的架构中，这些计算不再像过去所谓的GPGPU架构那样必须将计算映射到图形API（OpenGL和Direct 3D）中，因此对于开发者来说，CUDA的开发门槛大大降低了。CUDA的GPU编程语言基于标准的C语言，因此任何有C语言基础的用户都很容易地开发CUDA的应用程序。 由于GPU的特点是处理密集型数据和并行数据计算，因此CUDA非常适合需要大规模并行计算的领域。目前CUDA除了可以用C语言开发，也已经提供FORTRAN的应用接口，未来可以预计CUDA会支持C++、Java、Python等各类语言。可广泛的应用在图形动画、科学计算、地质、生物、物理模拟等领域。 2008年NVIDIA推出CUDA SDK2.0版本，大幅提升了CUDA的使用范围。使得CUDA技术愈发成熟 目前，支持CUDA的GPU销量已逾1亿，数以千计的软件开发人员正在使用免费的CUDA软件开发工具来解决各种专业以及家用应用程序中的问题。这些应用程序从视频与音频处理和物理效果模拟到石油天然气勘探、产品设计、医学成像以及科学研究，涵盖了各个领域。 目前市面上已经部署了超过一亿颗支持CUDA的GPU，数以千计的软件开发人员正在使用免费的CUDA软件工具来为各种应用程序加速。 CUDA 的核心有三个重要抽象概念： 线程组层次结构、共享存储器、屏蔽同步（ barrier synchronization），可轻松将其作为C 语言的最小扩展级公开给程序员。 CUDA 软件堆栈由几层组成，一个硬件驱动程序，一个应用程序编程接口(API) 和它的Runtime， 还有二个高级的通用数学库，CUFFT 和CUBLAS。硬件被设计成支持轻 量级的驱动和Runtime 层面，因而提高性能。
Ⅱ 关于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硬件基础知识
GPU channel 是GPU与CPU之间的桥接接口，通过CPU向GPU发送GPU指令的唯一通道，GPU channel包含了两类用于存储GPU指令的buffer：
当GPU指令被写入到GPU command buffer时，系统还会向Ring buffer中写入与此指令所对应的packet，packet包含了此指令在GPU command buffer中的偏移位置与长度数据。
在执行指令的时候，GPU不是直接从GPU command buffer中读取数据，而是先经过Ring buffer读取出当前待处理指令的相关信息，再据此读取GPU command（这也是为什么Ring buffer被称之为indirect buffer的原因）。
现代GPU为了加强数据的并行化处理的强度，使用的是SIMT（Single Instruction Multi Thread，SIMD的更高级版本）体系结构，shader program运行的最小单位是thread，多个运行相同shader的threads会被打包到一个组（此滚thread group），这个thread group，在NVIDIA被称之为warp，在AMD中被称之为wavefront。
上面这张图是从标题链接给出的Turing白皮书中截取的GPU架构图，其中包含如下几个关键缩写：
GPU中用于存储数据的结构有多种[4]，分别是：
每种存储结构都有着各自的优缺点此山，因此适用于不同的应用场景，从访问速度来看，这些存储结构按照从高到低排序依次是：
RMEM > SMEM > CMEM > TMEM > LMEM > GMEM
RMEM与SMEM是直接集成在GPU芯片上的，而剩下的几种存储结构则是在GPU之外的芯片上的，此外，LMEM/CMEM/TMEM都有着各自的缓存机制，即在访问数据的时候都会首先从缓存中进行查找判断，再决定是否需要从更低一级速度的存储结构中进行读取。
存储在LMEM中的数据可见性与RMEM一样，都是只对负责对其进行读写的线程可见。LMEM实际上森扒中并不是一块物理存储空间，而是对GMEM的一个抽象，因此其访问速度与对GMEM的访问速度是相同的。LMEM中的数据对于一个线程而言是Local的（即只从属于当前thread的空间，对其他线程不可见），通常用于存储一些automatic变量（automatic变量指的是一些大尺寸的数据结构或者数组，因为寄存器不够，因此会塞入LMEM中），编译器在寄存器不足的时候，就会从GMEM中开辟一块空间用作LMEM。
虽然LMEM是从GMEM中分割出来的，但是其使用方式与GMEM还是有着一些区别：
如上图所示（从图中可以看出，L1是位于GPU芯片上的，其中SMEM就存储在其中，RMEM也是在芯片上，而L2及以后的存储空间则都是芯片之外的存储空间了），在对LMEM进行数据读写的时候，会经历这样一个缓存层级流动：L1->L2->LMEM。因为LMEM实际上是临时开辟的一块空间，因此里面的数据实际上是GPU先写入的，在此之前发生的读取就相当于读到了一堆乱码。
那么什么情况下会使用到LMEM呢？一般来说有如下两种情形：
因为LMEM相对于寄存器访问速度的低效性，因此其对性能的影响主要有如下两个方面：
但是因为以下的两点原因，LMEM也不一定会造成性能下降：
对于一些LMEM可能会存在瓶颈的情况，参考文献[3]中给出了一些分析的方法可供排查，同时还给出了对应的优化策略以及实战案例，有兴趣的同学可以前往参考。
存储在RMEM中的数据只对负责对此寄存器进行读写的线程可见，且其生命周期与此线程的生命周期一致。
通常情况下，对寄存器的访问不需要消耗时钟周期，但是在一些特殊情况（比如先进行了一个写操作，之后再进行读取，或者在bank访问冲突的情况下），会有例外。先写后读的延迟大概是24个时钟周期，对于更新的GPU（每个SM包含32个cores的情况），可能需要花费768个线程来隐藏这个延迟。
当需求的寄存器数目超出硬件所能支持的限额时，就会导致寄存器压力，在这种情况下，数据就会使用LMEM来进行存储（所谓的spilled over，即溢出），如下图所示[3]：
存储在SMEM中的数据对处于同一个block所有的线程都是可见的（不负shared之名），因此通常用于多个线程之间的数据互换，为了避免多个线程同时访问相同的数据导致的阻塞，NVIDIA将SMEM划分成32个逻辑单元，每个单元叫做一个bank，在内存中连续的数据，在banks的分布也是连续的：
SMEM是位于L1 Cache中的，其尺寸通常为16/32/48KB，剩余部分用作L1 Cache，对于开普勒架构而言，每个bank每个时钟的带宽是64bits/clock，较早的Fermi架构时钟不太一样，但是带宽差不多是这个数值的一半。
由于一个warp中有32个线程，因此总共需要32个SMEM banks。由于每个bank在每个时钟周期中只支持一次访问请求，因此多个同时访问的请求就会导致bank conflict，这个的处理过程后面会讲。
默认每个bank占用32bits（4bytes），开普勒架构之后，可以通过指令（cudaDeviceSetSharedMemConfig()）将每个bank扩充到64bits，以应对双精度数据的访问冲突。
存储在Global Memory中的数据对于当前进程中的所有线程都是可见的，其生命周期与进程一致。
CMEM通常用于存储一些常量数据，当同一个warp中的所有线程都需要使用同一个参数时，可以将数据放在CMEM中，这种做法比将数据放在GMEM中更节省带宽。
TMEM也是一种常量存储结构，当一个warp中的线程所需要读取的数据都是存储位置上相邻的时候，使用这种结构比GMEM具有更优的性能表现（也是出于带宽的原因）
[1]. A HISTORY OF NVIDIA STREAM MULTIPROCESSOR
[2]. Life of a triangle - NVIDIA's logical pipeline
[3]. Local Memory and Register Spilling
[4]. GPU Memory Types – Performance Comparison
Ⅳ NVIDIA显卡支持CUDA，什么是CUDA
关于CUDA：
CUDA（Compute Unified Device Architecture）是一个新的基础架构，这个架构可以使用GPU来解决商业、工业以及科学方面的复杂计算问题。它是一个完整的GPGPU解决方案，提供了硬件的直接访问接口，而不必像传统方式一样必须依赖图形API接口来实现GPU的访问。在架构上采用了一种全新的计算体系结构来使用GPU提供的硬件资源，从而给大规模的数据计算应用提供了一种比CPU更加强大的计算能力。CUDA采用C语言作为编程语言提供大量的高性能计算指令开发能力，使开发者能够在GPU的强大计算能力的基础上建立起一种效率更高的密集数据计算解决方案。
关于NVIDIA CUDA技术
NVIDIA CUDA技术是当今世界上唯一针对NVIDIA GPU（图形处理器）的C语言环境，为支持CUDA技术的NVIDIA GPU（图形处理器）带来无穷的图形计算处理性能。凭借NVIDIA CUDA技术，开发人员能够利用NVIDIA GPU（图形处理器）攻克极其复杂的密集型计算难题，应用到诸如石油与天然气的开发，金融风险管理，产品设计，媒体图像以及科学研究等领域。
CUDA™ 工具包是一种针对支持CUDA功能的GPU（图形处理器）的C语言开发环境。CUDA开发环境包括:
nvcc C语言编译器
适用于GPU（图形处理器）的CUDA FFT和BLAS库
分析器
适用于GPU（图形处理器）的gdb调试器（在2008年3月推出alpha版）
CUDA运行时（CUDA runtime）驱动程序（目前在标准的NVIDIA GPU驱动中也提供）
CUDA编程手册
CUDA开发者软件开发包（SDK）提供了一些范例（附有源代码），以帮助使用者开始CUDA编程。这些范例包括:
并行双调排序
矩阵乘法
矩阵转置
利用计时器进行性能评价
并行大数组的前缀和（扫描）
图像卷积
使用Haar小波的一维DWT
OpenGL和Direct3D图形互操作示例
CUDA BLAS和FFT库的使用示例
CPU-GPU C—和C++—代码集成
二项式期权定价模型
Black-Scholes期权定价模型
Monte-Carlo期权定价模型
并行Mersenne Twister（随机数生成）
并行直方图
图像去噪
Sobel边缘检测滤波器
MathWorks MATLAB® 插件 (点击这里下载)
新的基于1.1版CUDA的SDK 范例现在也已经发布了。要查看完整的列表、下载代码，请点击此处。
技术功能
在GPU（图形处理器）上提供标准C编程语言
为在支持CUDA的NVIDIA GPU（图形处理器）上进行并行计算而提供了统一的软硬件解决方案
CUDA兼容的GPU（图形处理器）包括很多：从低功耗的笔记本上用的GPU到高性能的，多GPU的系统。
支持CUDA的GPU（图形处理器）支持并行数据缓存和线程执行管理器
标准FFT（快速傅立叶变换）和BLAS（基本线性代数子程序）数值程序库
针对计算的专用CUDA驱动
经过优化的，从中央处理器（CPU）到支持CUDA的GPU（图形处理器）的直接上传、下载通道
CUDA驱动可与OpenGL和DirectX图形驱动程序实现互操作
支持Linux 32位/64位以及Windows XP 32位/64位 操作系统
为了研究以及开发语言的目的，CUDA提供对驱动程序的直接访问，以及汇编语言级的访问。
Ⅳ 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 （高级一点）
谢谢，望采纳