Opengl ES 2.0 if() more expensive than normal map!! O_o
Author
Hi
I was trying to optimize my phone app with some custom culling solution:
Lets suppose the light is on the camera, then make dot product with vertex
normal, if the result is less than .1 skip pixel shader, that's it, with this
all pixels behind or blackness to the camera are not rendered.
I'm doing this on the vertex shader, and pass it to the pixel as w component of one vector, on pixel shader:
if(vector.w < .1)
discard;
I expected more fps, but FAIL, i get less fps =/, my phone was giving 37fps avg,
with this i get 24fps avg, there is no difference using discard or drawing 0.0,
if i comment the if statement my fps counting raises to 37fps avg again, i just
don´t get it, can be more expensive that if than a normal map calculations ????
PD - There is no difference using a varying float instead, the same result.
thanks
Read the documentation about alpha tested or 'discard' and how it affects the rendering pipeline. Alpha test is notoriously bad on phones that use a hardware hidden surface removal prepass since the alpha test is programmable and circumvents that effort
I'm not sure what kind of optimization you're trying to get by skipping pixels that receive no light. Aren't you just going to end up poking a hole in the surface? Sounds like you really just want to render black, not a hole
I'm not sure what kind of optimization you're trying to get by skipping pixels that receive no light. Aren't you just going to end up poking a hole in the surface? Sounds like you really just want to render black, not a hole
Author
Hi thanks for reply,
I read about using discard, and tried to do something like this:
if(vector.w > .1)
{
//do normal rendering, lots of operations
}else
{
//draw black
}
I just want to ensure the less calculations available, no matter if
draw black or a hole(discard), but no matter, using discard or the
above code is the same result, make me think is about the if statement..
About the light, is not the light, is the dot product between the normal
vector and the Eye vector (eyepos - vecpos), this can proof that pixel
"illuminated" for the camera can be able to render, and pixel orthogonal
to the camera can be omitted without being noticed (small phone screen).
Is just my custom theory, and they work on PC, i get more fps =/ nor on the
phone :(
EDIT: I think is indeed the if statement, i did some tests and no matter
what i compare, a float comparison kill the frame rate more than other
calculations, i.e:
if(worldPos.z < -0.5)
// do something
Even that drops my frame rate =( i can´t believe it
[Edited by - _Camus_ on February 16, 2010 2:51:30 AM]
I read about using discard, and tried to do something like this:
if(vector.w > .1)
{
//do normal rendering, lots of operations
}else
{
//draw black
}
I just want to ensure the less calculations available, no matter if
draw black or a hole(discard), but no matter, using discard or the
above code is the same result, make me think is about the if statement..
About the light, is not the light, is the dot product between the normal
vector and the Eye vector (eyepos - vecpos), this can proof that pixel
"illuminated" for the camera can be able to render, and pixel orthogonal
to the camera can be omitted without being noticed (small phone screen).
Is just my custom theory, and they work on PC, i get more fps =/ nor on the
phone :(
EDIT: I think is indeed the if statement, i did some tests and no matter
what i compare, a float comparison kill the frame rate more than other
calculations, i.e:
if(worldPos.z < -0.5)
// do something
Even that drops my frame rate =( i can´t believe it
[Edited by - _Camus_ on February 16, 2010 2:51:30 AM]
So you're trying to do backface culling in the fragment shader?
Every GPU I know of does backface culling before the fragment shader, and the hidden surface removal hardware in phones does this as well, so, how did you measure that this was a bottleneck?
Plus, branching in a shader is typically very costly. Before you optimize you have to measure the bottlenecks and realize the costs for these things. Branching on the phone's gpu is probably one of the worst things you can do, if the GPU even supports branching. Did you look at the assembly generated? The shader compiler on the phone may have ended up executing *both* paths of the if statement and then choosing the result to use based on the condition in the if() statement.
If the GPU does support branching, it's likely only cheaper if large blocks of nearby pixels *all* follow the same path down the branch. Cutting edge GPUs have more advanced branching logic, but it's likely the phone's GPU has little or none.
Every GPU I know of does backface culling before the fragment shader, and the hidden surface removal hardware in phones does this as well, so, how did you measure that this was a bottleneck?
Plus, branching in a shader is typically very costly. Before you optimize you have to measure the bottlenecks and realize the costs for these things. Branching on the phone's gpu is probably one of the worst things you can do, if the GPU even supports branching. Did you look at the assembly generated? The shader compiler on the phone may have ended up executing *both* paths of the if statement and then choosing the result to use based on the condition in the if() statement.
If the GPU does support branching, it's likely only cheaper if large blocks of nearby pixels *all* follow the same path down the branch. Cutting edge GPUs have more advanced branching logic, but it's likely the phone's GPU has little or none.
Author
Yes is likely a custom culling, i already did it with:
glEnable(GL_CULL_FACE);
glCullFace(GL_BACK);
but i wasn't sure if triangles that are not back-faces, like
the shoulders and back of my model are rendered or not, and
in fact they are rendered, can be seen through the wireframe,
so, this was an extra cull.
Oh i see, you are right because i got the bottleneck with any
branch of any kind on the fragment or vertex program, and behave different on
the desktop GPU, i get more frames on my pc, but not in the phone,
it seems PowerVR SGX530 do not work well doing branching.
Thanks for your time man, i need to explore more solutions, i'm drawing
a model with normal map and specular highlights:
I get 37fps avg, is N900 at 800x480, diffuse and normal maps of 256x256.
glEnable(GL_CULL_FACE);
glCullFace(GL_BACK);
but i wasn't sure if triangles that are not back-faces, like
the shoulders and back of my model are rendered or not, and
in fact they are rendered, can be seen through the wireframe,
so, this was an extra cull.
Oh i see, you are right because i got the bottleneck with any
branch of any kind on the fragment or vertex program, and behave different on
the desktop GPU, i get more frames on my pc, but not in the phone,
it seems PowerVR SGX530 do not work well doing branching.
Thanks for your time man, i need to explore more solutions, i'm drawing
a model with normal map and specular highlights:
I get 37fps avg, is N900 at 800x480, diffuse and normal maps of 256x256.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
