Jump to content
  • Advertisement
Sign in to follow this  
Callidus

OpenGL ExtEscape CPU Time Consumption

This topic is 4218 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Dear GameDev Community I am currently profiling my OpenGL engine on a Windows platform and what worries me is that a function called "ExtEscape" is the most time consuming with up to 18% CPU time. I do not call this function directly. Unfortunately, MSDN is not too specific about it. But looking at the call stack reveals that ExtEscape is for instance triggered by swapping buffers and vertex/index buffer updates. My questions are: 1) What does ExtEscape really do in the context of 3D graphics? 2) Is the observed time consumption normal behaviour? 3) What could I do to improve the situation? As always, I am grateful for your help. If you require more information, please don't hesitate to ask. Best regards Calli

Share this post


Link to post
Share on other sites
Advertisement
1.) I'm not too sure on the specifics here, but ExtEscape is likely to be querying whether the gfx hardware is still busy or until the frame is complete. As such, you shouldn't worry too much about it as it is not called directly by you, but rather by the run-time/driver. You can't really control that.
2.) Yes, waiting while buffers are swapped is a perfectly normal operation, but happens for a variety of reasons.
3.) Well there are several things, but you need to be sure what the actual situation is currently:

An 18% wait inside the driver/runtime can easily happen and it is a normal operation when:
1.) Cpu must wait for GPU in the case of accesses to locked resources currently being rendered.
2.) Stalls of the pipeline. Normally caused by reading back data from the gpu.
3.) Waiting for vsync (ie. both cpu & gpu have completed very quickly)
4.) Waiting for gpu to finish. If driver has already queued a maximum no. of frames for the gpu, your cpu may stall until the gpu has finished some of it's work.

My suspicion is that case 3 or 4 is happening for your app. If you're not doing anything gpu intensive at the points in question then I'd suggest case 3:
1.) vsync is enabled for your application.
2.) gpu and cpu operations are both completing in less than 1/60th of a second (or 1/30th or 1/20th, 1/15th etc...).
3.) therefore the driver/runtime waits in swapbuffers 18% of your frametime until the next vsync.

The golden rule here is that you should profile your application without vsync enabled. If you don't know how, you can do it either in the driver control panel (force it all off) or you can do it programmatically with wglSwapIntervalEXT(). See http://oss.sgi.com/projects/ogl-sample/registry/EXT/wgl_swap_control.txt for details on how to use this function/extension.

I hope something there helped.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!