Opengl 3 for 2D?

Started by llynx, October 26, 2009, 00:25:21

Previous topic - Next topic

llynx

Would 2D graphics be faster in Opengl 3? Is it worth upgrading my code to Opengl 3 from 1.1? Any thoughts, comments, opinions?

kappa

opengl 3 is still relatively new, many cards out there still don't support it. By moving to opengl 3 right now you will leave a large number of computers that can't run your app.

llynx

Quote from: javalwjgl on October 26, 2009, 13:32:47
opengl 3 is still relatively new, many cards out there still don't support it. By moving to opengl 3 right now you will leave a large number of computers that can't run your app.

Right right, but is there any sort of efficiency increase or anything? Vram usage etc etc? Or is there not much info on that yet?

Kai

The most "efficiency" increases are due to less host app -> driver calls.
Back in the "old immediate mode" days, there was glBegin(...) glVertex(...) ... glEnd(), etc.
These are the real bottlenecks in an application.

As time progressed, more mechanisms came up that decreased the driver calls, such as display lists. But display lists did not allow the geometry to be dynamic. That was, when Vertex Buffer Objects came into play.
But when having multiple vertex attributes sourced from different Vertex Buffer Objects, one had to glBindBuffer(...) them everytime. That is, where Vertex Array Objects was introduced (that is a new core feature in OpenGL 3.0 actually).

In between these inventions, there was another cool extension, called, EXT_direct_state_access, that removed the unconventient and irritating "bind-to-edit" circumstance (I recommend reading the specs about that!).

So, what really increases performance is reducing driver calls and batching large geometry in one big VBO with one draw call!
Also, use shaders! If you have know what effects you need (directional light from above, etc.), you don't need to call many state-changing OpenGL-methods, such as glEnable(GL_LIGHT), glEnable(...), ... but can once specify all "per-effect" state as uniform variables in a shader. That shader can then be activated with one single call to "glUseProgram(...)".

broumbroum

I suggest you to read about http://en.wikipedia.org/wiki/OpenCL which is embedding a new concept of delegating computation processes to the GPU when openGL actually uses the CPU.. quite interesting.

llynx

Quote from: Kai on October 26, 2009, 17:06:35
The most "efficiency" increases are due to less host app -> driver calls.
Back in the "old immediate mode" days, there was glBegin(...) glVertex(...) ... glEnd(), etc.
These are the real bottlenecks in an application.

As time progressed, more mechanisms came up that decreased the driver calls, such as display lists. But display lists did not allow the geometry to be dynamic. That was, when Vertex Buffer Objects came into play.
But when having multiple vertex attributes sourced from different Vertex Buffer Objects, one had to glBindBuffer(...) them everytime. That is, where Vertex Array Objects was introduced (that is a new core feature in OpenGL 3.0 actually).

In between these inventions, there was another cool extension, called, EXT_direct_state_access, that removed the unconventient and irritating "bind-to-edit" circumstance (I recommend reading the specs about that!).

So, what really increases performance is reducing driver calls and batching large geometry in one big VBO with one draw call!
Also, use shaders! If you have know what effects you need (directional light from above, etc.), you don't need to call many state-changing OpenGL-methods, such as glEnable(GL_LIGHT), glEnable(...), ... but can once specify all "per-effect" state as uniform variables in a shader. That shader can then be activated with one single call to "glUseProgram(...)".

The shaders are probably the most attractive part, it would simplify a lot and do stuff that won't be cpu dependent. Hmmmm I'll see if I can convert my base engine to Opengl 3.2

Ciardhubh

Quote from: llynx on October 26, 2009, 19:49:49
The shaders are probably the most attractive part, it would simplify a lot and do stuff that won't be cpu dependent. Hmmmm I'll see if I can convert my base engine to Opengl 3.2

Keep in mind that OpenGL 3.0/3.2 features are only available on fairly new cards (2007-ish onwards).
http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units
http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units

OpenGL 1.4 + extensions or 2.0 (2003-ish) would probably be better to ensure that a reasonable amount of computers can run your engine (plus new drivers are often still buggy).