On Sun, Feb 5, 2012 at 12:50 PM, Thorsten Renk wrote: > I haven't really seen any guidelines about efficient shader coding, but > I've come across a few statements here and in the forum now and then, > which I so far assumed to be true. I've now spent the last few days > benchmarking my lightfield/terrain haze framework to see if I can't > squeeze a bit more performance out. Since the results somewhat > contradicted things I have assumed to be true before, I thought I might > share my observations.
Very interesting, and food for thought :) > > 1) vertex shader is fast and efficient, fragment and geometry shaders are > comparatively slow and cost performance <snip> > Since for instance 3d clouds run almost exclusively via vertex shader, > this may not be an otherwise irrelevant observation. That's very interesting. Do you have any suggestions for what information we could push onto the fragment shader? > 2) vertex count doesn't matter > > I've read that in the forum as advice to model-builders quite often. For > all I can test, that's wrong. In order to get the same framerate in > default scenery and custom Italy CORINE scenery, I have to set the > visibility range ~a factor 10 different. That's consistent with a hundred > times higher vertex count in the CORINE scenery, or with a factor 10 > higher linear resolution of landcover and elevation data, which seems > about right. So the vertex count more or less directly sets my framerate. I think there are far too many variables in your examples to be able to draw a conclusion that vertex count is the over-riding factor. My understanding from Matthias' comments on the 3D cloud code is that provided the GPU isn't having to reload a different state set, then it should be very efficient indeed in handling larger numbers of vertices. So, in the 3D clouds case, asking the GPU to render a whole set of quads at once to create a cloud is more efficient than rendering each sprite one at a time. (On a related note, while the Impostor's haven't been a success, the other improvements should mean that you can use more sprites per cloud than before for the same perf cost) In your examples, the increase in vertex count will be accompanied by an increase in object count, and (in the AI case) an increase in textures. In each of these cases, the GPU will be loading and unloading state, which is inefficient. A more interesting example would be to compare the impact of a model with 1k vertices, with one with 10k vertices, with the same object count, texture etc. > 3) shifting constant-per-frame computations out of the shader doesn't > improve performance significantly. > > I suggested that here as an idea to improve performance of the cloud > shaders. I was now able to construct a test case for the idea. The > computation in question involved getting a per-frame constant from other > constants, i.e. to compute sqrt(2 * hazeAlt * EarthRadius) where hazeAlt > is the altitude up to which the haze extends which is passed as a uniform. > > Computing two of such square root expressions inside the vertex shader or > not computing it makes the difference between 21 and 22 fps in a high > vertex count benchmark test, i.e. 5%. Which is not that much in itself, > but if we would find, track and eliminate all these occasions, the sum of > such small improvements might well go into the 20-30%. Makes a lot of sense. I'm happy to add extra Uniforms to the 3D cloud shaders. What do you need calculated in the C++ code? -Stuart ------------------------------------------------------------------------------ Try before you buy = See our experts in action! 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-dev2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
