OpenCV、OpenCL、OpenGL、OpenPCL
??????? 對于幾個開源庫的總結(jié)，作為標(biāo)記，以前看過，現(xiàn)在開始重視起來！更詳細(xì)資料請移步 開源中國社區(qū)！
涉及：OpenCV，OpenCL，OpenGL，OpenPCL
截止到目前：
??????? OpenGL的最新版本為4.4，NVIDIA顯卡系列已提供了基于4.4版本的驅(qū)動；
??? ? ? OpenGL ES的最新版本為3.0，高通處理器圖形芯片已經(jīng)可以支持；
??????? OpenCV的最新發(fā)行版本為2.4.6,? 另外3,0版本在14年2月發(fā)布，有興趣可以查看OpenCV官方里程碑圖；
?? ???? OpenPCL的最新發(fā)行版為1.7.1的源代碼，不過編譯成功的人是少數(shù)，總之我是一個失敗的案例！
??????? OpenCL的最新版本為2.0，OpenCL全稱Open Computing Language，是第一個面向異構(gòu)系統(tǒng)通用目的并行編程的開放式、免費(fèi)標(biāo)準(zhǔn)，也是一個統(tǒng)一的編程環(huán)境，便于軟件開發(fā)人員為高性能計算服務(wù)器、桌面計算系統(tǒng)、手持設(shè)備編寫高效輕便的代碼，而且廣泛適用于多核心處理器(CPU)、圖形處理器(GPU)、Cell類型架構(gòu)以及數(shù)字信號處理器(DSP)等其他并行處理器，在游戲、娛樂、科研、醫(yī)療等各種領(lǐng)域都有廣闊的發(fā)展前景。
一、OpenCL框架組成 （轉(zhuǎn)自于華章IT官方博客）
原文鏈接：http://blog.csdn.net/hzbooks/article/details/8206571
下面是Copy：
OpenCL框架組成
本文主要討論OpenCL框架，其組成可劃分為以下三個部分：
- OpenCL平臺API：平臺API定義了宿主機(jī)程序發(fā)現(xiàn)OpenCL設(shè)備所用的函數(shù)以及這些函數(shù)的功能，另外還定義了為OpenCL應(yīng)用創(chuàng)建上下文的函數(shù)。
- OpenCL運(yùn)行時API：這個API管理上下文來創(chuàng)建命令隊(duì)列以及運(yùn)行時發(fā)生的其他操作。例如，將命令提交到命令隊(duì)列的函數(shù)就來自O(shè)penCL運(yùn)行時API。
- OpenCL編程語言：這是用來編寫內(nèi)核代碼的編程語言。它基于ISO C99標(biāo)準(zhǔn)的一個擴(kuò)展子集，因此通常稱為OpenCL C編程語言。
在后面的小節(jié)中，我們將為以上各個部分提供一個高層的概述。詳細(xì)內(nèi)容留待本書后面介紹，不過使用OpenCL時先有一個高層認(rèn)識會很有幫助。
1. 平臺API
平臺（platform）一詞在OpenCL中有非常特定的含義。它表示宿主機(jī)、OpenCL設(shè)備和OpenCL框架的組合。一個異構(gòu)計算機(jī)上可以同時存在多個OpenCL平臺。例如，CPU開發(fā)商和GPU開發(fā)商可以在一個系統(tǒng)上分別定義自己的OpenCL框架。程序員需要一種方法查詢系統(tǒng)中可用的OpenCL框架。他們需要查找哪些OpenCL設(shè)備可用，這些OpenCL設(shè)備有什么特性。另外，他們還需要控制這些框架和設(shè)備的哪個子集構(gòu)成給定OpenCL應(yīng)用中使用的平臺。
這些功能由OpenCL平臺API中的函數(shù)解決。在后面的章節(jié)中將會看到，我們重點(diǎn)討論OpenCL程序員為宿主機(jī)程序編寫代碼時，每個OpenCL應(yīng)用程序都以類似的方式打開，調(diào)用平臺API的函數(shù)為OpenCL計算定義上下文。
2. 運(yùn)行時API
平臺API中的函數(shù)為OpenCL應(yīng)用定義上下文。運(yùn)行時API則強(qiáng)調(diào)使用這個上下文滿足應(yīng)用需求的函數(shù)。這是一個龐大而且確實(shí)相當(dāng)復(fù)雜的函數(shù)集。
運(yùn)行時API的第一個任務(wù)是建立命令隊(duì)列。可以將命令隊(duì)列關(guān)聯(lián)到一個設(shè)備，不過一個上下文中可以同時有多個活動的命令隊(duì)列。
有了命令隊(duì)列，就可以使用運(yùn)行時API來定義內(nèi)存對象和管理內(nèi)存對象所需要的所有其他對象（如對于圖像對象還需要采樣器對象）。管理內(nèi)存對象是一個很重要的任務(wù)。為了支持垃圾回收，OpenCL會跟蹤多少個內(nèi)核實(shí)例使用這些對象（也就是說，持有一個內(nèi)存對象），以及內(nèi)核何時用完一個內(nèi)存對象（即釋放一個內(nèi)存對象）。
運(yùn)行時API管理的另一個任務(wù)是創(chuàng)建構(gòu)建動態(tài)庫所用的程序?qū)ο?#xff0c;內(nèi)核就由這些動態(tài)庫定義。程序?qū)ο蟆⒕幾g程序?qū)ο蟮木幾g器以及內(nèi)核定義都在運(yùn)行時層處理。
最后，與命令隊(duì)列交互的命令都由運(yùn)行時層的函數(shù)發(fā)出。管理數(shù)據(jù)共享和對內(nèi)核執(zhí)行施加約束的同步點(diǎn)也由運(yùn)行時API處理。
可以看到，運(yùn)行時API函數(shù)完成了宿主機(jī)程序的大部分具體工作。要想一次掌握運(yùn)行時API，從第一個函數(shù)開始學(xué)完所有函數(shù)，這是很有壓力的。我們發(fā)現(xiàn)，更好的做法是使用一種實(shí)用的方法。掌握真正要使用的函數(shù)。過一段時間，你就會把它們?nèi)娓采w到，并完全掌握，不過要根據(jù)OpenCL應(yīng)用的具體需要來學(xué)習(xí)這些函數(shù)。
3. 內(nèi)核編程語言
宿主機(jī)程序非常重要，不過完成OpenCL中實(shí)際工作的是內(nèi)核。有些OpenCL實(shí)現(xiàn)允許你與非OpenCL編寫的原生內(nèi)核交互，不過，大多數(shù)情況下都需要編寫內(nèi)核來完成應(yīng)用中的特定工作。
OpenCL中的內(nèi)核編程語言稱為OpenCL C編程語言，因?yàn)槲覀兿Ｍ^一段時間后可以定義符合規(guī)范的其他語言。它由ISO C99語言派生而來。
在OpenCL中，要對支持可移植性特別當(dāng)心。這要求我們標(biāo)準(zhǔn)化不同類的OpenCL設(shè)備之間的最小公共子集。由于C99中有些特性只有CPU能夠支持，所以在定義OpenCL C編程語言時，我們?nèi)サ袅薈99的一些語言特性。刪除的主要語言特性包括：
- 遞歸函數(shù)。
- 函數(shù)指針。
- 位域。
另外，我們不支持完整的標(biāo)準(zhǔn)庫集合。OpenCL編程語言中不支持的標(biāo)準(zhǔn)頭文件很多，不過程序員最有可能遺漏的是stdio.h和stdlib.h。再次說明，一旦不再將通用處理器作為OpenCL設(shè)備，這些庫將很難獲得支持。
由于需要保持OpenCL核心抽象的真實(shí)性，所以會帶來另外一些限制。例如，OpenCL定義了一組內(nèi)存地址空間。聯(lián)合（union）或結(jié)構(gòu)（structure）不能混合類型。另外，OpenCL還定義了一些不透明的類型，例如，支持圖像的內(nèi)存對象。OpenCL C編程語言除了允許將這些類型作為參數(shù)傳遞給函數(shù)外，不允許對它們做任何其他處理。
我們將OpenCL C編程語言限制為只滿足用于OpenCL的關(guān)鍵OpenCL設(shè)備的需求。出于同樣的原因，促使我們擴(kuò)展語言以及以下方面：
- 矢量類型和這些類型實(shí)例上的操作。
- 地址空間限定符，支持OpenCL對多個地址空間的控制。
- 一組豐富的內(nèi)置函數(shù)，支持OpenCL應(yīng)用中通常需要的功能。
- 全局和局部內(nèi)存中處理無符號整數(shù)和單精度標(biāo)量變量的原子函數(shù)。
大多數(shù)編程語言忽略浮點(diǎn)算術(shù)系統(tǒng)的特定細(xì)節(jié)。它們只是從硬件導(dǎo)入算術(shù)系統(tǒng)，從而完全避開這個問題。由于所有主流CPU都支持IEEE 754和IEEE 854標(biāo)準(zhǔn)，所以這個策略是可行的。實(shí)際上，通過集中研究這些浮點(diǎn)標(biāo)準(zhǔn)，硬件開發(fā)商在為語言開發(fā)商解決浮點(diǎn)定義的有關(guān)問題。
不過，在異構(gòu)世界中，如果脫離CPU，那么對浮點(diǎn)算術(shù)運(yùn)算的支持會有更多的選擇。過去通過與硬件開發(fā)商的緊密合作，我們希望大力推動他們完善對IEEE浮點(diǎn)標(biāo)準(zhǔn)的支持。與此同時，我們不希望對這些開發(fā)商過于苛刻，所以賦予他們一定的靈活性可以避開IEEE標(biāo)準(zhǔn)中一些不常使用但實(shí)現(xiàn)很困難的特性。后面會詳細(xì)討論有關(guān)細(xì)節(jié)，不過從高層可以總結(jié)為OpenCL需要以下特性：
- 對IEEE 754格式的全面支持。雙精度是可選的，不過如果提供雙精度，也必須符合IEEE 754格式。
- 支持默認(rèn)的IEEE 754舍入模式，即“舍入為最近整數(shù)”。其他舍入模式盡管值得推薦（因?yàn)閿?shù)值分析學(xué)者需要這些模式），但它們是可選的。
- 盡管IEEE規(guī)范要求動態(tài)改變舍入模式，但OpenCL中的舍入模式是靜態(tài)設(shè)置的。
- 必須支持特殊值INF（無窮大）和NaN（非數(shù)字），不過不要求提示NaN（通常反映并發(fā)系統(tǒng)中的問題）。
- 非規(guī)格化數(shù)（小于1的數(shù)乘以所支持的最大負(fù)指數(shù)）可以化簡為0。如果你還不了解為什么這很重要，不用擔(dān)心，很多人都與你一樣。這也是數(shù)值分析學(xué)者很依賴但很少有程序員了解的另一個特性。
關(guān)于浮點(diǎn)數(shù)異常還有很多其他規(guī)則，不過它們對大多數(shù)人來說都過于復(fù)雜、過于深奧，沒有必要在這里多做說明。關(guān)鍵是要了解我們已努力滿足IEEE 754的大多數(shù)內(nèi)容，同時省略了很少使用而且（在配有矢量單元的異構(gòu)平臺上）難以支持的一些特性。
OpenCL規(guī)范并不僅限于IEEE標(biāo)準(zhǔn)。在OpenCL規(guī)范中，還有一些表格詳盡地定義了數(shù)學(xué)函數(shù)中允許的相對誤差。要想了解所有這些錯誤確實(shí)難度很大，不過對于編寫詳細(xì)數(shù)值代碼的程序員來說，定義這些錯誤是至關(guān)重要的。
綜合以上浮點(diǎn)數(shù)需求、限制和擴(kuò)展，就得到了一個非常適合當(dāng)前異構(gòu)平臺的編程語言，隨著這些平臺中使用的處理器繼續(xù)發(fā)展，并變得更為通用，OpenCL C編程語言也會隨之發(fā)展。
4. 小結(jié)
我們已經(jīng)介紹了核心OpenCL框架的基本組成。要單獨(dú)地了解這些組成部分（我們介紹時就主要采用了這種方式）很重要。為了把這些單獨(dú)的部分匯集起來，形成OpenCL的一個全景圖，下面對應(yīng)用在OpenCL框架中的基本工作流做個小結(jié)，如圖1-9所示。
圖1-9 這個模塊圖總結(jié)了OpenCL的組成以及一個OpenCL應(yīng)用執(zhí)行期間在宿主機(jī)上發(fā)生的動作
首先是一個定義上下文的宿主機(jī)程序。圖1-9中的上下文包含兩個OpenCL設(shè)備、一個CPU和一個GPU。接下來定義了命令隊(duì)列。這里有兩個隊(duì)列，一個是面向GPU的有序命令隊(duì)列，另一個是面向CPU的亂序命令隊(duì)列。然后宿主機(jī)程序定義一個程序?qū)ο?#xff0c;這個程序?qū)ο缶幾g后將為兩個OpenCL設(shè)備（CPU和GPU）生成內(nèi)核。接下來宿主機(jī)程序定義程序所需的內(nèi)存對象，并把它們映射到內(nèi)核的參數(shù)。最后，宿主機(jī)程序?qū)⒚罘湃朊铌?duì)列來執(zhí)行這些內(nèi)核。
-----------------------------
本文節(jié)選自《OpenCL編程指南》
原書名：OpenCL Programming Guide
作者：Aaftab Munshi / Benedict R. Gaster / Timothy G. Mattson / James Fung / Dan Ginsburg
本書由五位OpenCL核心設(shè)計人員攜手打造，不僅詳細(xì)而完整地解讀了枯燥的OpenCL規(guī)范，而且通過一些重要的案例展示了如何利用OpenCL實(shí)現(xiàn)大量并行算法、編寫復(fù)雜的并行程序、對OpenCL進(jìn)行性能優(yōu)化，以及探查硬件和針對硬件進(jìn)行調(diào)整，是系統(tǒng)學(xué)習(xí)OpenCL的經(jīng)典參考書。
閱讀本書PDF樣章，請訪問http://download.csdn.net/detail/hzbooks/4791805
豆瓣收藏本書，請訪問 http://book.douban.com/subject/20385439/
二、OpenGL簡介:
原文鏈接：http://blog.csdn.net/barnett_zhubo/article/details/6460789
OpenGL(Open Graphics Library)定義了一個跨編程語言、跨平臺的編程接口的規(guī)格，是一個性能卓越的三維圖形標(biāo)準(zhǔn)。OpenGL是一個專業(yè)的圖形程序接口，是一個功能強(qiáng)大、調(diào)用方便的底層圖形庫。OpenGL的前身是SGI公司為其圖形工作站開發(fā)的IRIS GL。IRIS GL是一個工業(yè)標(biāo)準(zhǔn)的3D圖形軟件接口，SGI公司便在IRIS GL的基礎(chǔ)上開發(fā)了OpenGL。
?
OpenGL與OpenGL ES的區(qū)別
OpenGL ES是專為內(nèi)嵌和移動設(shè)備設(shè)計的一個2D/3D輕量圖形庫，它是基于OpenGL API設(shè)計的，是OpenGL 三維圖形API的子集，針對手機(jī)、PDA和游戲主機(jī)等嵌入式設(shè)備而設(shè)計。該API由Khronos集團(tuán)定義、推廣，Khronos是一個圖形軟硬件行業(yè)協(xié)會。
?
OpenGL ES的版本
OpenGL ES現(xiàn)在主要有兩個版本：OpenGL 1.x 針對固定管線硬件，OpenGL 2.x針對可編程管線硬件。
OpenGL ES 是從 OpenGL 裁剪定制而來的，去除了 glBegin/glEnd，四邊形（GL_QUADS）、多邊形（GL_POLYGONS）等復(fù)雜圖元等許多非絕對必要的特性。經(jīng)過多年發(fā)展，現(xiàn)在主要有兩個版本，OpenGL ES 1.x 針對固定管線硬件的，OpenGL ES 2.x 針對可編程管線硬件。OpenGL ES 1.0 是以 OpenGL 1.3 規(guī)范為基礎(chǔ)的，OpenGL ES 1.1 是以 OpenGL 1.5 規(guī)范為基礎(chǔ)的，它們分別又支持 common 和 common lite 兩種profile。lite profile只支持定點(diǎn)定點(diǎn)實(shí)數(shù)，而common profile既支持定點(diǎn)數(shù)又支持浮點(diǎn)數(shù)。 OpenGL ES 2.0 則是參照 OpenGL 2.0 規(guī)范定義的，common profile發(fā)布于2005-8，引入了對可編程管線的支持。
下面是我們列舉的一些被Opengl ES裁剪掉的Opengl功能,因此大家在使用api時需要注意,不能使用以下這些api：
1. glBegin/glEnd?
2. glArrayElement?
3. 顯示列表?
4. 求值器?
5. 索引色模式?
6. 自定義裁剪平面?
7. glRect?
8. 圖像處理(這個一般顯卡也沒有，FireGL/Quadro顯卡有)?
9. 反饋緩沖?
10. 選擇緩沖?
11. 累積緩沖?
12. 邊界標(biāo)志?
13. glPolygonMode?
14. GL_QUADS、GL_QUAD_STRIP、GL_POLYGON
15. glPushAttrib、PopAttrib、glPushClientAttrib、glPopClientAttrib?
16. TEXTURE_1D、TEXTURE_3D、TEXTURE_RECT、TEXTURE_CUBE_MAP?
17. GL_COMBINE?
18. 自動紋理坐標(biāo)生成?
19. 紋理邊界?
20. GL_CLAMP、GL_CLAMP_TO_BORDER?
21. 消失紋理代表?
22. 紋理LOD限定?
23. 紋理偏好限定?
24. 紋理自動壓縮、解壓縮?
25. glDrawPixels、glPixelTransfer、glPixelZoom?
26. glReadBuffer、glDrawBuffer、glCopyPixels
由于篇幅關(guān)系,這里我們列舉的可能不是全部,更多詳細(xì)內(nèi)容大家可以參考www.khronos.org/opengles/。
三、Android中的OpenGL ES簡介?
原文鏈接：http://blog.csdn.net/jusang486/article/details/8978112
OpenGL ES軟件層次棧，本章介紹了Android系統(tǒng)中OpenGL ES的調(diào)用層次棧，詳細(xì)分析了庫之間如何通過鉤子（hook）實(shí)現(xiàn)API調(diào)用關(guān)聯(lián)，讓我們明白各個庫之間的依賴關(guān)系。本節(jié)為Android中的OpenGL ES簡介。
Android中的OpenGL ES簡介
Android支持使用OpenGL（Open Graphics Library）API進(jìn)行2D和3D圖形的繪制 ，尤其使用OpenGL ES（Embedded System） API。OpenGL是一個跨平臺的圖形API規(guī)范，它為3D圖形處理硬件定義了一套標(biāo)準(zhǔn)的軟件接口。OpenGL ES是在OpenGL API的基礎(chǔ)上專為嵌入式設(shè)備選取的一套API規(guī)范。自早期的版本Android 1.0就開始支持OpenGL ES 1.0和1.1規(guī)范，自Android 2.2版本開始支持OpenGL ES 2.0規(guī)范。Android提供的OpenGL ES API類似于J2ME JSR239標(biāo)準(zhǔn)，但不同。
我們既可通過Android Framework中提供的API，也可以通過Native層（Native Development Kit ，NDK）的API去使用OpenGL。開發(fā)者可以使用Framework中兩個基本的類GLSurfaceView和GLSurfaceView。Renderer在Android應(yīng)用程序中進(jìn)行圖形繪制操作，也就是在Renderer中使用OpenGL API在GLSurfaceView上進(jìn)行繪制，具體如何使用它們，詳見官方文檔 、 。
在使用GLSurfaceView和GLSurfaceView.Renderer進(jìn)行繪制時，可以使用下面這些OpenGL ES API包。
（1）包javax.microedition.khronos.opengles提供OpenGL ES 1.0/1.1標(biāo)準(zhǔn)實(shí)現(xiàn)，可以使用的API類包括：GL10、 GL10Ext、 GL11、 GL11Ext和GL11ExtensionPack。
（2）包android.opengl，提供了一套靜態(tài)函數(shù)接口，包括OpenGL ES 1.0/1.1和2.0，其性能優(yōu)于包javax.microedition.khronos.opengles。支持OpenGL ES 1.0/1.1的類包括：GLES10、 GLES10Ext、 GLES11和GLES10Ext；支持OpenGL ES 2.0的API類是：android.opengl.GLES20 （自Android 2.2開始）。
由于Android支持OpenGL ES 1.0/1.1、2.0，且由于二者有顯著差異。那么該選擇哪個版本呢？在本節(jié)參考的Google文檔里的"Choosing an OpenGL API Version"部分列出了四項(xiàng)因素，介紹如下。
（1）性能 ：通常，OpenGL ES 2.0能比ES 1.0/1.1提供較快的性能。但是，這最終依賴于Android設(shè)備，不同的設(shè)備平臺OpenGL的實(shí)現(xiàn)不同。
（2）設(shè)備兼容性：開發(fā)者開發(fā)的應(yīng)用程序需要考慮Android設(shè)備類型，不同的Android版本對OpenGL版本支持不同，如OpenGL ES 2.0自Android 2.2才開始支持。
（3）編碼便利性：OpenGL ES 1.0/1.1 API編程較為方便，2.0版本相對復(fù)雜些。
（4）圖形控制：通過使用shaders，OpenGL ES 2.0對圖形繪制能提供較多的控制，可以創(chuàng)建更好的效果，在1.0/1.1版本上則很難達(dá)到。
總結(jié)
以上是生活随笔為你收集整理的OpenCV、OpenCL、OpenGL、OpenPCL的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 大班教案《出生的秘密》反思
- 下一篇： 专业程序员必知必会技巧：驯服复杂代码