The OpenGL ES 2.0 Specs state that "[s]hader compiler support is optional" (see "Notes" here).
Are there any Android devices that do not support shader compilation? If so, is there some shader compiler that I can include with my app to generate a binary instead? Or is the format of the binary also standardized so that I can precompile my shaders before hand and ship the binary with my app if needed? Or is there a requirement I can put into my app so that it isn't offered to devices without compiler support?
Since Android 4.0 (actually 3.0 but Google/Android never released the code as distinct product) OpenGL ES 2.0 has always been part of the spec required to get Android Market/Google Play. See: Android 4.0 Compatibility Definition Document and Android Compatibility Definition Document Archive for the other versions.
Since OpenGL ES 2.0 uses shaders written in OpenGL ES Shader Language I believe your reference to 'optional' for the Shader Compiler refers to the fact the driver vendor can provide a different interface (binary) to load shaders in. Given that there is no specified binary format, everyone as far as I can tell has got GLSL text fed into the graphics driver to build the shaders at runtime. And don't forget there are multiple GPU vendors/chipsets so specific binaries for each doesn't look too attractive from a developer point of view at least in the multi CPU architecture (ARM,x86,MIPS) multi GPU (Qualcomm,PowerVR,nVidia) world of Android. Vendors can still interpret the text differently but at least it would be within the proscribed Khronos spec.
Since text is the what is being sent over to the GPU driver, well performance could be better since it has to do the translation, mapping, scheduling, etc. which leads to the recent announcement for Vulkan see: Android Developer Blog Vulkan Announcement. If you look at the specs, it describes an intermediate binary format but is probably at least a year away from a consumer available implementation.
Unless your intention is to support Gingerbread (2.3) and below - you should be able to rely upon OpenGL ES 2.0 availability.
Related
I recently switched from using glBufferData to glMapBufferRange which gives me direct access to GPU memory rather than copying the data from CPU to GPU every frame.
This works just fine and in OpenGL ES 3.0 I do the following per frame:
Get a pointer to my GPU buffer memory via glMapBufferRange.
Directly update my buffer using this pointer.
Use glUnmapBuffer to unmap the buffer so that I can render.
But some Android devices may have at least OpenGL ES 3.1 and, as I understand it, may also have the EXT_buffer_storage extension (please correct me if that's the wrong extension ?). Using this extension it's possible to set up persistent buffer pointers which do not require mapping/unmapping every frame using the GL_MAP_PERSISTENT_BIT flag. But I can't figure out or find much online in the way of how to access these features.
How exactly do I invoke glMapBufferRange with GL_MAP_PERSISTENT_BIT set in OpenGL ES 3.1 on Android ?
Examining glGetString(GL_EXTENSIONS) does seem to show the extension is present on my device, but I can't seem to find GL_MAP_PERSISTENT_BIT anwhere, e.g. in GLES31 or GLES31Ext, and I'm just not sure how to proceed.
The standard Android Java bindings for OpenGL ES only expose extensions that are guaranteed to be supported by all implementations on Android. If you want to expose less universally available vendor extensions you'll need to roll your own JNI bindings, using eglGetProcAddress() from native code compiled with the NDK to fetch the entry points.
For this one you want the extension entry point glBufferStorageEXT().
I'm trying to port an iOS project to Android (java). I've however encountered a few ES 2.0 extension functions (OES), which do not appear in the Android GLES20 API:
glGenVertexArraysOES
glBindVertexArrayOES
glDeleteVertexArraysOES
It appears I have to call these functions from NDK, dynamically bind the extensions at runtime and check for support od devices. Not something I'd love to do.
While googling I found these functions in the GLES30 api. So my question is:
- is it possible to mix GLES20 and GLES30 calls?
- are these functions basically calls to the same api or is this completely different?
- any other sugggestions?
Just looking at the API entry points, ES 3.0 is a superset of ES 2.0. So the transition is mostly smooth. You request API version 3 when making the GLSurfaceView.setEGLContextClientVersion() call, and your ES 2.0 code should still work. Then you can start using methods from GLES30 on top of the GLES20 methods.
There are some very subtle differences, e.g. related to slight differences in cube map sampling, but you're unlikely to run into them. If you want details, see appendix F.2 of the spec document. Some features like client side vertex arrays have been declared legacy, but are still supported.
The only thing you're likely to encounter are differences in GLSL. You can still use ES 2.0 shaders as long as you keep the #version 100 in the shader code. But if you want to use the latest GLSL version (#version 300 es), there are incompatible changes. The necessary code changes are simple, it's mostly replacing attribute and varying with in and out, and not using the built-in gl_FragColor anymore. You have to switch over to the new GLSL version if you want to take advantage of certain new ES 3.0 features, like multiple render targets.
The downside of using ES 3.0 is of course that you're much more restricted in the devices your software runs on. While the latest higher-end devices mostly support ES 3.0, there are still plenty of devices out there that only support 2.0, and will stay at that level. According to the latest data from Google (http://developer.android.com/about/dashboards/index.html), 18.2% of all devices support ES 3.0 as of July 7, 2014.
As #vadimvolk explained, you will need to check whether OpenGL driver supports OES_vertex_array_object extension. More info here:
http://www.khronos.org/registry/gles/extensions/OES/OES_vertex_array_object.txt
If you just stick to use OpenGL ES 3.0, you can use these methods after checking that you've got OpenGL ES 3.0 context. In Android, you can mix calls to GLES20 and GLES30 because these APIs are backwards-compatible.
All you need is to create OpenGL ES 2.0 context and check if returned context version is 3.0 by reading GL_VERSION string. If it is 3.0, you can use mix both GLES20 and GLES30 functions. Additional info: https://plus.google.com/u/0/+RomainGuy/posts/iJmTjpUfR5E
Functions are same. In GLES20 they are exists only on some devices as not mandatory extensions.
In GLES30 they are mandatory.
If you use them from GLES30 your application will work only on devices supports GLES30 (only devices made for android 4.4).
I am now programming on Android and I wonder whether we can use GPGPU for Android now? I once heard that Renderscript can potentially execute on GPGPU in the future. But I wonder whether it is possible for us to programming on GPGPU now? And if it is possible for me to program on the Android GPGPU, where can I find some tutorials or sample programs? Thank you for your help and suggestions.
Up till now I know that the OpenGL ES library was now accelerated use GPU, but I want to use the GPU for computing. What I want to do is to accelerate computing so that I hope to use some libraries of APIs such as OpenCL.
2021-April Update
Google has announced deprecation of the RenderScript API in favor of Vulkan with Android 12.
The option for manufacturers to include the Vulkan API was made available in Android 7.0 Compatibility Definition Document - 3.3.1.1. Graphic Libraries.
Original Answer
Actually Renderscript Compute doesn't use the GPU at this time, but is designed for it
From Romain Guy who works on the Android platform:
Renderscript Compute is currently CPU bound but with the for_each construct it will take advantage of multiple cores immediately
Renderscript Compute was designed to run on the GPU and/or the CPU
Renderscript Compute avoids having to write JNI code and gives you architecture independent, high performance results
Renderscript Compute can, as of Android 4.1, benefit from SIMD optimizations (NEON on ARM)
https://groups.google.com/d/msg/android-developers/m194NFf_ZqA/Whq4qWisv5MJ
yes , it is possible .
you can use either renderscript or opengGL ES 2.0 .
renderscript is available on android 3.0 and above , and openGL ES 2.0 is available on about 95% of the devices.
As of Android 4.2, Renderscript can involve GPU in computations (in certain cases).
More information here: http://android-developers.blogspot.com/2013/01/evolution-of-renderscript-performance.html
As I understand, ScriptIntrinsic subclasses are well-optimized to run on GPU on compatible hardware (for example, Nexus10 with Mali T604). Documentation:
http://developer.android.com/reference/android/renderscript/ScriptIntrinsic.html
Of course you can decide to use OpenCL, but Renderscript is guaranteed (by Google, being a part of Android itself) to be running even on hardware which doesn't support GPGPU computation and will use any other available acceleration means supported by hardware it is running on.
There are several options: You can use OpenGL ES 2.0, which is supported by almost all devices but has limited functionality for GPGPU. You can use OpenGL ES 3.0, with which you can do much more in terms of GPU processing. Or you can use RenderScript, but this is platform-specific and furthermore does not give you any influence on whether your algorithms run on the GPU or the CPU. A summary about this topic can be found in this master's thesis: Parallel Computing for Digital Signal Processing on Mobile Device GPUs.
You should also check out ogles_gpgpu, which allows GPGPU via OpenGL ES 2.0 on Android and iOS.
if this topic is a duplicate, I'm sorry, but I couldn't find the information I am asking anywhere.
I had started learning OpenGL, and I had even made a very simple game using OpenGL ES 1.1 some years ago for iOS. However, I have abandoned it in favor of other projects. The last version of OpenGL I checked out was 2.1, and frankly, I just checked it out without giving it too much attention before abandoning it for my full time iOS employment.
Now, I want to pick it up again. However, the books I have cover OpenGL 2.5 (Red Book), OpenGL ES 2.0 (I hadn't have the chance to open it) and OpenGL Shading language (I can't remember which one, but I bought it at the same time I bought the Red Book). I have read that OpenGL 3.0 and above changed dramatically the rendering pipeline making it fully programmable, and that's why it dropped support for older features, getting also rid of obsolete and bloating functions.
I have two computers with OS X 10.7.4, a Macbook with GeForce 9400M, and an iMac with ATI Radeon HD 6750 Mobility, both of which I believe are in compliance with OpenGL 3.0 (at least with most features).
Giving all this information, here are my main questions:
Are there any good start up tutorials in OpenGL 3.0+?
Are there any good start up tutorials in OpenGL 3.0 + for OS X? All I could find was outdated tutorials for fixed pipeline
Are the books I already have going to help me or will I need to buy their newest versions due to the shift in the OpenGL pipeline?
Is there something I have misunderstood or that I am missing?
My target is mainly OS X, iOS and Android, therefore I am not interested in platform-specific resources and information. I understand that every platform has its own implementation and extensions to the OpenGL API, but I wan to be as platform-independent as possible. I am not specifying any language in my question, since I am proficient in C/C++/ObjC and the Android OpenGL Java implementation is not that different from what I hear.
Time is not an issue, nor my mathematical/programming skills. And I also don't want to initially learn how to use any wrappers/frameworks around OpenGL, before I learn the basics of OpenGL before learning abstract notions and frameworks around it.
Thank in advance for all the information and directions you can give me regarding this matter.
Answer to question 3:
An excellent book about OpenGL ES 2.0 is OpenGL ES 2.0 Programming Guide by Aaftab Munshi. As OpenGL ES 2.0 is roughly a subset of OpenGL 3.0+, this book might be useful for OpenGL 3.0+ developers as well.
There is no really good book about OpenGL 3.0+. The currently available editions of the OpenGL Red Book mainly focus on old-style deprecated OpenGL programming and can not be recommended.
There will be a new edition of the OpenGL Red Book available in January 2013
with 85% new material and focus on modern OpenGL programming. Wait with the Red Book until then.
From what I've read, it appears that OpenGL ES 2.0 isn't anything like OpenGL 2.1, which is what I assumed from before.
What I'm curious to know is whether or not OpenGL 3 is comparable to OpenGL ES 2.0. In other words, given that I'm about to make a game engine for both desktop and Android, are there any differences I should be aware of in particular regarding OpenGL 3.x+ and OpenGL ES 2.0?
This can also include OpenGL 4.x versions as well.
For example, if I start reading this book, am I wasting my time if I plan to port the engine to Android (using NDK of course ;) )?
From what I've read, it appears that OpenGL ES 2.0 isn't anything like OpenGL 2.1, which is what I assumed from before.
Define "isn't anything like" it. Desktop GL 2.1 has a bunch of functions that ES 2.0 doesn't have. But there is a mostly common subset of the two that would work on both (though you'll have to fudge things for texture image loading, because there are some significant differences there).
Desktop GL 3.x provides a lot of functionality that unextended ES 2.0 simply does not. Framebuffer objects are core in 3.x, whereas they're extensions in 2.0 (and even then, you only get one destination image without another extension). There's transform feedback, integer textures, uniform buffer objects, and geometry shaders. These are all specific hardware features that either aren't available in ES 2.0, or are only available via extensions. Some of which may be platform-specific.
But there are also some good API convenience features available on desktop GL 3.x. Explicit attribute locations (layout(location=#)), VAOs, etc.
For example, if I start reading this book, am I wasting my time if I plan to port the engine to Android (using NDK of course ;) )?
It rather depends on how much work you intend to do and what you're prepared to do to make it work. At the very least, you should read up on what OpenGL ES 2.0 does, so that you can know how it differs from desktop GL.
It's easy to avoid the actual hardware features. Rendering to texture (or to multiple textures) is something that is called for by your algorithm. As is transform feedback, geometry shaders, etc. So how much you need it depends on what you're trying to do, and there may be alternatives depending on the algorithm.
The thing you're more likely to get caught on are the convenience features of desktop GL 3.x. For example:
layout(location = 0) in vec4 position;
This is not possible in ES 2.0. A similar definition would be:
attribute vec4 position;
That would work in ES 2.0, but it would not cause the position attribute to be associated with the attribute index 0. That has to be done via code, using glBindAttribLocation before the program is linked. Desktop GL also allows this, but the book you linked to doesn't do it. For obvious reasons (it's a 3.3-based book, not one trying to maintain compatibility with older GL versions).
Uniform buffers is another. The book makes liberal use of them, particularly for shared perspective matrices. It's a simple and effective technique for that. But ES 2.0 doesn't have that feature; it only has the per-program uniforms.
Again, you can code to the common subset if you like. That is, you can deliberately forgo using explicit attribute locations, uniform buffers, vertex array objects and the like. But that book isn't exactly going to help you do it either.
Will it be a waste of your time? Well, that book isn't for teaching you the OpenGL 3.3 API (it does do that, but that's not the point). The book teaches you graphics programming; it just so happens to use the 3.3 API. The skills you learn there (except those that are hardware based) transfer to any API or system you're using that involves shaders.
Put it this way: if you don't know graphics programming very much, it doesn't matter what API you use to learn. Once you've mastered the concepts, you can read the various documentation and understand how to apply those concepts to any new API easily enough.
OpenGL ES 2.0 (and 3.0) is mostly a subset of Desktop OpenGL.
The biggest difference is there is no legacy fixed function pipeline in ES. What's the fixed function pipeline? Anything having to do with glVertex, glColor, glNormal, glLight, glPushMatrix, glPopMatrix, glMatrixMode, etc... in GLSL using any of the variables that access the fixed function data like gl_Vertex, gl_Normal, gl_Color, gl_MultiTexCoord, gl_FogCoord, gl_ModelViewMatrix and the various other matrices from the fixed function pipeline.
If you use any of those features you'll have some work cut out for you. OpenGL ES 2.0 and 3.0 are just plain shaders. No "3d" is provided for you. You're required to write all projection, lighting, texture references, etc yourself.
If you're already doing that (which most modern games probably do ) you might not have too much work. If on the other hand you've been using those old deprecated OpenGL features which from my experience is still very very common (most tutorials still use that stuff). Then you've got a bit of work cut out for you as you try to reproduce those features on your own.
There is an open source library, regal, which I think was started by NVidia. It's supposed to reproduce that stuff. Be aware that whole fixed function system was fairly inefficient which is one of the reasons it was deprecated but it might be a way to get things working quickly.