Asynchronous Resource Loading

2»

Comments

  • edited July 2015
    iarwain wrote:
    I'm curious to know why the load counter starts that high instead of starting at 0.
    Also, what is the log result on desktop, to compare?

    I did notice that. Desktop logs always start at 0. I theorised that perhaps Android was slower to initialise and that textures had already queued.

    In the case of this log where the texture count start at 7, perhaps it misses out on some CREATE events, throwing some kind of count out. Just a thought.

    I'll get a desktop version of the log.
  • edited July 2015
    Attached is a desktop version + create names.

    Won't have access to an android build until this evening to put creation names in, but this should help compare. https://forum.orx-project.org/uploads/legacy/fbfiles/files/texture_desktop.txt
  • edited July 2015
    On my side, I checked the workflow in synchronous mode, but it was actually fine, I misread it this morning.
    I did fix the workflow when a texture decompression fails though, as before the load counter wouldn't be updated.
    Now the counter gets updated but no load event will be sent, an empty texture will be created and used in place of the faulty one, with a log explaining what happened. That was just as a FYI as I doubt it was your case anyway.

    One other thing to do on Android would be to add logs inside orxTexture.c everytime the load counter gets increased or decreased, as well as the texture name associated with the operation. That should give us all the visibility we need to understand what's going on.
  • edited July 2015
    iarwain wrote:
    add logs inside orxTexture.c everytime the load counter gets increased or decreased, as well as the texture name associated with the operation. That should give us all the visibility we need to understand what's going on.

    Yep, all done for desktop. See attached. https://forum.orx-project.org/uploads/legacy/fbfiles/files/desktop_textures_full_logging.txt
  • edited July 2015
    And here's the one for Android. I included lots of logging lines before and after, in case it helps. In this example, the count got down to 3 before seizing: https://forum.orx-project.org/uploads/legacy/fbfiles/files/android_textures_full_logging.txt
  • edited July 2015
    Thanks for the logs, Sausage!

    We're getting closer but I think we'll need logs inside the Android display plugin now. Mostly in the Decompress and DecompressCallback to see where things get stuck.
    Also could you try the latest version of orx, I made a couple of changes that could potentially help with any loading issue?
  • edited July 2015
    Hi sausage,

    So I didn't test your issue, but I never had this before...
    I've googled for the "GetBufferLock timed out" error and here is what I found.

    All the post about this error were reported on Tegra2 GPU (same as your), and they are all related to graphics stuffs (textures etc...)

    There may be different reasons for this error, but most probably a poorly designed locking mechanism for GPU memory allocation. Maybe GPU runs out of memory, and fails to unlock something, really hard to tell.

    My conclusions:
    Your device sucks (sorry. I know because I owned an Asus Transfromer with the same GPU. still works great as a doorstop).
    Issue is really low level and Orx probably wont be able to recover from this. ever.
  • edited July 2015
    iarwain wrote:
    Thanks for the logs, Sausage!

    We're getting closer but I think we'll need logs inside the Android display plugin now. Mostly in the Decompress and DecompressCallback to see where things get stuck.
    Also could you try the latest version of orx, I made a couple of changes that could potentially help with any loading issue?

    Yes will do. Starting shortly. I saw the commits from Lydesik and yourself today so I've been keen to try again.
  • edited July 2015
    lydesik wrote:

    My conclusions:
    Your device sucks (sorry. I know because I owned an Asus Transfromer with the same GPU. still works great as a doorstop).
    Issue is really low level and Orx probably wont be able to recover from this. ever.

    In a strange sort of way, this gives me some comfort. I just didn't like the idea that all these android devices would try my game and seize up half the time. But if it's down to just one GPU, I guess I can live with it and move on.

    Thing is... it doesn't have to be asynchronous loading. I'm happy with synchronous loading of textures, if it were possible.

    Anyway, I'll go through the motions with some new logs for the sake of completeness.
  • edited July 2015
    well, you can disable asynchronous texture loading with orxDisplay_SetTempTexture(orxNULL);

    but, my bet is it won't change a thing.
  • edited July 2015
    Guess I'll just have to take that on advice then. No point letting this issue hold up the title release.

    Tried adding logging to the plugin file but nothing logged. Too tired to see why tonight.
Sign In or Register to comment.