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.
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?
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.
Unfortunately I cannot reproduce the issue you are seeing on my machine, would it be possible for you to send over the binary that triggers the issue you are describing?
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.
[blockquote]binary is a little on the large side as there are a few pieces required for the app to run[/blockquote]
No problem, don’t worry about the binary then.
[blockquote] I’ll probably try to see if I can drum up a simple repo app[/blockquote]
If it is possible then that would be great.
[blockquote]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.[/blockquote]
No I wasn’t, I will try this out tomorrow and let you know if I can reproduce the problem.
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…