Deadlock waiting on sync object.

This topic contains 6 replies, has 2 voices, and was last updated by  Carrado 3 months, 1 week ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #56225

    Carrado
    Member

    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.

    • This topic was modified 4 months, 3 weeks ago by  Carrado.
    #56229

    Shaun
    Member

    Hi 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?

    Thanks,
    Shaun

    • This reply was modified 4 months, 2 weeks ago by  Shaun.
    • This reply was modified 4 months, 2 weeks ago by  Shaun.
    • This reply was modified 4 months, 2 weeks ago by  Shaun.
    #56237

    Carrado
    Member

    Shaun,
    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.

    #56247

    Shaun
    Member

    Hi Carrado,

    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?

    Thanks,
    Shaun

    • This reply was modified 4 months, 2 weeks ago by  Shaun.
    #56253

    Carrado
    Member

    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.

    #56254

    Shaun
    Member

    Hi Carrado,

    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.

    Thanks,
    Shaun

    #56442

    Carrado
    Member

    SOLVED:
    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.
Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.