> On Dec. 2, 2012, 9:23 a.m., Celierra Darling wrote: > > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl, line > > 127 > > <http://codereview.secondlife.com/r/612/diff/1/?file=8137#file8137line127> > > > > The 'if' here might be problematic.. I remember some cards were choking > > on branches, thus the convoluted lines that looked like new = old + > > int(conditional)*value. (same for class1) > > > > Also, I could have sworn that there used to be comments here specifying > > what the non-mangled math originally was (a la the old > > softenLightF.glsl:206-214).... > > Tofu Buzzard wrote: > Our shaders are really branchy, that's really not a problem (on the > target class). I don't strictly remember removing comments on the original > maths, but the weighting (the only mathy part of this affair really) has > changed radically at least twice since the original inline explanation, and > should be simple enough to follow procedurally lately. :)
However, a general rule of thumb is if you can save a branch in a shader, then you should do so. My personal preference is to try and keep it to branches that have defined ARB instructions that a vendor's GLSL compiler will likely optimize to (which is limited to less than and greater than unfortunately). Though you're right, it's not much of a problem on class 2 hardware that can handle deferred. That said, is there a good reason for diff.z != 0.0 to *not* be diff.z > 0.0? - Geenz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/612/#review1288 ----------------------------------------------------------- On Dec. 2, 2012, 3:49 a.m., Tofu Buzzard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/612/ > ----------------------------------------------------------- > > (Updated Dec. 2, 2012, 3:49 a.m.) > > > Review request for Viewer. > > > Description > ------- > > Use a different scheme for weighting SSAO samples, apply SSAO before fog is > applied, fix a bug in the screen-space shadow/ssao smoothing offset where the > 'checkerboard' stipple had been refactored incorrectly, change some default > settings in line with the resulting visual changes. Also, improve comments a > bit. :3 > > > This addresses bug VWR-29083. > http://jira.secondlife.com/browse/VWR-29083 > > > Diffs > ----- > > doc/contributions.txt UNKNOWN > indra/llrender/llshadermgr.h UNKNOWN > indra/llrender/llshadermgr.cpp UNKNOWN > indra/newview/app_settings/settings.xml UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/blurLightF.glsl UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/softenLightF.glsl > UNKNOWN > indra/newview/app_settings/shaders/class1/deferred/sunLightSSAOF.glsl > UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/softenLightF.glsl > UNKNOWN > indra/newview/app_settings/shaders/class2/deferred/sunLightSSAOF.glsl > UNKNOWN > indra/newview/pipeline.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/612/diff/ > > > Testing > ------- > > Been running with this for months on an assortment of nvidia hardware, linux > only. > > > Thanks, > > Tofu Buzzard > >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
