Rendertexture.SetActive and performance

Unity Engine
1

Hi,

I’m optimizing a cg-shader on my Android phone, and I’m really stumped about one thing…

If my frag shader is less than 20 ALU (measured in both Unity and in PVTShaderEditor), profiling shows that the complete rendering of my scene takes 1.5 ms on my Samsung Galaxy Nexus with a PowerVR SGX540 GPU.
If I zoom in to cover the entire screen with my mesh, it goes up by perhaps 1 extra ms per frame.

Rendertexture.SetActive stays at 0.0 ms, perfectly ok since I’m not using any image-effects or render-textures.

If I add some additional instructions to the frag part of the shader, something really weird happens.
At 20-25 ALU and above I get a massive hit in the profiler for Rendertexture.SetActive.

At 25 ALU it’s about 15-20 ms per frame, and at 35 ALU I end up at 30 ms or more.

Note that I know that it is the frag part that makes a difference, since it’s only when most of the screen is covered by my meshes that this happens.
If I zoom out, Rendertexture.SetActive takes less time depending on screen coverage, and if I remove instructions from the shader, it falls back to 0.0 ms.

Can someone (Aras perhaps?) please explain why Rendertexture.SetActive is taking this much time in the profiler?
And why the frametime doesn’t increase in a more linear fashion with added instructions but instead jumps up by atleast 10-ms at some magic number and only then increases more slowly with added complexity?

These kind of questions have been askes around the forum and web before, but I haven’t been able to find a single post that informs us users what is happening and why.

Right now I have to cut out parts of my functionality in my shaders to avoid the very visible lag that’s introduced when I happen to cross the boundary to the Rendertexture.SetActive mystic realm.

Best regards,

Anders

2

Bump… Any info is deeply appreciated.

3

All I can help you with is that when you get such high numbers for a call that should be very cheap (like RenderTexture.SetActive), the cause is usually somewhere else, for example pipeline stalls, or loading a big chunk of data.
I have no idea what’s the reason for your slowdown though. Is the ALU count the only thing that affects it, no matter the actual operation?

4

Hi Dolkar, and thanks a lot for taking your time!
Yes, I also think that the reason is something other than RenderTexture.SetActive, and that there simply isn’t a separate name for it in the profiler yet…

The only thing I’ve changed in the shader to make it use all that extra time is a few multiplies and smoothstep instead of step.
So there’s no extra shader inputs, no extra texture reads or anything like that.

If I would just know what’s causing it, perhaps I could side-step it without sacrificing quality.

/Anders

5

I’m quite puzzled as well… Does it happen only on that machine? If not, file a bug report.