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 （高級一點）
謝謝，望採納