Use getShaderPrecisionFormat to check if highp precision is available in shader

[dmnsgn]

API could default to highp and be overrided manually, but check getShaderPrecisionFormat in every case:

renderer = createRenderer(opts)
const renderer = createRendererer({
  ...,
 precision: 'highp' // 'lowp' || 'mediump'
})

[vorg]

I think in the context of pex-renderer it’s safe to assume such device would not be able to run it anyway.

[vorg]

@dmnsgn I'm re-opening this issue due to iPhoneX problems with normal mapping #123

[dmnsgn]

PR in progress: #125

[vorg]

From Unity docs: Precision, Hardware Support and Performance

One complication of float/half/fixed data type usage is that PC GPUs are always high precision. That is, for all the PC (Windows/Mac/Linux) GPUs, it does not matter whether you write float, half or fixed data types in your shaders. They always compute everything in full 32-bit floating point precision.

That explains no performance gains when i tested "half-float pipeline" (and all mediump qulifiers you removed in #125)

The half and fixed types only become relevant when targeting mobile GPUs, where these types primarily exist for power (and sometimes performance) constraints. Keep in mind that you need to test your shaders on mobile to see whether or not you are running into precision/numerical issues.

I did run into issues many times that's why i tried to avoid it.

Using lower precision can often be faster, either due to improved GPU register allocation, or due to special “fast path” execution units for certain lower-precision math operations. Even when there’s no raw performance advantage, using lower precision often uses less power on the GPU, leading to better battery life.

Now that's interesting.

A general rule of thumb is to start with half precision for everything except positions and texture coordinates. Only increase precision if half precision is not enough for some parts of the computation.

[vorg]

In that context this comment from Filament docs makes more sense

This solution solves the storage problem but requires intermediate computations to be performed with single precision floats. We would instead prefer to perform all (or at least most) of the lighting work using half precision floats instead. Doing so can greatly improve performance and power usage, particularly on mobile devices. Half precision floats are however ill-suited for this kind of work as common illuminance and luminance values (for the sun for instance) can exceed their range. The solution is to simply pre-expose the lights themselves instead of the result of the lighting pass. This can be done efficiently on the CPU if updating a light's constant buffer is cheap. This can also be done on the GPU, as shown in listing 25.

[vorg]

From Apple's [OpenGL ES Programming Guide] (now deprecated of course):

When in doubt, default to high precision.
Colors in the 0.0 to 1.0 range can usually be represented using low precision variables.
Position data should usually be stored as high precision.
Normals and vectors used in lighting calculations can usually be stored as medium precision.
After reducing precision, retest your app to ensure that the results are what you expect.

[vorg]

ThreeJS work "towards mediump"

• Textures Rendered as Black on (some?) devices with Android 7+ lot's of horror stories as it seem that they are not mediump ready
• Materials: Consider to use mediump for all shaders more up to date discussion

I kind of proves my earlier comment that just supporting mediump won't magically fix the devices not having highp and would require setting mobile support as a serious goal with serious mobile testing.

[dmnsgn]

It probably won't fixes all bugs magically but at least provide support for other precisions which could be a good start before planning anything else.