# Re: [Flightgear-devel] Shader performance

```After a few more tests, some more observations which seem to be right to
me listed here (if that is confirmed, we may perhaps gather these and
other statements to the Wiki to get some guidelines for efficient shader
coding):```
```
* 'big' performance users seem to be the scientists's friends, i.e.
functions like exp(x), log(x), sqrt(x) which for me make a noticeable
impact :-(. I've made good experience by returning asymptotics explicitly,
for instance in a light function

f(x) = e / (1.0 + a * exp(-b * (x-c)) )**(1/d)

simply asking if x > threshold and returning e if the condition is true
before attempting to evaluate the function speeds things up quite a bit in
many cases while making a tiny error (in my case, 1e-4 or so).

I haven't tried it yet, but I suspect now that x*x*x*x would also evaluate
much faster than pow(x,4.0) since the first is just a multiplication while
the second utilizes a function which is even more general than sqrt().

* GLSL doesn't go for smartness, so it has to be coded in. In an
expression like

mix(cheapExp, expensiveExp, fraction)

even for fraction = 0 expensiveExp is computed. So again, an if (fraction
== 0) in front of this can reduce the load quite a bit to compute
expensiveExp only if it is really needed.

* in the shaders I have seen, usually a very physics-centered approach is
taken: We first take the color of an object from the texture, then apply
ambient, diffuse and specular light to see what color it takes, then go to
the eye and have a look at how much of it is fogged.

However, an eye-centered approach seems much better to me - the first
question to be asked is 'What can we see of the object?' and if the answer
is '99% fog' we don't really need to know the texture or compute specular
reflections.

Which is to say, in many situations I would perhaps compute the fog
function first (if possible) and base my decisions what else to compute
for the pixel/vertex dependent on the outcome of that. For instance, in
the cloud shader fog comes pretty much last - but we probably could
dispense with bottom and away side shading beyond a certain fog value,
because it's useless to first compute a darkening and then brighten it to
transparent/white again.

So far, this hasn't been too relevant because objects which are 99% fogged
are soon to be unloaded anyway, because the distance to which terrain is
laoded is set by the same parameter as the fog. But this may not be how to
continue. The terrain-haze shader already allows the two to be different,
and it has also a lot of merit to have terrain loaded even if you can't
see it - weather needs to know terrain to get cloud-terrain interactions
right, any terrain radar would need it (see for instance the very
interesting development 787 MFD Vertical Profile here:

http://flightgear.org/forums/viewtopic.php?f=30&t=15200

this simply won't work under true IFR conditions when it is needed most
because no terrain is loaded).

All in all, it seems to me that making shader code efficient is just a
very messy and ugly uphill battle in which lots of small effects sum up to
something noticeable in the end...

Cheers,

* Thorsten

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just \$99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
```