Using slabs for varying incoming texture sizes and types is slow.


    Nov 18 2020 | 7:05 pm
    Hello!
    I'm trying to use a fixed pipeline of slabs, and want it to process textures of different sizes. This is possible and works, but is very slow, as demonstrated here:
    The same happens if I try to change types (from char to float for instance).
    Does anybody have an idea how I can speed this up so I can throw different types of textures in there without worry?
    EDIT: this is NOT the case on my Mac (Catalina, Intel Iris Plus Graphics 655), just on my PC (windows 10, GTX 2080 Ti)
    thanks! -Tarik

    • Nov 23 2020 | 6:35 pm
      Why don't you just set the size of the node texture instead of changing the size of the jit.gl.slab? If you want to do this only with 2 chains then I would manually create two slab chains with different textures input instead of using that convoluted system.
    • Nov 23 2020 | 7:01 pm
      Yes, the uzi part is really the problem, without it I go from 12fps to 430fps
    • Nov 23 2020 | 8:39 pm
      I'm pretty sure Tarik's patch is simply for demonstrating the issue.
      unfortunately I don't have a lot to say about it. changing dims and changing type requires rebuilding the texture, which is an expensive process. I don't think there's much we can do, as this is driver level. So my suggestion would be to catch any dimension changes as far up the chain as possible, and perform a resize to match the chain dims there.
    • Nov 24 2020 | 6:36 pm
      Thanks all & thanks Rob!
      Yes, my patches here are indeed meant just to demonstrate the issue. So, yes this issue is simply what it is, and I noticed that also on Mac this rebuilding costs time, it just seems to be less severe than on windows. But okay, accepted.
      So I decided to build several chains in stead, one for each resolution/type combination that I want to use. To my surprise I saw that just the existence of these extra slabs in my patch would slow down rendering. Even if they're disabled and with automatic 0. Also this is only properly noticeable on windows!
      My gpu seems to have plenty of memory left, so I don't think that's the issue? Any clue what is it that these idle slabs are doing to slow down the rendering?
      Here's a patch demonstrating the issue:
    • Nov 24 2020 | 8:55 pm
      Oh, sorry, I looked this too quickly.. The second patch is very clear. Interesting, this slab slow down, I'm also curious to know. I didn't really noticed it in my patches, but i have regularily slab and gl.pix that I enable/disable (not that much thought) and it's good to know if it impacts the performance