- June 30, 2017 at 4:34 pm #56225
Updated to the latest emulator (R17) and whenever I do a client wait sync my application deadlocks. The code base have been tested on different platform and worked with the previous version of the emulator, so I’m confident that the codebase is NOT the issue. Reverting back to the previous version also confirms that the root cause is the latest version. One point to note is that the application uses 2 GLES context( one on the main thread and another in a separate thread ). Thanks for the ongoing support for the emulator as it seems like others have let theirs fall by the wayside.
July 3, 2017 at 11:00 am #56229
- This topic was modified 4 months, 3 weeks ago by Carrado.
By any chance do you know the specific wait function where the deadlock occurs i.e. eglClientWaitSync, glWaitSync, glClientWaitSync? Or does this issue occur for all wait sync functions?
Also which platform are you running this on; Windows, Mac, Linux and which architecture; x86 or x64?
Which version PVRVFrame other than 17.1 did you test your application with?
ShaunJuly 3, 2017 at 2:38 pm #56237
My apologies for being so vague. The deadlock occurs on a glClientWaitSync.
Host machine spec:
Windows 10 Pro 64-bit.
AMD RX 470, Crimson 17.1.1 drivers.
The version of PVRFrame I was running with was PVRVFrame 10.3 from the previous Native SDK install ( ie. the latest prior to the 2017 update. I wasn’t able to run in strict mode with the previous version either as it kept complaining about the host machine not meeting the requirement when it did, but was able to run in loose mode.July 4, 2017 at 3:34 pm #56247July 4, 2017 at 5:20 pm #56253
The binary is a little on the large side as there are a few pieces required for the app to run ( game ) so that may not be an option. I’ll probably try to see if I can drum up a simple repo app. Also were you testing this with multiple GLES context ? The application as a context on the main thread and another context on a loader thread.July 4, 2017 at 5:29 pm #56254
binary is a little on the large side as there are a few pieces required for the app to run
No problem, don’t worry about the binary then.
I’ll probably try to see if I can drum up a simple repo app
If it is possible then that would be great.
Also were you testing this with multiple GLES context ? The application as a context on the main thread and another context on a loader thread.
No I wasn’t, I will try this out tomorrow and let you know if I can reproduce the problem.
ShaunAugust 15, 2017 at 4:52 am #56442
The issue was not with the emulator, but within my codebase. The underlying issue has to do with which context created the sync object and the context in which the wait occurs. The particular behavior is described here : //https://www.khronos.org/opengl/wiki/Sync_Object. I’m somewhat concerned as all other drivers this was tested on allowed this errant behavior, until now..
1 user thanked author for this post.