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
