Thanks for writing this up. I have a couple of comments, nitpicks really. On Mon, Oct 15, 2012 at 9:43 AM, Renk Thorsten <thorsten.i.r...@jyu.fi> wrote: > > I thought it might be a good idea to write up a few things I've tried > recently and not seen in widespread use - so that either others know about > them as well or I can find out what the pitfalls are. > > Basically this is about reducing the number of varyings, which is desirable > for at least two reasons. First, their total amout is quite limited (I think > 32?). Second, they cause work per vertex and per pixel, so their load scales > always with the current bottleneck. Their actual workload is just a linear > interpolation across a triangle though, so the optimization I'm talking about > here is maybe all together 10-20% gains, not something dramatic, and it's not > unconditionally superior to save a varying if the additional workload in the > fragment shader is substantial. > > Also, the techniques are somewhat 'dirty' in the sense that they make it a > bit harder to understand what is happening inside the shader. > > * making use of gl_FrontColor and gl_BackColor -> gl_Color > > As far as I know, these are built-in varyings which are already there > regardless if we use them or not. So if we don't use them at all because all > color I don't think that any varyings -- except for the fragment coordinates -- are mandatory, except perhaps on very old hardware. Generally the total shader program is optimized to remove any unnecessary computations. However...
>computations are in the fragment shader, they can carry four components of >geometry, if we use a color but know the alpha, there is one varying which >>can be saved by using gl_Color.a to encode it. I agree that using a coordinate in a varying that you already need is a good trick, better than assigning a new varying. One can assume that a vec4 varying is no more expensive than a vec3. By the way, we only encode the front/back facing info in alpha in order to get around shader language bugs. > > The prime example is terrain rendering where we know that the alpha channel > is always 1.0 since the terrain mesh is never transparent. In > default.vert/frag gl_Color.a is used to transport the information if a > surface is front or backfacing, but in terrain rendering we know we're always > above the mesh, so all surfaces we see are front-facing, and we do backface > culling in any case. ... > * light in classic rendering > > Leaving Rembrandt aside, the direction of the light source (the sun) is not a > varying but actually a uniform. In case we need this in world space in the > fragment shader, doing a > lightdir = normalize(vec3(gl_ModelViewMatrixInverse * > gl_LightSource[0].position)); > in the vertex shader and passing this as varying vec3 is quite an overkill. One reason to pass this as a varying is that on old hardware, GeForce 7 and earlier, it is very expensive to change a uniform that is used by a fragment shader. It forces the shader to be recompiled. So, this is actually a well-known optimization for old machines. Also, I want to point out that, in your example, lightdir is in the local coordinate system of the terrain, if in fact you are shading terrain. I would call "world space" the earth-centric coordinate system in which the camera orientation is defined. > > Due to the complexity of the coordinate system of the terrain, it's not clear > to me how to get the world space light direction really into a uniform, but > we do have it's z-component (the sun angle above the horizon) as a property > and can use this as uniform. Since light direction is a unit vector, it means > that only the polar angle of the light needs to be passed as a varying then, > saving two components. We could include per-tile uniforms as state attributes in the scene graph if we decide that we really want them.. > > In particular for water reflections computed in world space, passing normal, > view direction and light direction in world coordinates from the vertex > shader (9 varying) is really not efficient - the normal of water surfaces in > world space is (0,0,1) and not varying at all (we do have formally water on > steep surfaces in the terrain, but we never render this correct in any case > since in reality rivers don't run up and down mountainslopes and foam when > they run really fast on slopes, and to worry about getting light reflection > wrong when the whole setup is wrong is a bit academic), the light direction > is really just the polar angle, since we later dot everyting with the normal > we really only need the z-component of the half-vector, and that means just > two components of the view direction - so it can in principle be done with 3 > varyings rather than 9. I'm not sure it's useful to think of each component of a varying vector as a "varying" i.e., three vec3 varying values use up three varying "slots," and so do 3 float varying values. On the other hand, if you can back all the lighting info into one varying, great. > > I've tested and used some of those, for instance making use of the cross > product or the alpha channel in terrain rendering performs just fine. A > 10%ish performance gain for the terrain shader isn't something to be > massively excited about, but in the end combining a few 10% gains from > various tricks does make an impact. Well, anyway - a few people just might > be interested. Absolutely! Tim ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
