Sign in to follow this  
neebee

OpenGL inside opengl

Recommended Posts

I want to know how exactly opengl saves the states and etc. I mean when you call glBegin or something like this it sets some state variable. where are these state variables defined? not in gl.h I suppose? because these variables are global and no matter which scope of your application you call them, it sets them.

Share this post


Link to post
Share on other sites
Quote:
Original post by neebee
I want to know how exactly opengl saves the states and etc.

I mean when you call glBegin or something like this it sets some state variable. where are these state variables defined? not in gl.h I suppose? because these variables are global and no matter which scope of your application you call them, it sets them.


Each context has its own state, so it's not completely horrible. A lot of it can be read by calling functions such as glGetIntegerv, glGetDoublev, etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by the_edd
Each context has its own state, so it's not completely horrible. A lot of it can be read by calling functions such as glGetIntegerv, glGetDoublev, etc.


I got you, but how does glGetIntegerv reach that variable. how does this context mechanism work? where are these context states defined and how does it access it? I ask this as a programming practice.

Share this post


Link to post
Share on other sites
This is a very complex topic. In short, the state is tracked by the OpenGL driver.

OpenGL drivers are typically separated into a "frontend" or "state tracker", which translates incoming OpenGL calls into some internal representation; and a "backend" or "hardware driver", which translates that internal representation into a command stream that can be executed by the GPU.

Of course, things are much more complex than that. OpenGL drivers must emulate features in software if the hardware does not support them ("software fallback"). Before your OpenGL commands reach the drivers, they typically travel through an OS-provided library (opengl32.dll, libGL.so, etc) which must choose the correct driver to dispatch them to.

If you wish to learn more about the dirty details, there's no better source than mesa3d.org. This is an open-source implementation of OpenGL, which contains both the state tracker and a large number of hardware *and* software drivers. It forms the backbone of 3d graphics on Linux and a number of other operating systems.

Start with the dispatching mechanism and head over to mesa3d.org for more documentation and the actual source code.

Share this post


Link to post
Share on other sites
en passant, this kind of a programming approach for a library is outdated now as far as I can understand?

is there a performance benefit for this or should I stick with C++ classes for library implementations?

Share this post


Link to post
Share on other sites
Quote:
Original post by neebee
en passant, this kind of a programming approach for a library is outdated now as far as I can understand?

is there a performance benefit for this or should I stick with C++ classes for library implementations?


Many (most) OpenGL drivers are implemented in C++, with only the public interface being defined in C. The reason? Every language can consume C interfaces in some way. Nothing can consume C++ interfaces, at least not in any cross-platform way (since C++ does not have a well-defined ABI).

In other words, as long as your library exposes a C API, it doesn't really matter what language it is actually implemented in.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this