Tarik

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:

comment

number

toggle

jit.fpsgui

jit.gl.texture

gate

message

jit.gl.videoplane

jit.gl.slab

inlet

outlet

qmetro

jit.window

jit.gl.render

jit.gl.gridshape

route

jit.gl.node

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)

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:

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 v

using-slabs-for-varying-incoming-texture-sizes-and-types-is-slow

and here's another weird thing that's most likely related:

if I send a "dim 1920 1080" command to a jit.gl.slab with @adapt on 1, it will take a massive hit in speed, even if the incoming texture is precisely 1920x1080 (so adapt 1 shouldn't be doing anything!)

and here's another weird thing that's most likely related:
if I send a "dim 1920 1080" command to a jit.gl.slab with @adapt on 1, it will take a massive hit in speed, even if the incoming texture is precisely 1920x1080 (so adapt 1 shouldn't be doing anything!)

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.

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.

Yes, the uzi part is really the problem, without it I go from 12fps to 430fps

Yes, the uzi part is really the problem,  without it I go from 12fps to 430fps

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.

I'm pretty sure Tarik's patch is simply for demonstrating the issue. 

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?

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!

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

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


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