I’ve encountered an odd behavior in the OpenGL ES 2.0 SDK for Windows X86PCEmulation. After running PVRTraceGUI for the first time, I couldn’t initialize my GLES-application nor any of the SDK examples. It took me a while to realize this relationship. After trying a few things (new gpu driver, old restore point in windows …), the solution was to run PVRTraceGUI in together with my application.
The actual problem occurs in my initialization code:
eglGetConfigs is successful, but returns 0 configs
eglCreateWindowSurface fails with error code EGL_BAD_CONFIG
Together with PVRTraceGUI, I get 2 configs and everythings works fine as it did before.
Can anybody tell my what PVRTraceGUI is doing and how I can continue working without running that tool?
The number of configs available depends on the currently selected hardware profile. You can select which one you want to use by running the PVRVFrameGUI application.
When PVRTraceGUI is running it will temporarily force the emulator to use the “Host” profile, which basically means “don’t try to emulate any specific hardware device and just use whatever is available on the host system”. So my guess is that you have a hardware profile selected which is returning 0 configs, but it works when PVRTraceGUI is running because the profile selection gets overridden.
Before running the PVRVFrameGUI app can you open up the following file:
UsersUserNameAppDataRoamingImagination TechnologiesPVRVFrame.plist and look for the
profile section and let me know what that value is set to? By default it should always be “1” for the Host profile.
thanks for the explanation!
If I have PVRTraceGUI running, the value is “1”. When I close it, the value switches back to “0”. I manually modified the value to “1” while not running PVRTraceGUI. Now, the value stays “1”, even if I start/exit PVRTraceGUI.
The only question left is how this could ever happen… (I never modifed some of these files, but I installed gEDBugger before, maybe it has something to do with it?)
So, yeah, it works again! Kudos to you!
Yes I’m not sure how that happened
I believe PVRTraceGUI simply reads the current value from the file at startup and then restores it on shutdown. I’ll check with the engineer responsible in case it is doing something more awkward.
Regardless the emulator should really be handling any invalid plist values more gracefully, so I’ll file a bug report. Thanks for your help!