Why fragment shader is faster than just rendering texture?

Question

I checked something and I got weird result about performance with C++ & OpenGL & GLSL.

In the first program I drew pixels to texture with fragment shader and then render the texture. The texture's mag\\min was GL_NEAREST .

In the second program I took the fragment shader and rendered directly to the screen.

Why the second program is faster? Isn't rendering texture faster instead of repeating the same action?

It's like taking a video of AAA game and then show it on the same computer and get lower FPS with the video.

The fragment shader is:

uniform int mx,my;

void main(void) {
    vec2 p=gl_FragCoord.xy;
    p-=vec2(mx,my);
    if (p.x<0.0)
        p.x=-p.x;
    if (p.y<0.0)
        p.y=-p.y;
    float dis=sqrt(p.x*p.x+p.y*p.y);
    dis+=(abs(p.x)+abs(p.y))-(abs(p.x)-abs(p.y));
    p.x/=dis;
    p.y/=dis;
    gl_FragColor=vec4(p.x,p.y,0.0,1.0);
}

Answer 1

As usual with performance questions, about the only way to be really certain would be to use a profiler.

That said, my guess would be that this is mostly a question of processing bandwidth versus memory bandwidth. To render a texture, the processor has to read data from one part of memory, and write that same data back to another part of memory.

To directly render from the shader, the processor only has to write the output to memory, but doesn't have to read data in from memory.

Therefore, it's a question of which is faster: reading that particular data from memory, or generating it with the processing units? The math in your shader is pretty simple (essentially the only part that's at all complex is the sqrt ) -- so at least with your particular hardware, it appears that it's a little faster to compute the result than read it from memory (at least given the other memory accesses going on at the same time, etc.)

Note that the two (shader vs. texture) have quite different characteristics. Reading a texture is going to be nearly constant speed, regardless of how simple or complex of computation was involved in creating it. Not to state the obvious, but a shader is going to run fast if the computation is simple, but slow down (potentially a lot) if the computation as the computation gets complex. In the AAA games you mention, it's fair to guess that at least some of the shaders use complex enough calculations that they'll almost certainly be slower than a texture read. At the opposite extreme a really trivial shader (eg, one that just passes the fragment color through from input to output) is probably quite a lot faster than reading from a texture.