Why is my simplest shader taking up the most processing power - swift

Question

So I ran a frame capture to see the performance. To my surprise it was my full screen rending things that were to blame. Take a look
Here are the two hogging functions. I have disabled the texture look up on the full screen texture to illustrate how ridiculous this is!
Program #3
Vert:
precision highp float;
attribute vec2 position;
uniform mat4 matrix;
void main()
{
gl_Position = matrix * vec4(position.xy, 0.0, 1.0);
}
Frag:
precision highp float;
uniform float alpha;
void main()
{
gl_FragColor = vec4(0.0, 0.0, 0.0, 1.0 - alpha);
}
Context:
//**Set up data
glUseProgram(shade_black.progId)
glBindBuffer(GLenum(GL_ARRAY_BUFFER), black_buffer) //Bind the coordinates
//**Pass in coordinates
let aTexCoordLoc = GLuint(black_attribute_position)
glEnableVertexAttribArray(aTexCoordLoc);
glVertexAttribPointer(aTexCoordLoc, 2, GLenum(GL_FLOAT), GLboolean(GL_FALSE), 0, BUFFER_OFFSET(0)) //Send to shader
//**Pass in uniforms
glUniformMatrix4fv(black_uniform_ortho, 1, GLboolean(GL_FALSE), &orthographicMatrix) //Pass matrix
glUniform1f(black_unifrom_alpha, 0.95) //Pass alpha
counter += timedo
//**Draw (instanced)
//The number 3 is actually variable but for this purpose I set it flat out
glDrawArraysInstanced(GLenum(GL_TRIANGLE_STRIP), 0, 4, 3 )// GLsizei(timedo)) //Draw it
//**Clean up
glBindBuffer(GLenum(GL_ARRAY_BUFFER), 0) //Clean up
glBindBuffer(GLenum(GL_ARRAY_BUFFER), 0)
Program #2
Vert:
precision highp float;
attribute vec4 data;
uniform mat4 matrix;
uniform float alpha;
varying vec2 v_texcoord;
varying float o_alpha;
void main()
{
gl_Position = matrix * vec4(data.xy, 0.0, 1.0);
v_texcoord = data.zw;
o_alpha = alpha;
}
Frag:
precision highp float;
uniform sampler2D s_texture;
varying float o_alpha;
varying vec2 v_texcoord;
void main()
{
//vec4 color = texture2D(s_texture, v_texcoord);
gl_FragColor = vec4(1.0);
//This line below is what it should be, but I wanted to isolate the issue, the picture results are from setting it to white.
//gl_FragColor = vec4(color.rgb, step(0.4, color.a ) * (color.a - o_alpha));
}
Context:
func drawTexture(texture: FBO, alpha: GLfloat)
{
//**Start up
//DONE EARLIER
//**Pass in vertices
glBindBuffer(GLenum(GL_ARRAY_BUFFER), textures_buffer)
let aTexCoordLoc = GLuint(textures_attribute_data)
glEnableVertexAttribArray(aTexCoordLoc);
glVertexAttribPointer(aTexCoordLoc, 4, GLenum(GL_FLOAT), GLboolean(GL_FALSE), 0, BUFFER_OFFSET(0)) //Tell gpu where
//**Pass in uniforms
glUniform1i(textures_uniform_texture, 0)
glUniformMatrix4fv(textures_uniform_matrix, 1, GLboolean(GL_FALSE), &orthographicMatrix)
glUniform1f(textures_uniform_alpha, alpha)
//**Texture
glBindTexture(GLenum(GL_TEXTURE_2D), texture.texture)
//**Draw
glDrawArrays(GLenum(GL_TRIANGLE_STRIP), 0, 4)
//**Clean up
glBindTexture(GLenum(GL_TEXTURE_2D), 0)
glBindBuffer(GLenum(GL_ARRAY_BUFFER), 0)
}
For the others you can at least se their draw call, but they aren't causing much damage.
What on earth is going on to cause the most complicated shaders to only be responsible for less then 1% of the latency?
NOTE: Both of these shaders use a VBO that is created and filled at the start of the app.

Answer 1

It does look kind of surprising. Here's how I'd try to make sense of those figures (assuming those times are GPU timings for those render calls):
Fill-rate is everything on mobile. Even running a simple pixel shader over 3 million pixels or so (iPad retina) is going to be an expensive task, and you shouldn't be too surprised that it's more expensive than a large number of much smaller particles. Your percentages are going to add up to 100%, so if all your other stuff is just a few hundred vertices and fills a few thousand pixels, you shouldn't be surprised if the full-screen stuff is huge relative to that. It also says '5ms', which is tempting to think of as an absolute figure, but bear in mind that the CPU and GPU automatically start running slower when there's not much work to do, so even a millisecond timing can be very misleading when the device is mostly idle.
Do you have a glClear at the start of the frame? If not, then you can pay a pretty high price because the first thing the GPU must do when it processes a tile is load in the old contents. With a glClear at the start of your rendering, it knows it needn't bother loading old contents. Maybe you're seeing that price on your first full-screen pass if you don't have a glClear.