Yes.
No.
Two things. First, as has been pointed out, you don't refer to triangles by an index, but by the coordinate positions of the triangles. Lemme give you an example.
Check out the rotating triangle example on this page. I'll copy the code here.
Code:
attribute vec4 vertexPosition;
uniform mat4 modelMatrix;
uniform mat4 viewMatrix;
uniform mat4 projectionMatrix;
uniform float time;
const float PI = 3.1415926535897932384626433832795; //check out the number of digits of pie
mat4 rotateZ(float angle) {
mat4 rotationMatrix;
rotationMatrix[0] = vec4(cos(angle), sin(angle), 0, 0);
rotationMatrix[1] = vec4(-sin(angle), cos(angle), 0, 0);
rotationMatrix[2] = vec4(0, 0, 1, 0);
rotationMatrix[3] = vec4(0, 0, 0, 1);
return rotationMatrix;
}
void main() {
float angleRadians = (time / 30.0) * PI / 180.0; //And check out this math
mat4 rotatedModelMatrix = rotateZ(angleRadians) * modelMatrix;
gl_Position = projectionMatrix * viewMatrix * rotatedModelMatrix * vertexPosition;
}
All these types are effectively 16-bit. Don't worry too much about how the details, but check the two lines I've commented. What you'll see is that we're dealing with irrational numbers. Pi has digits past the zero up to infinity.
So the math with pi will never be
exactly accurate because we don't have all infinite digits of pi. We could make it less accurate by shortening it to just 3.14. Or just 3. We'd start to notice, though, if we made it that short. The triangle wouldn't rotate at a single smooth pace because we'd introduce errors that were greater than a pixel.
Does that make sense? When you start multiplying and dividing floating point numbers, the number of digits is unpredictable, or even infinite. That's why we call it X-bits of
precision because we're saying "how close - how precise - is this math, because there
will be inaccuracies." In this case, moving the triangle generates errors/inaccuracies smaller than a pixel, so it's not visible on a physical screen.
Second thing to point out, shaders don't just manipulate the triangles. A vertex shader is just one kind of shader. GPUs are pipelined, with rendering happening one phase at a time, and shaders only able to manipulate the data at that phase. So after vertex shaders, you have pixel shaders, which are manipulating
color data.
Here is an example.
Just like with the vertex shader, there will be errors, but the question is, are those errors visible on screen or to the human eye. The higher the precision, the more colors you can represent. Lower precision can create effects like color banding.
Here you can see how 8-bit color only gives us enough shades of reds for a very blocky gradient, but 24-bit color gives us enough for a very smooth transition from red to black. Practically speaking, actual pixel shaders will use more complex color representations, and have to deal with errors accumulating across shaders - both of which can make the effects of precision less than obvious.
But the other thing about FP32 - it's twice as much memory. Which not only doubles how much RAM your assets take up, but makes copying the objects around slower. Remember your limited memory bus - even if FP32 is just as fast as FP16 for all operations on the cores, it still has huge performance implications.
TL;DR: Precision is just that - how precise your numbers are. FP16 is so much faster than FP32, that it is the default choice. The consequences of precision aren't that functionality won't work, so much as will look less good.