I am studying a book and one statement is creating confusion for me for some time:
"OpenGL is really a hardware-independent specification of a programming
interface, and you use a particular implementation of it on a particular kind
of hardware."
If OpenGL is hardware independent than why do we need different implementations for particular kind of hardware. This appears to be a contradiction to me. Could you kindly enlighten me on this?
The specification is hardware-independent, but different hardware is allowed to implement the specification in different ways. OpenGL doesn't specify how it's implemented, just what the final behaviour should be.
The OpenGL specification is like giving someone directions on how to get somewhere. The implementation of the specification is them taking a Ford Focus to get there. You didn't ask them to take that specific car; any car could follow your directions. They could have taken a truck or even walked.
The directions are independent of how you intend to travel. Just as the OpenGL specification is independent of the hardware that it is implemented on. Many different vehicles can follow the same directions, just as many different pieces of hardware can implement the same OpenGL specification.
Actually my confusion is still not resolved. What I understand is that different implementations of OpenGL can have the functions with different names and parameters that do the same thing? We have OpenGL Implentation for iPhones and other devices but due to the limitation of hardware capability the things that PC can do the iPhone Graphics Hardware cannot do. This is precisely what leads to the confusion.
Thus could you kindly differentiate between "Open GL specification" and "OpenGL Implemenation". What is the simple definition of a OpenGL specification?
The specification is the interface of the library.
Is this huge pdf http://www.opengl.org/registry/doc/g...e.20120427.pdf
The pdf state how a certificated opengl implementation must behave.
Apart few kickstart platform specific function the interface is the same.
The implementation is often written in the driver hardware vendor.
As you said the latest nVidia card and an embedded system (iPhone actually use EGL, it's sligly different) have different capability. One part of openGL specification state that to be compliant for a certain version you must have some capability.
Then there are extension, extension are not in the specification and some of them are platform dependent (eg. GL_NV_path_rendering). An implementation don't have to implement all the extension, so you will not find the function entry in the driver/library.
~ ~ I tell you, realtime 3D is made of blood, sweat and screams! ~ ~
OpenGL is an API.Originally Posted by shippo113
The API part can be considered the "front part". It is the part that your see : glBindTexture, glBindBuffer, glDrawElements and so on. This part is what the OpenGL specification describes.
The back part is the part that you don't see. The back part has to talk to the actual hardware and that has to be written by the people who make the video card. On Windows and Linux, nvidia's driver programmers write their own drivers, Intel's people write their own drivers, and AMD's people write their own.
As a programmer (you) that uses GL, you don't need to worry about how GL works behind the scene. All you have to do is make GL function calls and it "just works" on all video cards* and on all OSes **.
* not a guarantee
** all popular OSes (Windows, Linux, Unix, FreeBSD, Sun, Mac OSX)
------------------------------
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Thank you sir. This issue is now resolved. I do not know if I can continue on this thread but I have a question about this one from pg 39:
"There are other situations in which glFlush() is useful:
• Software renderers that build images in system memory and don’t want to constantly update the screen.
• Implementations that gather sets of rendering commands to amortize start-up costs. The aforementioned network transmission example is one instance of this."
As far as I have learnt glFlush causes execution to begin on commands in the buffer, thus this will cause the screen to be updated right? Thus the first point seems to have a contradiction.
The second point talks of what we would called display-list in OpenGL right? That we gather a list of commands in the buffer and than glFlush them all at once, saving processing time which will be wasted if we use the immediate-mode, right??
Kindly respond in few words since I only need a push
It's not contradictory, that's exactly what the first point explains. Unless you call glFlush, there is no guarantee that your draw commands have actually started to be executed, no matter how many of them you've already issued. glFlush ensures that at least they started to execute.
No, display lists are a different story. It talks about remote rendering, i.e. when the client (where the application and the client side of GL is running) is a different machine than the server (where the server side of GL is running).
Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/
Perfect, problem solved
Posting Permissions
