Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
On demand rendering and true multithread luau — Gideros Forum
  • Home
    • ›

    On demand rendering and true multithread luau

    hgy29hgy29 Maintainer
    in Roadmap
    I am working on the two completely unrelated features mentionned in the subject.

    First one will allow to tell Gideros to render new frames only when contents have changed (if it can figure out), thus saving battery life in apps with mostly static content. I have it working on QT and HTML so far, and it seems to work really well: for my pro apps CPU usage has been reduced by 20% and GPU usage by 99%!

    Second feature I am working on, is trying to make luau thread safe, so that Core.asyncCall routines could be turned to real threads if asked. Of course most Gideros API is not thread safe, but a few calls could be made thread safe easily, and pure lua routines could be executed in another core without issues. But making luau thread safe isn't easy at all, so one step at a time :)

    Likes: MoKaLux, keszegh, SinisterSoft, vitalitymobile

    +1 -1 (+4 / -0 )Share on Facebook

    Comments

    • keszeghkeszegh Member
      the first one seems especially useful for everybody.

      Likes: MoKaLux, SinisterSoft

      Longtitle Productions, creator of
      Fragmenter - animated loop machine and IKONOMIKON - the memory game
      +1 -1 (+2 / -0 )Share on Facebook
    • PaulRPaulR Member, Maintainer
      Nice, can't argue with a 99% reduction in GPU! Although for us mortals who don't write custom shaders for everything we can probably expect a more modest 90%. :smile:

      From the sounds of the preview thread on the Roblox forum about threading it seems that their Actors are coroutines that are also distributed across cores in separate Luau states as required. It will be interesting to see what tactics you are taking! B)
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      According to LuaU main devs, LuaU will never be multithreaded/parallel. Actors are spawn in separate VM and talks to other parts of the project through a messaging system. That’s not what I am after, I’d like to run two parallel threads in the same VM, thus sharing all variables and environment…

      Likes: SinisterSoft

      +1 -1 (+1 / -0 )Share on Facebook
    • PaulRPaulR Member, Maintainer
      That does sound tricky. On the note of taming garbage collectors, I watched a presentation with one of the Luau devs (Russian guy, sort of bald, can't remember his name sorry) where he was talking about a revamp of the Luau GC happening at some point in the near(ish) future.
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      Yes, the trickiest part will be to avoid two GC task running in parallel, without adding mutexes everywhere
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      Quick update: I have on demand rendering working on IOS and Android too now, which saves a lot of battery!
      I also managed to run multiple Lua threads truly in parallel, but it is unstable currently (only works in debug compilation, crashes instantly when compiled with optimizations). I choose to suspend GC completely while parallel threads are running, this avoids a lot of locks/mutexes. GC will run when only main thread remains or parallel threads are suspended or waiting. That seems a fair trade of.

      Likes: SinisterSoft

      +1 -1 (+1 / -0 )Share on Facebook
    • PaulRPaulR Member, Maintainer
      Good work! This opens Gideros up to running normal apps, without the X fps re-render overhead.

      Re the threading, that seems like the way forward too. User threads could be expected to be GC-aware and periodically call some form of GC yield function that pauses thread execution until the main thread signals it to continue after it has safely run the GC.

      +1 -1Share on Facebook
    • SinisterSoftSinisterSoft Maintainer
      @hgy29 That's a really good idea. Maybe your thread changes could be submitted to regular Luau ? (for Roblox users)
      Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
      https://deluxepixel.com
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      Parallel threads no longer crash in release, I am progressing…

      Likes: SinisterSoft, PaulR, MoKaLux, vitalitymobile

      +1 -1 (+4 / -0 )Share on Facebook
    • hgy29hgy29 Maintainer
      I think I've got something usable. I did a few benchmarks and enabling threads come with a small penalty in single thread mode. This was expected but it doesn't seem that much.

      Here are a few figures showing the gain (or loss) relative to current single thread gideros:
      - Table fill: 1T=-2,85% 2T=38% 4T=47%
      - Prime number finding: 1T=1,81% 2T=46% 4T=67%
      - Pure math: 1T=-0,68% 2T=39% 4T=55%

      It is strange the one of the tests gave better results in single thread, that makes me think that my test procedure has some jitter depending on my PC workload.

      Likes: SinisterSoft, MoKaLux, vitalitymobile

      +1 -1 (+3 / -0 )Share on Facebook
    • SinisterSoftSinisterSoft Maintainer
      This is a great step forward. It would be good if it's possible to optimise away the penalty somehow.
      Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
      https://deluxepixel.com
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      SinisterSoft said:

      It would be good if it's possible to optimise away the penalty somehow.

      I already tried to reduce it as much as possible, but there is no way we can avoid it completely. Hopefully it is already compensated by the performance gain from latest LuaU update.

      Likes: SinisterSoft

      +1 -1 (+1 / -0 )Share on Facebook
    • vitalitymobilevitalitymobile Member
      @hgy29 I just come across this repository and see it has many stars

      https://github.com/oneapi-src/oneTBB

      Maybe it helps you with some ideas to continue the current work.
      Keep up the great work! Thank you so much for making Gideros better each day!

      Likes: MoKaLux, hgy29

      Coming soon
      +1 -1 (+2 / -0 )Share on Facebook
    • hgy29hgy29 Maintainer
      I think I am done with the first stage of parallel threading in Gideros, I'll build a 2022.9 soon with this new feature.
      I have added support for shared lua tables (tables usable concurrently by several threads), one have to call table.share(t) to make a table shared.
      I also added a Core.signal() call which create an object that can be used for thread synchronization. It exposes a wait() and a notify() call.

      BUT, most Gideros API isn't thread safe, and no opengl call can be made outside main thread. We will need to check which calls are safe and which aren't, and possibly make some of them safe.

      Likes: SinisterSoft

      +1 -1 (+1 / -0 )Share on Facebook
    • keszeghkeszegh Member
      with this will i be able to load a texture file without stalling the app main thread?
      Longtitle Productions, creator of
      Fragmenter - animated loop machine and IKONOMIKON - the memory game
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      keszegh said:

      with this will i be able to load a texture file without stalling the app main thread?

      Precisely not, since texture loading involves opengl. But there is already a way to separate the file loading and decoding part from the texture uploading to opengl which Texture.loadAsync which spawns a thread internally if possible

      Likes: keszegh

      +1 -1 (+1 / -0 )Share on Facebook
    Sign In or Register to comment.