I was trying to make a very simple shader for rendering transparent textures on a quad with no ilumination.
I have some experience in GLSL but after struggling for some time I have been unable to use it on my windows builds and decided to try shaderlab. This shader works perfectly but I was wondering if I’m doing something wrong, especially the lighting part as it “feels” a bit strange to me.
I also don’t like all those surface shaders. In the end, they do some horrible assumptions which can slow down your game by a lot.
But guess what, you can define your own vertex and fragment shaders just like in any other shader compiler using #pragma vertex and #pragma fragment
There’s a tiny little tutorial about this riiight here: http://docs.unity3d.com/Documentation/Manual/ShaderTut2.html
To clarify the above post… You made it faster on some machines by adding the fragmentoption ARB_precision_hint_fastest pragma and fixed a bug by moving Cull off to inside the pass. Unless I missed something, all the other changes seem unnecessary.
The line in the frag shader below, mixes a half and float ( they should all be fixed precision there )
using half and float is slow, mixing and causing a conversion is even slower.
return texcol*_Color;
original code was returning a half4 in frag shader, which should be fixed4 ( fixed4 is faster )
BTW: I dont think the “fragmentoption ARB_precision_hint_fastest” does anything for vertex frag shaders just put it there by habit
Original compiled frag shader is 8 cycles and more code
Most of today’s GPUs completely ignore variable precision settings anyways, but fair point, I missed that one.
3 and 4) The same thing… My target is usually modern GPU, so I often ignore the precision altogether.
“ARB_precision_hint_fastest” is not a Unity thing, it comes from openGL… now THIS actually controls the precision used:
Most of the code you see there will be optimized away by the UMD, like all those unnecessary assignments. Even if it wasn’t optimized at all, as far as I know, assignments (even with conversion) are free and don’t cost you a cycle. But yeah, your compiled result is indeed sexier
So there, I don’t believe there’s any actual performance improvement, but I agree it’s better to be safe.
And don’t get me wrong, I’ll really appreciate if you prove me wrong. Performance means a lot to me… I mourn every lost cycle.
ARB_precision_hint_fastest << I didnt know that was opengl thing i thought it was for unity shader optimizer thingy,I was just testing resulting compiled code always looked the same, so i put it in any shaders i write to be safe. ( good thing i do )
I rarely use the macros in the include files, didn’t catch that one
“o.uv = TRANSFORM_TEX (v.texcoord, _MainTex);”
Id rather code it right, because like on Android you never know what it will get turned into
On my tests on Android and iOS, having a float where it should be a fixed did show a difference in speed.
( Im sure in some cases it dont matter, but others it gets turned into a lot more code )
I’ve noticed that sometimes using a half2 for a uv leads to some weird texture mapping on iOS devices. You sometimes need the full floating point precision.
Also I’ve heard that casting between two types like a fixed * half leads to some performance degradation not sure if it’s true or not.
The precision is ignored on desktop GPUs though. You can easily prove this by setting a fixed precision variable and overloading it’s range (outside of -2, 2). It still has it’s correct value.