I'm beginning my journey into graphics programming and want to learn OpenGL. Because I'm green to graphics programming but not to C and C++, a familiar question came up when I looked at OpenGL and ES… Is OpenGL a superset of OpenGL ES? I read in an ES 3.0 guide that it uses shader-based implementations that exist as part of OpenGL's embedded libraries, and that ES avoids using similar/redundant libraries provided by big 'ol OpenGL due to mobile hardware limitations… Are shader-based implementations which are a huge part of OpenGL ES less efficient solutions when programming on the desktop? OR should I look at the two APIs as different beasts altogether? thx in advance.
C++ – OpenGL’s relationship to OpenGL ES (3.0)
cgraphicsmobileopengl
Related Solutions
Except OpenGL, I never used those libraries, but I'm going to try to guess, by reading wikipedia pages, like you did.
You seem right about Mesa. Here is the additional info we have :
To make things simpler, let's imagine a simplified flow of data (and commands) that happens at the entries and exits of each of those APIs. At the very beginning we have your application program (compiled code), that you run from your computer. At the end we have images that are displayed on your screen.
There are several cases which I will restrain to the answers to these questions:
-does your computer have a graphic card (GPU), or only a CPU, to process graphic functions ?
-is your application embedded in a window of the x-window system ?
-if you use the x window system, is the "x server" running on your computer or on an other computer on the network ?
I'll assume you have the drivers for your GPU if you have one, and that you have Mesa for the software rendering).
First scenario : you run a graphic application written with OpenInventor, without using to the X Window System, and you don't have a graphic card. The program flow would be quite similar to :
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
What happens here is called "software rendering" : the graphics command are not handled by any graphic hardware, but instead by your usual CPU, the processor that generally runs software.
Second scenario : now imagine that with the same conditions as above, you have a graphic card. The flow would look more like this :
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
What happens now is called "hardware acceleration", usually faster than the first scenario.
Third scenario : now let's introduce the X Window System flow, or at least how I think it is, based on the few Wikipedia lines I read.
Let's forget about the graphic hardware and API for a while. The flow should look like :
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
Note that when using the X Window System, your screen and the computer from which you run your application may not be "directly" connected, but could be connected through a network.
Fourth scenario : suppose you want to add fancy 3D graphic renderings to your X Client application from the previous example. It seems to me that the X Window System is not originally able to do this, or at least it would necessitate much convoluted code to perform the equivalent of an OpenGL API function.
Luckily you can use GLX to add support for OpenGL commands to the system. You now have :
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
Now you can reconnect that last arrow to the one after "OpenGL" in the first scenario : you can get 3D images on your screen !
Finally about what I think understand of the DRI :
It seems to allow Mesa to have access to the GPU, so that would modify the flow of our first scenario into :
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
And it also seems to short-circuit the flow when using GLX, given the condition that its server and client are on the same computer, and that you have a GPU. In that case the graph of our fourth scenario would simply become :
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
That's it !
Now keep in mind that I'm not an expert in Unix environments, so my best advice is to study the documentation of each of those APIs to know precisely what they can do.
Combining the previous chart into a single one might make things easier to understand. I let this as an exercice to you!
I was doubting: I'm writing a cross-platform engine OpenGL C++, I figured out windows forces the developers to access OpenGL features above 1.1 through extensions.
That sounds odd, because Windows have never forced me to use extensions, I always use core functions when possible, and while saying "when possible" I mean if my graphics card/driver supports the features. Because that plays the biggest part.
If the functionality is available in the core, is it also available as extension (VBO's e.g.)?
Not necessarily! But always favor the core functions when you can. Though when using extensions (EXT, ARB, etc) just always remember to check, if they are available.
If you're going to release a program using an NV Extension (Nvidia Extension), then again be sure to have something that checks whether the function is available, as if someone with a non-Nvidia graphics card uses your program it will most likely crash.
Or is an extension something you never know is available?
Yes, you never know for sure if an extension is available, it depends on various things such as.
- The OpenGL version you're using
- Your Graphics Card
- Your Graphics Card version and model (GeForce, Cuda, Radeon, etc)
- Your Graphics Card vendor (Nvidia, AMD, etc)
By using core functions the chances are that the majority of people will be able to run the program, as long as their graphics card can run the particular GL version.
- EXT extensions usually only are supported by a few vendors.
- ARB extensions are often supported by the majority but not necessarily all vendors.
- Core functions are supported by every card which supports the particular GL version, which the program is using.
Remember
Always remember you can't mix-match and use GL_TEXTURE1
with glActiveTextureARB
and you can't use GL_TEXTURE1_EXT
with glActiveTexture
. Even though mixing them sometimes produces the desired result, there is no guarantee for that.
Best Answer
Desktop OpenGL and OpenGL ES share a lot of similarities. The older OpenGL, prior to programable shaders, is somewhat similar to ES v1, in which both relied on a fixed-function rendering pipeline (i.e.: just the C-API). GL ES 2 and above is a lot more like the modern desktop GL, since it requires the use of shaders and other modern rendering practices like the use of Vertex Buffers. In fact, there are two extensions to the desktop GL that aim at reducing the work of porting code from desktop to GL ES devices, by providing to the desktop version all the specific functions of GL ES. ARB_ES2_compatibility, ARB_ES3_compatibility
So I think it is fair to say that OpenGL ES is a subset of desktop GL. Both are converging to a unified API, and the overall "feel" of the library is pretty much the same for both.
If you are looking for a more detailed comparison of existing GL versions, I think your best bet is looking at the wiki History of OpenGL and the OpenGL ES wiki. There is also this SO thread that you might find worth reading.