手機(jī)硬件的更新是如此迅速以至于我們開始進(jìn)入一個(gè)手機(jī)與高端PC功能無(wú)異的時(shí)代。它們的區(qū)別將只是芯片的功耗不同而已。

我不想讓自己聽起來(lái)像是在推廣我們自己的芯片，但我相信Tegra K1是未來(lái)即將發(fā)生的事物的前瞻。不僅僅發(fā)生在我們身上，我希望其他行業(yè)也能加入進(jìn)來(lái)，從而使開發(fā)者可以為從PC到手機(jī)安全地假設(shè)一個(gè)相對(duì)統(tǒng)一的功能集。K1只是***示例，因?yàn)樗腉PU核心是Kepler 。而且它不是什么營(yíng)銷手段，它實(shí)際上是與運(yùn)轉(zhuǎn)像GTX780這種神奇事物相同的微架構(gòu)。幾年的血汗與淚水使其成為了可能。并且限于尺寸，功率和熱限制，它 只有192個(gè)核心（而不是2304個(gè)），但它仍具有較強(qiáng)的性能競(jìng)爭(zhēng)力。更重要的是在功能上它處于一個(gè)完全不同的陣營(yíng)中，因?yàn)樗С滞暾淖烂婕?jí) OpenGL4.4,包括幾何著色器，鑲嵌，計(jì)算等，還有像bindless這樣的支持其他事物的擴(kuò)展。

但是Android只支持OpenGL ES,對(duì)嗎？實(shí)際上不是這樣的。雖然現(xiàn)在在Android平臺(tái)上，***的官方支持的圖形API是OpenGL ES,你仍然可以使用EGL在平臺(tái)上創(chuàng)建一個(gè)"大"OpenGL 上下文，前提是你的設(shè)備支持它。這使得在不同的操作系統(tǒng)上傳輸數(shù)據(jù)很實(shí)用，Windows/Linux/Mac/streamOS 都有OpenGL的后臺(tái)程序，可以快速啟動(dòng)并模擬裁剪平面(clip planes),alpha測(cè)試,或者spec中的少數(shù)差異。它同樣可以作為一個(gè)不錯(cuò)的引用渲染后端程序，在ES渲染路徑啟動(dòng)和運(yùn)行之前驗(yàn)證你的端口。

不要擔(dān)心，你可以在你的app中同時(shí)使用GLES和BigGL。實(shí)際上，這很簡(jiǎn)單。最重要的事情在EGL中，它是Android為創(chuàng)建OpenGL上下文而公開的API。Java或C/C++同樣可以這樣做，但是要注意需要EGL_SPEC.1.4以上版本。

首先，在創(chuàng)建上下文(或者調(diào)用任何一個(gè)EGL函數(shù))之前，要知道哪個(gè)版本的GL最支持當(dāng)前設(shè)備?？梢酝ㄟ^簡(jiǎn)單地調(diào)用eglBindAPI(EGL_OPENGL_API)來(lái)完成。該API會(huì)將EGL切換到桌面OpenGL模式，如果當(dāng)前設(shè)備不支持，則返回EGL_TRUE或者留下未改變的狀態(tài)并返回EGL_FALSE。鑒于該函數(shù)可以切換全局狀態(tài)，所以最安全的做法是讓EGL首先調(diào)用它，之后不再調(diào)用。

創(chuàng)建完上下文之后，如果eglBindAPI()函數(shù)沒有切換BigGL模式，你就要和你之前那樣創(chuàng)建你的ES上下文。如果切換成功，你可選擇性地 創(chuàng)建BigGL上下文。幸運(yùn)的是，EGL讓它簡(jiǎn)單化。因?yàn)槲覀円呀?jīng)調(diào)用了eglBindAPI(EGL_OPENGL_API),EGL已經(jīng)設(shè)置為 BigGL模式，所以我們只需要在配置文件和上下文中調(diào)整一些屬性即可。

首先，在傳遞給eglChooseConfig()的配置屬性中，我們需要確保 EGL_RENDERABLE_TYPE 設(shè)置為 EGL_OPENGL_BIT ，而不是EGL_OPENGL_ES2_BIT.

其次, 傳遞給函數(shù)  eglCreateContext() 的屬性也需要稍微調(diào)整。對(duì)于 ES上下文，通常把 EGL_CONTEXT_CLIENT_VERSION 設(shè)為 1, 2 或3， 這取決于你想搭建哪個(gè)版本的OpenGL ES.對(duì)于BigGL上下文，我們不使用這個(gè)屬性,所以不要設(shè)置。事實(shí)上，你可以直接把BigGL的屬性列表置空。

粗略地講，這比較像下面的樣本 (為簡(jiǎn)潔起見，忽視錯(cuò)誤檢查):

if(eglBindAPI(EGL_OPENGL_API)) 
{ 
  // Create a BigGL context... 
  EGLDisplay display = eglGetDisplay(...); 
  eglInitialize(display, ...); 
  const EGLint configAttrs[] = 
  { 
    EGL_SURFACE_TYPE,    EGL_WINDOW_BIT, 
    EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT, 
    // backbuffer attributes here... 
    EGL_NONE 
  }; 
  EGLConfig config; 
  EGLint    numConfigs = 0; 
  eglChooseConfig(display, configAttrs, &config, 1, &numConfigs); 
  EGLint ctxAttrs[] = 
  { 
    EGL_NONE 
  }; 
  eglCreateContext(display, config, EGL_NO_CONTEXT, ctxAttrs); 
} 
else 
{ 
  // TODO: Fallback to old ES context creation... 
} 

***一點(diǎn)問題，也是我對(duì)于使用OpenGL或者OpenGL ES的開發(fā)人員的一些建議，不論他們基于怎樣的平臺(tái)進(jìn)行開發(fā)。尤其重要的一點(diǎn)是像上面提到的那樣在API之間進(jìn)行切換。并且，不要隱式地鏈接到GL符號(hào)！就算是再多的功能，你都應(yīng)當(dāng)使用eglGetProcAddress()， 并且當(dāng)心不要在上下文中共享函數(shù)指針。如果你做了一下比較瘋狂的事情，比如在同一個(gè)應(yīng)用中創(chuàng)建了一個(gè)BigGL上下文和一個(gè)ES上下文，或者創(chuàng)建了像 glDrawElement()這樣的函數(shù)，在兩者的API中都存在，但是可能指向了完全不同的實(shí)現(xiàn)方法。這就意味著你應(yīng)當(dāng)僅鏈接到libEGL，所以需 要通過qglGetProcAddress()函數(shù)查詢所有的符號(hào)。

編輯：應(yīng)當(dāng)指出的是，從技術(shù)的角度講，通過eglGetProcAddress()可獲得的“EGL_KHR_get_all_proc_addresses”應(yīng)當(dāng)是目前的核心功能，但是我堅(jiān)信，既然目前它在Android通用EGL接口上進(jìn)行了實(shí)現(xiàn)，也就意味著它可以單獨(dú)驅(qū)動(dòng)，這可能在舊版本的Android上無(wú)法正常工作。但是如果你正在考慮支持BigGL，你可能不希望舊設(shè)備成為你道路上的絆腳石。

特別強(qiáng)調(diào)：我強(qiáng)烈建議如果可能的話，任何正在開發(fā)的應(yīng)用程序應(yīng)該也有GLES渲染路徑。BigGL對(duì)于開發(fā)是實(shí)用的，對(duì)于一些邊緣特性，甚至?xí)鼘?shí)用，但是有GLES后端同樣會(huì)幫助Android避免分段存儲(chǔ)，并且?guī)椭愕膽?yīng)用更多的曝光在盡可能多的用戶面前。

英文原文：OpenGL 4.4 and beyond on Android

 譯文鏈接：http://www.oschina.net/translate/opengl-44-and-beyond-on-android