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.
Related
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).
Let's say I wanted to write my own software for Android that would benchmark rendering performance. Something along the lines of 3Dmark basically. What sorts of factors should the different test cases measure? Would it simply be rendering a ton of verts? Running a ton of textures?
Are there any resources out there that are either books or online guides that might help with developing specific test cases that would exercise specific portions of a phone/tablet's GPU?
Thanks,
Besides vertex count and texture sizes, the other major variables you should cover in an OpenGL ES benchmark are the display resolution and the complexity of the shader programs. You might also want to evaluate the compatibility of the OpenGL ES and EGL drivers, including extensions. There is a real need for that on Android.
This question is specifically about OpenGL 2.0 ES on Android, but if there are more general answers based on the OpenGL specs, I'd be interested in those too.
Is there a way to pass a message (string) out of a GL 2.0 ES shader to the application code (either Java or native)? E.g.
void main()
{
...
if (somecondition)
{
logMessage("Things are messed up man");
}
}
If not, why would a programming environment be defined (OpenGL ES 2.0 shader language in this case) without this type of facility? I don't know anything about hardware but surely this would not be that hard to implement in the GPU. If there are performance issues, it could always be optionally #ifdef'd out of the shader code...
No, there are no logging facilities like you're asking for in any of the OpenGL shading languages (including OpenGL ES). Debug contexts on desktop OpenGL (and in ES when they get there) may provide some information, but there's nothing like what you're asking for.
The most common technique (and this is usually done in the context of fragment shaders) is to set the output of the shader to an error color, or some other signal that indicates the shader failed some condition you were banking on.
Given many instances of a particular shader execute simultaneously (think of how many fragment shader threads are executed when filling in a full-screen quad), tracking the state of each thread would require considerable amounts of state to do the job right.
You say:
I don't know anything about hardware but surely this would not be that hard to implement in the GPU.
No; modern GPUs are complex machines with complex designs. While doing this is possible, it's not worth the additional complexity and hardware validation. That's the magic of APIs, while something like that looks conceptually simple, it's not.
radical7 answer is correct.
If you want to do debugging of the shader code, GPU vendors provide compilers and simulators. Or you could try the glm library and code the shader in C++, with all the tools to print messages you need.
I just caught a little quirk in my fledgling application's GL interfaces. On desktop GL things like glShaderSource() take a GLchar*, but on the mobile GLES interfaces they take a plain char*.
Now, this is really a very trivial thing to fix. Since GLchar is a typedef of char anyway, one can just use char* on desktop GL and be alright everywhere.
However, seeing this issue raises concerns in me about coming across other compatibility issues in the GL vs GLES realm. Of course I know that GLES 2.0 is basically a stripped down OpenGL 2.0, and that I'll have to suffer the loss of things like the fixed function pipeline. But will it get any worse that that? I was hoping that the interfaces which GLES 2.0 did leave for me would at least work identically to their desktop GL counterparts. But is this indeed the case? I sure do hope so.
But is this indeed the case?
No.
For example, glTexSubImage2D doesn't work in ES 2.0 like it does in desktop GL. The internal format and pixel format parameters take entirely different values, values that would not be legal in most cases with desktop GL.
You should not expect ES 2.0 code to run without changes on desktop GL.
So Android 3.0 (honeycomb) is out now and boasts some kind of new hardware-accelerated 3D graphics engine called Renderscript.
Renderscript 3D graphics engine
Renderscript is a runtime 3D framework that provides both an API for building 3D scenes as well as a special, platform-independent shader language for maximum performance. Using Renderscript, you can accelerate graphics operations and data processing. Renderscript is an ideal way to create high-performance 3D effects for applications, wallpapers, carousels, and more.
And according to this blog post dating back from 2009, this graphics engine could already be found used in a class named Fountain (even before honeycomb). This last clue was helpful to me, because now I can easily find that class name in the Honeycomb code.
Can any of you supply any more insights into Renderscript? and ways to learn more about how to use it? Now that this has become a public api, I'm assuming that the people in-the-know may be able to get the permission to freely talk about it (I hope).
RenderScript is several things:
- A language, similar to C99 with extra advanced features. It's pre-compiled on the host and re-compiled on the device, to achieve best performance.
- A rendering library (you can draw textured meshes, etc.)
- A compute library (to run heavy computations in RenderScript which can then be offloaded to the GPU, several CPUs or DSPs.)
Have you downloaded the Honeycomb SDK via the android tool? It downloads documentation, including the javadoc pages for Renderscript.