Our application uses opnegl to render some 3d graphs.
First call to wglCreateContext seems to take more time after system restart (Almost 3 secs).
After that the time taken is just 1/10 or less (0.3 to 0.2 secs).
This high log is seen only for the first invocation of wglCreateContext after every restart.
Is this any known case?
I am new to opengl so kindly pardon my ignorance on the same.
Regards,
Amal
The first call to wglCreateContext is going to initialise OpenGL, and possibly a large portion of the driver for the video hardware. So the behaviour isn’t unexpected.
Thanks for the update. Will it be possible to elaborate a bit on the same. Like why there is a difference in times for the first call and subsequent calls. Is anything specific limited to just the first call? Also, is there any way to minimise the duration of the first call?
Because the first call has to initialise everything.
Probably not. But you can run the application on system start so that when you actually want to use it, it won’t be the first call.
Thank you for the details.
Do we have any specific APIs that would help us identify if opengl is already initialized?
Another query I have is whether it is possible to initialize opengl on system start up by enabling some options/services or some BIOS flag?
It’s more that the graphics driver (which implements the OpenGL API) is probably doing initialization work on the first context creation, so anything related to that would be very driver specific.
You may have a better chance to discover how to speed things up by using a system profiler to find out what is happening during that delay - for example if you were to discover that a lot of shared libraries need to be loaded from disk as part of the initialization you could do some pre-fetching to ensure they are in cache. As with any optimization work you first need to determine what the cause of the slowdown is before you can start addressing it effectively. So far we’ve only guessed at the driver doing startup initialization work (it’s a good guess, but measuring is usually the more reliable path).
You could also write a very simple OpenGL program that just creates a context and then exits and arrange for it to be run at the correct point during startup (sometime after the graphical environment is up I imagine). How to do this (the run during startup part) is somewhat system dependent and you are likely to get more help with that on a different forum.
Just made an observation related to the high load times.
When we disabled Windows Defender real time protection, we could see that load time is drastically reduced.
For example, with real time protection turned ON, wglCreateContext call clocks 2.6 seconds.
When turned off, it is 0.07 seconds.
The performance log for windows defender shows a 2.5 second scan time for igc32.dll.
Think this dll is related to Intel Graphics Shader compiler.
Have you come across any such issue before?
Graphics driver init may load a lot of on-disk driver-related files to preload things like driver performance profiles, some of the on-disk shader cache from prior runs, etc. Have seen this kind of thing with NVIDIA drivers before (i.e. lots of file loading), but it’s been years since I dug into it.
That’s likely how *Windows Defender" gets looped in. It’s possibly being kicked to scan those files that the graphics driver (linked into your app) is trying to load, to verify that Defender wants to allow the driver+your app to even receive them. It may chose to block them.
You may be able to get some insight into what the driver is busy doing in while it’s in wglCreateContext by running a sample-based profiler like Very Sleepy:
Just see what your app is blocked on while that wglCreateContext is running.
Alternatively, you can capture the list of files accessed by your process during startup (during that wglCreateContext hang), and, if the usermode graphics driver is what’s actually tripping those file loads, observe which files it’s loading. That may give you clues as to what you can do to reduce the wglCreateContext() time consumption. There are probably multiple ways to get that list of files on Windows, but here’s one:
(On Linux it’s easier. Just use strace.)
For instance, clearing out the graphics driver’s shader cache may or may not help, depending on your driver.
Alternatively, you can adjust your Windows Defender config to whitelist some/all of the directories that the graphics driver is accessing files in. This may reduce or remove the of the large graphics driver init cost you’re seeing with Windows Defender active (with your current ASR rule config). Or otherwise modify the Defender config so it’s not imposing this extra startup time cost on your app.