[Unityshader] Optimization on the shader

Original link: http://game.ceeger.com/Components/SL-ShaderPerformance.html

Compute only things that need; Anything that was not actually needed can be eliminated. For example, supporting per-material-A-nice-to-make-shader more flexible, but if-you-always-leave that color set To white then it's useless computations performed for each vertex or pixel rendered on screen.

Just calculate the parts you need and eliminate any unnecessary parts. For example, it is a good thing to support shader-by-material, and doing so can make shaders more flexible and easy to use, but if you always set the color to white, the per-vertex or pixel-by-point calculations will be useless.

Another thing to keep on mind is frequency of computations. Usually there is many more pixels rendered (hence their pixel shaders executed) than there is vertices (vertex shader ex Ecutions); And more vertices than objects being rendered. So generally if you can, move computations out of pixel shader into the vertex shader; Or out of shaders completely and set the values once from a script.

Another thing to be aware of is the frequency of calculations. Generally speaking, the number of pixels you need to render (pixel shader execution) is more than the number of vertices you need to render (the vertex shader executes), and the number of vertices you need to render is more than the number of models. So, in general, whenever possible, move the calculated amount from the pixel shader to the vertex shader, or completely remove it from the shader and assign a value from the script. Less Generic Surface Shaders

Surface Shaders is great for writing Shaders this interact with lighting. However, their default options is tuned for ' general case '. In many cases, you can tweak them to make shaders run faster or at least be smaller:

Surface shaders are ideal for writing lighting-related shaders. However, for the general case, their default options are optimized. In many cases, you can tweak them to make them run faster, or even if they don't speed up, you can make them smaller: approxview directive for shaders this use view direction i.e. specular View direction be normalized Per-vertex instead of per-pixel. This was approximate, but often good enough.
Approxview: A shader that directs the use of line-of-sight direction (such as specular reflection) to turn the line of sight one vertex at a point rather than pixels. This is approximate method, but often can get good enough effect. Halfasview for specular shader types is even faster. Half-vector (halfway between lighting direction and view vector) would be computed and normalized per vertex, and lighting function would already receive half-vector as a parameter instead of view vector.
Halfasview: For mirror shader types, even faster. Half vectors (the light source direction vector and half of the line of sight direction vectors plus and after) are computed and normalized by vertex, while the light calculation function uses the half vector as a parameter instead of the line of sight direction vectors. Noforwardadd would make a shader fully support only one directional light in Forward rendering. The rest of the lights can still has an effect as per-vertex lights or spherical harmonics. This was great to make shader smaller and make sure it always renders on one pass, even with multiple lights present.
Noforwardadd will fully support a forward rendering shader with only one directional light. The remaining light sources can still be used as each vertex officer or spherical harmonic light source to influence objects in the scene. This makes it very easy to make the shader smaller and ensures that it is always rendered once, even if there are multiple lights in the scene. Noambient would disable ambient lighting and spherical harmonics lights on a shader. This can is slightly faster.
The noambient will turn off the effects of ambient and spherical harmonic lights in the shader. This can speed up the shader a little bit.Precision of computations calculation accuracy

When writing shaders in CG/HLSL, there is three basic number types:float, half and fixed (as well as vector & matrix Variants of them, e.g. Half3 and float4x4):

When using CG/HLSL to write shaders, there are mainly three basic data types used: Float,half and fixed (and their vector and matrix variables, i.e. HALF3 and float4x4): Float:high Precision Floating point. Generally, just like a float type in regular programming languages.
FLOAT: high-precision floating-point type. is typically 32 bits, just like a single-precision floating-point type in a formal programming language. Half:medium Precision floating point. Generally, with a range of-60000 to +60000 and 3.3 decimal digits of precision.
Half: Medium precision floating point type. Typically 16 bits, the range is 60000 to +60000 and 3.3 decimal digits precision. Fixed:low Precision fixed point. Generally bits, with a range of-2.0 to +2.0 and 1/256th precision.
Fixed: low-precision floating-point type. Typically 11 bits, ranging from 2.0 to +2.0 and 1/256th accuracy.

Use lowest precision. is possible; This was especially important on mobile platforms like IOS and Android. Good rules of thumb are:

It is especially important for iOS and Android platforms to use the lowest possible precision. Recommended rule of thumb: for colors and unit length vectors, use fixed.
For vectors of color and unit length, use fixed. For others, the use half if range and precision are fine; otherwise use float.
For others, if the range and precision allow, use half, otherwise use float.

On mobile platforms, the key was to ensure as much as possible stays in low precision in the fragment shader. On the most mobile GPUs, applying swizzles to Low precision (FIXED/LOWP) types are costly; Converting between FIXED/LOWP and higher precision types are quite costly as well.

On a mobile platform, the key is to use as much low-precision data as possible in the fragment shader. In most mobile device GPUs, applying swizzles on low-precision (FIXED/LOWP) types is time-consuming, and converting between FIXED/LOWP and high-precision types can be costly. Alpha Testing
Alpha Test

Fixed function alphatest or it s programmable equivalent, clip (), have different performance characteristics on different p Latforms:

Fixed function alphatest or the programmable function clip () with its functions have different performance characteristics on different platforms: generally it's a small advantage to use it to cull out totally transpare NT pixels on the most platforms.
In general, using it to remove completely transparent pixels from most platforms has a small advantage. However, on PowerVR GPUs found in IOS and some Android devices, alpha testing is expensive. Don't try to use it as "performance optimization" there, it'll be slower.
However, in the PowerVR GPU on iOS devices and some Android devices, alpha test is time-consuming. Do not try to apply it to optimize performance, as it will make performance slower. Color Mask

On some platforms (mostly mobile GPUs found in IOS and Android devices), the using Colormask to leave out some channels (e.g. Colormask RGB) Can is expensive, so only use it if really necessary.

On some platforms (mostly GPUs and Android devices on iOS mobile devices), it is expensive to use Colormask to remove some channels (such as Colormask RGB), so do not use it unless it is really necessary.