tags:

views:

557

answers:

4

For rendering I have a current GL context, associated to a window. In the case the application render multiple scenes (for example using accumulation or different viewports) I think it is ok to reuse the same context.

My question, indeed, is: why should I use multiple GL context? I red on ARB_framebuffer_object extension spec that MakeCurrent call could be expansive, and in the case the ARB_framebuffer_object extension is present I can render on a generic buffer without using MakeCurrent.

Apparently the only reason to use multiple GL context is to avoid to setup context state (pixel store, transfer, point size, polygon stipple...) or to have avaialable multiple render buffers configuration (one context with accumulation, another without). How to determine when is better an alternative context instead of setting context state?

Thankyou all!

+1  A: 

In GUI programs you can have multiple opengl views, where some of them run in the same thread as the GUI and others run in their own thread. Further more you can run opengl in offscreen mode. At least one context per thread.

Not sure if it makes sense to have more contexts per thread.

neoneye
+1  A: 

I usually tend to use additional contexts only when I absolutely have to, such as rendering to multiple GUI windows. For everything else, I use framebuffer objects or state changes.

However, performance recommendations like this do not apply to all cases. If in doubt, you should measure your own application on your own hardware. gDEBugger might help, there's a trial version available.

Malte Clasen
+1  A: 

If you want to address multiple GPU's, you need to use multiple context since you have at least one drawable per GPU, with a GPU-specific context.

eile
A: 

IIRC, objects like textures and buffer objects can be shared between contexts, so technically you could create a second context in a second thread and load the textures asynchronously there, without worrying whether the first thread is performing the rendering.

Kronikarz