I'm using Mali 400mp for doing some mathmetic computing.But the result is not satisfying.
In my program, I put a float array A by using gluniforlfv() into the shader,and put a Image Texture B by using glTexImage2D() into the shader,use the values in A and values in B to do mathmatic computing.
I use Mali's parameter to se OpenGL ES2.0 environment:
protected int redSize = 8;
protected int greenSize = 8;
protected int blueSize = 8;
protected int alphaSize = 8;
protected int depthSize = 16;
protected int sampleSize = 4;
protected int stencilSize = 0;
The txture parameter is:
........
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, texwidth, texheight, 0, GL_RGBA, GL_UNSIGNED_BYTE, Data);
The problem is :
Firstly, when I use gluniformlfv() to put a float array into the shader, the value in shader for computing is not the same as its real value.For example, if the value is 0.123456, however, in shader, the value is bigger or smaller in fact .So as other values.
Secondly, When I doing some computing in shader, it seems the result is not right for addition ,division etc. The result has some difference with the idealized mathmatic computing. I don't know why.
Hi Tim,
Thank you for your reply.I do these calculations in the fragment shader.Your reply is very useful.Your last sentense means that if I give the float array to vertex shader and then pass to fragment shader the result will be better,isn't it? And how about the result of the calculation in fragment shaders, for some calculations the difference is at the first decimal.For example, if the result should be 128.3567,the fragment shader is 128.2436,however.
Thank you.
Best wishes.
Autman
Hi Autman,
Floats passed from vertex to fragment shader will keep 24 bits of precision as long as you don't do any further calculations on them using them only for a lookup into a texture. As soon as you do any calculation on them within the fragment shader the precision will drop to FP16.
> For example, if the result should be 128.3567,the fragment shader is 128.2436,however.
This would be expected. An FP16 value can represent a value of approximately 3 decimal places... so in this case these three are taken up by "128". If you could normalise all the values so the maximum value was 1 then you could count on the three places to the right of the decimal point being more or less accurate.
I hope that helps,
Tim