Why there is frame buffer copy done each frame?

I have noticed that Unity makes a copy of framebuffer each frame. It uses a very simple shader blitting the texture, but being fullscreen (e.g. 1920x1200 on Acer Iconia Tab 8) it costs 2.2 ms of GPU time.

The source of VS:

attributemediumpvec4 vertex;
varyingmediumpvec2 texCoord;
void main()
{
gl_Position = vec4(vertex.xy, 0.0, 1.0);
texCoord = vertex.zw;
}

Source of FS:

varyingmediumpvec2 texCoord;
uniformsampler2D tex;
void main()
{
gl_FragColor = vec4(texture2D(tex, texCoord).rgb, 1.0);
}

Is this necessary? Are there some project settings that force this behavior?

 

Something to do with deferred lighting path versus the forward, where the various buffers have to be combined and output?

 

Forgot to mention, it's forward rendering and Unity 5. To rule out problems with scene setup - I tested and it happens with an empty scene too. While shadows are enabled - 3 RTs without shadows 2RTs. Last one is simply copying the previous one.

The main problem is that shader does nothing just eats GPU cycles. I am not sure where to look for solution to skip this pass somehow - 2.2ms is a lot of time which I'd like to use for something else.

 

It could be that it's blitting to the actual back-buffer, however why it wouldn't be writing to that to start with I don't know.
Unless ofc you have HDR enabled?
(HDR would force a non-backbuffer intermediate texture, and that blit pass is then going from the HDR texture to the non-HDR backbuffer).
It could also be if you have linear mode enabled, as swap buffers are always (as far as I know) sRGB, it would once again need to keep a non-swapbuffer render texture as an intermediate. (Linear mode would blend differently, so even without post process effects it would make a difference.)

 

Just checked - no HDR, and there's no Linear for android, I also tried 32 bit Display buffer on/off.

 

Android, so can't use RenderDoc either.
Is this actually for a build or in the editor? (If in the editor and it's attempting to simulate the android rendering that might be the cause?)

 

Standalone build does not have this problem - it would be noticed already. Could be some special case for Android x86 or particular GPU/driver.

 

I was referring to an android build, but from your response assume your profiling that already.

 

Yes, and I'm profiling it on hardware (1920x1200 on Acer Iconia Tab 8) with Intel tools.

 

On prestigio multipad 4, situation is the same. But this second render target also gets glClear, followed by the copy of main render target. Unfortunately I can't get GPU timings for the operations on Prestigio, just the fact that they exist and what shaders are used. Anyway, full screen blit should be quite heavy. So it is not Android x86 specific.

I'm profiling with Intel's INDE:
https://software.intel.com/en-us/intel-inde

Anyone experiencing similar behavior?