High memory usage / Unresponsive touchdesigner on shader build

[edeetee]

When making a change to my raytk network, my memory climbs as high as 10GB. This memory goes up and down (garbage collection probably) for a few minutes before TD returns from being unresponsive.

Some solutions that would help:

• A way to monitor the shader build process so that I can optimise myself
• General optimisations & reusing shader snippets that have already been generated before
• Documentation on how to avoid this problem

[edeetee]

If someone has an idea what the best course of action is, I could have a go trying to remedy it - already tried making some changes to the source.

[t3kt]

The memory issue is not something that I've encountered before. Could you upload a project that demonstrates the issue? It would also be useful to know:

• GPU
• GPU driver version
• Operating System
• TouchDesigner version

There is going to be lag when the GPU driver compiles the shader. That happens any time something causes the generated code to change. As far as I am aware, GPU drivers do not provide a way to compile parts of the shader for reuse. We don't really have any control over that process, without being able to modify the internals of TouchDesigner or creating a replacement for the GLSL TOP. If you know of any alternatives, that would be really useful.

The more complex the generated shader, the longer it takes to compile. There are some operators that involve a lot of additional code (like waveletNoiseField), so avoiding those would help reduce the time.

Things that typically cause recompiles:

• Wiring changes in the network.
• Changes to most menu parameters.
  • Again the best option is to avoid changing them.
  • That isn't ideal, but there is a lot of infrastructure built around many of them that requires compile-time evaluation.
• Changes to certain optimized parameters like anti-aliasing.

The best approach is to avoid making those kinds of changes in the network while in situations where stalling would be problematic (e.g. live performance, recording output, etc). If you're switching between parts of the network, you can use a Switch ROP, which lets you switch operators without requiring a recompile. Menu parameters can be a bit harder to avoid. In certain cases it may be possible to redesign them to use runtime-based evaluation. But in other cases the settings in one operator result in changes to the behavior of other operators throughout the network.

[edeetee]

Here is pretty much all I have with raytk at the moment. For me, any network change causes 1+ minutes of unresponsive program. The network is composed of a couple of texture manipulation things for UV inputs and for calculating a normalized distance for some color effects. The rest is shaping and materials. slowShaderCompileTest.zip

RAM: 16GB CPU: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz 2.21 GHz GPU: RTX 2070 MaxQ (Laptop)

• 8GB DDR6
• Driver version 466.77 OS: 64bit Windows 10

[edeetee]

Through trail and error, It seems like the generalised geodesic sdfs are causing some of the build freezing. Investigating more

[t3kt]

First of all, the result looks amazing.

I am able to reproduce the stalling issue. When I was saying some stalling is to be expected, it's generally in the range of a few seconds. So this is definitely outside the norm.

This is by far the most complex RayTK network I've ever seen. Some stats:

• 67 active ROPs
• 202 parameters
• 8 texture sources (2 of which are derived from CHOPs)
• 3127 lines of generated shader code, not including static libraries
• 201 generated macros

For comparison, one of my most complex scenes uses 20 operators.

As a sort-of workaround, while making changes to the network, you could disable cooking on the renderer, which should stop it from recompiling for each change.

But more importantly, there are some ways you can change your network design to improve performance (both runtime and compile). Things that are good practices for TouchDesigner in general don't always work well with the toolkit.

There is a cost for every ROP in the network. While that's technically true for everything in TD (except nulls), there's an advanced system of dependency evaluation that means that only things that are being used have much runtime cost. In RayTK, an entire render graph is compiled into a shader and run in a single TOP.

Some suggestions:

• Anything that you aren't using, either disconnect it or switch off the "Enable" parameter, which basically bypasses the operator entirely. Both of those things will trigger recompiles though.
• Use fields only when they are doing something that wouldn't be possible otherwise. For example, sphereSdf has a Radius Field input. It's useful in cases like iteration, where the radius varies for different repetitions of the shape. If the input is just a constantField, then that could just be based on the "Radius" parameter on the sphereSdf. There are rarely cases where it makes sense to connect constantField to that sort of input. The field inputs almost always have equivalent parameters, and if you can directly use those parameters instead, do so. This is a major factor in the issues you've been encountering. There are a ton of constantFields.
• Calculations that can reasonably be done outside of the ROP network should be done with CHOPs/etc.
• Since you are comfortable using customOp (which is great, and rarely used...), you may be able to condense some things from a few ROPs into a single customOp. That reduces some of the overhead.
• ROP reuse doesn't work the way the rest of TD works.
  • Example: a noiseField whose output is connected to 4 different rescaleField operators, which are then combined using combineFields.
  • In TD normally, that noiseField (and any inputs) would run once, then four things would use the result.
  • In RayTK, what that means is that noiseField (and all inputs) run 4 times.
  • The rescaleField1 and rescaleField2 operators produce code like this, where each one calls noiseField:

    float rescaleField1(p, ctx) {
    float val = noiseField1(p, ctx);
    return applyScaling(val, rescaleField1_Inputlow1, rescaleField1_Inputlow2, ...);
    }
    float rescaleField2(p, ctx) {
    float val = noiseField1(p, ctx);
    return applyScaling(val, rescaleField2_Inputlow1, rescaleField2_Inputlow2, ...);
    }

The reasons for these things are complicated, but if you're interested I'd be happy to discuss it and see if you have any ideas on how to improve things.

[edeetee]

Thanks for the compliment. I think you've build an impressive library here too :)

The reason the network is so large is that I was doing my own sdf data generation (depth, position, mat type), then doing all of the material processing in tops. This gave me pretty shoddy performance, I'm guessing due to how TOPS use textures instead of optimising into a shader. I came across your library and decided to see if I would get performance improvements. I definitely got performance improvements but now I'm getting these problems.

The most utility I get from your library is:

• Easier to prototype shader inputs
• Easier to prototype with complex sdf functions I don't understand with
• Ability to actually debug shader code

I think it's getting to the point of complexity where using a shader building library may be helpful. I can write shader code that reuses inputs in the right context so there must be some way to generate it. Probably more type info tracking or something to decide wether or not a value can be reused.

I think from here I'll try reduce my field usage and see if my assumption of reusing input operators allows me to simplify other things.