OpenGL 4.4 和 Android
手机硬件的更新是如此迅速以至于我们开始进入一个手机与高端PC功能无异的时代。它们的区别将只是芯片的功耗不同而已。
我不想让自己听起来像是在推广我们自己的芯片，但我相信Tegra K1是未来即将发生的事物的前瞻。不仅仅发生在我们身上，我希望其他行业也能加入进来，从而使开发者可以为从PC到手机安全地假设一个相对统一的功能集。K1只是首个示例，因为它的GPU核心是Kepler 。而且它不是什么营销手段，它实际上是与运转像GTX780这种神奇事物相同的微架构。几年的血汗与泪水使其成为了可能。并且限于尺寸，功率和热限制，它只有192个核心（而不是2304个），但它仍具有较强的性能竞争力。更重要的是在功能上它处于一个完全不同的阵营中，因为它支持完整的桌面级OpenGL4.4,包括几何着色器，镶嵌，计算等，还有像bindless这样的支持其他事物的扩展。
但是Android只支持OpenGL ES,对吗？实际上不是这样的。虽然现在在Android平台上，首选的官方支持的图形API是OpenGL ES,你仍然可以使用EGL在平台上创建一个"大"OpenGL 上下文，前提是你的设备支持它。这使得在不同的操作系统上传输数据很实用，Windows/Linux/Mac/streamOS 都有OpenGL的后台程序，可以快速启动并模拟裁剪平面(clip planes),alpha测试,或者spec中的少数差异。它同样可以作为一个不错的引用渲染后端程序，在ES渲染路径启动和运行之前验证你的端口。
不要担心，你可以在你的app中同时使用GLES和BigGL。实际上，这很简单。最重要的事情在EGL中，它是Android为创建OpenGL上下文而公开的API。Java或C/C++同样可以这样做，但是要注意需要EGL_SPEC.1.4以上版本。
首先，在创建上下文(或者调用任何一个EGL函数)之前，要知道哪个版本的GL最支持当前设备。可以通过简单地调用eglBindAPI(EGL_OPENGL_API)来完成。该API会将EGL切换到桌面OpenGL模式，如果当前设备不支持，则返回EGL_TRUE或者留下未改变的状态并返回EGL_FALSE。鉴于该函数可以切换全局状态，所以最安全的做法是让EGL首先调用它，之后不再调用。
创建完上下文之后，如果eglBindAPI()函数没有切换BigGL模式，你就要和你之前那样创建你的ES上下文。如果切换成功，你可选择性地创建BigGL上下文。幸运的是，EGL让它简单化。因为我们已经调用了eglBindAPI(EGL_OPENGL_API),EGL已经设置为BigGL模式，所以我们只需要在配置文件和上下文中调整一些属性即可。
首先，在传递给eglChooseConfig()的配置属性中，我们需要确保 EGL_RENDERABLE_TYPE 设置为 EGL_OPENGL_BIT ，而不是EGL_OPENGL_ES2_BIT.
其次, 传递给函数 eglCreateContext() 的属性也需要稍微调整。对于 ES上下文，通常把 EGL_CONTEXT_CLIENT_VERSION 设为 1, 2 或3， 这取决于你想搭建哪个版本的OpenGL ES.对于BigGL上下文，我们不使用这个属性,所以不要设置。事实上，你可以直接把BigGL的属性列表置空。
粗略地讲，这比较像下面的样本 (为简洁起见，忽视错误检查):
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... }最后一点问题，也是我对于使用OpenGL或者OpenGL ES的开发人员的一些建议，不论他们基于怎样的平台进行开发。尤其重要的一点是像上面提到的那样在API之间进行切换。并且，不要隐式地链接到GL符号！就算是再多的功能，你都应当使用eglGetProcAddress()，并且当心不要在上下文中共享函数指针。如果你做了一下比较疯狂的事情，比如在同一个应用中创建了一个BigGL上下文和一个ES上下文，或者创建了像glDrawElement()这样的函数，在两者的API中都存在，但是可能指向了完全不同的实现方法。这就意味着你应当仅链接到libEGL，所以需要通过qglGetProcAddress()函数查询所有的符号。
编辑：应当指出的是，从技术的角度讲，通过eglGetProcAddress()可获得的“EGL_KHR_get_all_proc_addresses”应当是目前的核心功能，但是我坚信，既然目前它在Android通用EGL接口上进行了实现，也就意味着它可以单独驱动，这可能在旧版本的Android上无法正常工作。但是如果你正在考虑支持BigGL，你可能不希望旧设备成为你道路上的绊脚石。
特别强调：我强烈建议如果可能的话，任何正在开发的应用程序应该也有GLES渲染路径。BigGL对于开发是实用的，对于一些边缘特性，甚至会更实用，但是有GLES后端同样会帮助Android避免分段存储，并且帮助你的应用更多的曝光在尽可能多的用户面前。