顯卡編譯器

Ⅰ 我的顯卡是GTX970m支持opencl不支持opengl怎麼處理

讓不支持OpenCL的顯卡支持OpenCL有點難度，這要求顯卡本身開放一定程度的對底層硬體的支持。
不過也不是完全不可能。
比如目前有一個庫叫做POCL，pocl - Portable Computing Language。想法是將OpenCL程序編譯為系統支持的已有的並行計算語言，然後在相應的設備上執行。目前POCL主要在CPU上運行，它可以將OpenCL程序轉換為類似PThread的多線程並行程序，然後在不支持OpenCL的設備上運行。其原理就有點像軟體模擬了一個OpenCL的runtime。
藉助類似的想法，我們就可以嘗試創建一個中間層runtime，來進行代碼的運行時編譯和轉換。將系統不支持的OpenCL代碼轉換到系統支持的某種API上去。
試想， 我們可以在一個NVIDIA顯卡上，編寫相應的編譯器或runtime，將OpenCL程序轉換為CUDA的二進制代碼， 然後就可以在N卡上執行了。（當然，N卡本身支持OpenCL1.1， 最新的beta驅動支持OpenCL 1.2， 我們這里只是討論一種可行性）。
更進一步， 我們甚至可以將OpenCL轉換為OpenGL的shader kernel，然後在不支持OpenCL的顯卡上運行。其實早年的GPGPU的研究，大部分都是藉助pixel shader來進行並行計算的。後來才出現了針對通用並行計算的API。 對於較老的GPU，我們轉換為Pixel shader。 對於新的GPU，我們可以藉助Compute shader。
當然了，設計這樣一個軟體模擬的解決方案，無疑是巨大的工作量，難度也不低，需要對底層有很好的理解。同時，由於系統本身支持的API的一些限制，我們不可能支持所有的OpenCL的特性，必然會對性能有所影響。
但是單就可能性來說， 題主的問題的答案應當是：可行。

Ⅱ 請問directx和opengl是對顯卡的編程嗎那shader又是什麼三者有什麼關系呢

DirectX（Direct
eXtension，簡稱DX）是由微軟公司創建的多媒體編程介面。由C++編程語言實現，遵循COM。被廣泛使用於Microsoft Windows、Microsoft XBOX、Microsoft
XBOX 360和Microsoft XBOX ONE電子游戲開發，並且只能支持這些平台。最新版本為DirectX 12，創建在最新的Windows
8.1上。

OpenGL（全寫Open
Graphics Library）是個定義了一個跨編程語言、跨平台的編程介面的規格，它用於三維圖象（二維的亦可）。OpenGL是一個開放的三維圖形軟體包，它獨立於窗口系統和操作系統，OpenGL可以與Visual C++緊密介面，便於實現機械手的有關計算和圖形演算法，可保證演算法的正確性和可靠性目前，2.0版本開始加入了很多類似於DirectX中可編程單元的設計.

Shader Model（在3D圖形領域常被簡稱SM）就是「優化渲染引擎模式」。Shader（著色器）是DirectX中一段能夠針對3D對象進行操作、並被GPU所執行的程序。早在微軟發布DirectX 8時，Shader
Model的概念就出現在其中了，並根據操作對象的不同被分為對頂點進行各種操作的Vertex Shader（頂點渲染引擎）和對像素進行各種操作的Pixel
Shader（像素渲染引擎）。

到了Shader Model 4.0,在VS和PS之間引入了一個新的可編程圖形層--幾何渲染器(Geometry
Shader)。原來的Vertex Shader和Pixel Shader只是對逐個頂點或像素進行處理，而新的Geometry
Shader可以批量進行幾何處理。然而性能受到詬病，為了兼顧性能，在DirectX11(SM
5.0)開始引入了Tessellation來取代GS的部分功能。

說白點，三者的關系是，Shader Model是DirectX其中一個技術協議程序，而DirectX和OpenGL則是多媒體編程介面的競爭對手。

Ⅲ AMD顯卡目前最新的顯卡BIOS編譯軟體是哪個

目前最新的hoenix.BIOS.Editor

如果是你手頭有bios的源代碼，那麼用微軟的MSVC編譯器就可以。
如果你僅僅是想把BIOS文件燒錄到主板上，那麼一般的編程器只要支持BIOS的flash rom的都可以，比如SF100.

Ⅳ 我的電腦顯卡驅動用32位好還是64位好

這要看系統是32位的還是64位的。32位的系統用32位的驅動程序，同理，64位的系統必須用64位的驅動程序。不能混用，否則會導致響應設備不能正常運行，或者系統癱瘓。
不能確定系統位數，用驅動精靈即可自動安裝顯卡驅動程序了。
還是不行，直接換個可以自動安裝機器硬體驅動程序的系統盤重裝系統就行了，這樣就可以全程自動、順利解決 系統中顯卡驅動程序自動安裝 的問題了。用u盤或者硬碟這些都是可以的，且安裝速度非常快。具體安裝方法如下：
1、U盤安裝：用ultraiso軟體，打開下載好的系統安裝盤文件（ISO文件），執行「寫入映像文件」把U盤插到電腦上，點擊「確定」，等待程序執行完畢後，這樣就做好了啟動及安裝系統用的u盤，用這個做好的系統u盤引導啟動機器後，即可順利重裝系統了；
2、硬碟安裝：前提是，需要有一個可以正常運行的Windows系統，提取下載的ISO文件中的「*.GHO」和「安裝系統.EXE」到電腦的非系統分區，然後運行「安裝系統.EXE」，直接回車確認還原操作，再次確認執行自動安裝操作(執行前注意備份C盤重要資料)。

Ⅳ 我買了一塊GTX 1660TI顯卡，顯卡驅動10.1，請問能使用caffe、tensorflow訓練模型嗎

老黃去年下禁令禁止游戲顯卡跑深度學習。解決方法如下：（tensorflow）
方法一：改變系統變數使得僅目標顯卡可見：

1 export CUDA_VISIBLE_DEVICES=0 #這里是要使用的GPU編號，正常的話是從0開始
方法二：使用tensorflow api添加設備環境
1 with tensorflow.device('/gpu:0'):
2 main tensorflow program

注意：
如果使用方法二，需要修改一下Session配置，否則在默認配置下，所有可見顯卡的顯存都會被佔用（暫時還沒找到原因）。
修改代碼：
1 config=tensorflow.ConfigProto()
2 config.gpu_options.allow_growth=True
3 ...
4 sess=tensorflow.Session(config=config,...)

Ⅵ nvidia/cuda 公開源中的devel和runtime有什麼區別

從很多方面來看，CUDA和OpenCL的關系都和DirectX與OpenGL的關系很相像。如同DirectX和OpenGL一樣，CUDA和OpenCL中，前者是配備完整工具包、針對單一供應商(NVIDIA)的成熟的開發平台，後者是一個開放的標准。
雖然兩者抱著相同的目標：通用並行計算。但是CUDA僅僅能夠在NVIDIA的GPU硬體上運行，而OpenCL的目標是面向任何一種Massively Parallel Processor，期望能夠對不同種類的硬體給出一個相同的編程模型。由於這一根本區別，二者在很多方面都存在不同：

1）開發者友好程度。CUDA在這方面顯然受更多開發者青睞。原因在於其統一的開發套件(CUDA Toolkit, NVIDIA GPU Computing SDK以及NSight等等)、非常豐富的庫(cuFFT, cuBLAS, cuSPARSE, cuRAND, NPP, Thrust)以及NVCC(NVIDIA的CUDA編譯器)所具備的PTX(一種SSA中間表示，為不同的NVIDIA GPU設備提供一套統一的靜態ISA)代碼生成、離線編譯等更成熟的編譯器特性。相比之下，使用OpenCL進行開發，只有AMD對OpenCL的驅動相對成熟。

2）跨平台性和通用性。這一點上OpenCL佔有很大優勢（這也是很多National Laboratory使用OpenCL進行科學計算的最主要原因）。OpenCL支持包括ATI,NVIDIA,Intel,ARM在內的多類處理器，並能支持運行在CPU的並行代碼，同時還獨有Task-Parallel Execution Mode，能夠更好的支持Heterogeneous Computing。這一點是僅僅支持數據級並行並僅能在NVIDIA眾核處理器上運行的CUDA無法做到的。

3）市場佔有率。作為一個開放標准，缺少背後公司的推動，OpenCL顯然沒有占據通用並行計算的主流市場。NVIDIA則憑借CUDA在科學計算、生物、金融等領域的推廣牢牢把握著主流市場。再次想到OpenGL和DirectX的對比，不難發現公司推廣的高效和非盈利機構/標准委員會的低效(抑或謹慎，想想C++0x)。

很多開發者都認為，由於目前獨立顯卡市場的萎縮、新一代處理器架構(AMD的Graphics Core Next (GCN)、Intel的Sandy Bridge以及Ivy Bridge)以及新的SIMD編程模型(Intel的ISPC等)的出現，未來的通用並行計算市場會有很多不確定因素，CUDA和OpenCL都不是終點，我期待未來會有更好的並行編程模型的出現(當然也包括CUDA和OpenCL，如果它們能夠持續發展下去)。

Ⅶ 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提供對驅動程序的直接訪問，以及匯編語言級的訪問。

Ⅷ NVIDIA顯卡的的CUDA核心是什麼

CUDA核心，理論上流處理器縮寫是SP。但NVIDIA自己稱呼他們的SP是CUDA Core。

CUDA Core只是N卡流處理器而已,只是一個流處理器名詞。

CUDA是一個統一計算架構，屬於軟體+硬體架構統稱。他不是一個軟體也不是一個純硬體。而是軟硬結合的計算體系。

你可以理解為CUDA是一個基於NVIDIA GPU平台上面NV自己定製的特殊計算體系。是NV自己發明的運算演算法，在NV平台和軟體支持上面才能發揮最高效率。CUDA在NVIDIA定義是一種類C語言，本身兼容C語言。CUDA雖然是一種獨立語言提供開發學習，但CUDA本身和C差距不算非常巨大，很多有經驗的開發者很快能學會。

CUDA在全球屬於NVIDIA私人生態區，他的勢力並不比IOS小。甚至在高端計算領域和圖形領域。CUDA算的上是權威標准。 Quadro和Tesla這2個統治世界的著名計算平台就是靠著CUDA生態區才能提供客戶一體化服務，否則如果大家都像AMD那樣只賣個浮點看起來很高的物理節點，那麼老黃根本不敢自封視覺運算公司，那不是普通半導體公司搞的授權么？

CUDA是一個計算結構，是一個理念。是一個軟硬平台，是一個NV提供綜合性服務的東西。他不是一個顯卡授權，也不是一個集群。也不是一個驅動。

Ⅸ CUDA和OpenCL有什麼區別

從很多方面來看，CUDA和OpenCL的關系都和DirectX與OpenGL的關系很相像。如同DirectX和OpenGL一樣，CUDA和OpenCL中，前者是配備完整工具包、針對單一供應商(NVIDIA)的成熟的開發平台，後者是一個開放的標准。

雖然兩者抱著相同的目標：通用並行計算。但是CUDA僅僅能夠在NVIDIA的GPU硬體上運行，而OpenCL的目標是面向任何一種Massively
Parallel Processor，期望能夠對不同種類的硬體給出一個相同的編程模型。由於這一根本區別，二者在很多方面都存在不同：

1)開發者友好程度。CUDA在這方面顯然受更多開發者青睞。原因在於其統一的開發套件(CUDA Toolkit, NVIDIA GPU
Computing SDK以及NSight等等)、非常豐富的庫(cuFFT, cuBLAS, cuSPARSE, cuRAND, NPP,
Thrust)以及NVCC(NVIDIA的CUDA編譯器)所具備的PTX(一種SSA中間表示，為不同的NVIDIA
GPU設備提供一套統一的靜態ISA)代碼生成、離線編譯等更成熟的編譯器特性。相比之下，使用OpenCL進行開發，只有AMD對OpenCL的驅動相對成熟。

2)跨平台性和通用性。這一點上OpenCL佔有很大優勢(這也是很多National
Laboratory使用OpenCL進行科學計算的最主要原因)。OpenCL支持包括ATI,NVIDIA,Intel,ARM在內的多類處理器，並能支持運行在CPU的並行代碼，同時還獨有Task-Parallel
Execution Mode，能夠更好的支持Heterogeneous
Computing。這一點是僅僅支持數據級並行並僅能在NVIDIA眾核處理器上運行的CUDA無法做到的。

3)市場佔有率。作為一個開放標准，缺少背後公司的推動，OpenCL顯然沒有占據通用並行計算的主流市場。NVIDIA則憑借CUDA在科學計算、生物、金融等領域的推廣牢牢把握著主流市場。再次想到OpenGL和DirectX的對比，不難發現公司推廣的高效和非盈利機構/標准委員會的低效(抑或謹慎，想想C++0x)。

很多開發者都認為，由於目前獨立顯卡市場的萎縮、新一代處理器架構(AMD的Graphics Core Next (GCN)、Intel的Sandy
Bridge以及Ivy
Bridge)以及新的SIMD編程模型(Intel的ISPC等)的出現，未來的通用並行計算市場會有很多不確定因素，CUDA和OpenCL都不是終點，我期待未來會有更好的並行編程模型的出現(當然也包括CUDA和OpenCL，如果它們能夠持續發展下去)。