From: Matthieu K. <mat...@s2...> - 2012-08-30 21:23:09
|
> The benefit of performing sorting by material (or rather, shader) is > that it reduces shader program switches. didn't think about that one tbh, but then again sorting by material seems unlikely to result in a sort by shader as we have tons of materials per shader and the sorting by material will result in a quite arbitrary shader order. > Whether that makes a difference > depends on whether a scene contains a lot of shader variations or not. test scenes had quite some variations by material, but shader variations were quite low - I think partially due to distance sorting as sorting by distance also results in more coherent light influences. > As sorting increases with the number of meshes... how many were in the > test scenes? I used three test scenes myself: castle, bias and a map from PS: amdeneir (~600-1500 draw calls with ~300k-500k primitives iirc). while castle is pretty simple bias and especially amdeneir are pretty complex I think, so should have all covered. > Note that doing distance-based sorting by default is probably not a step > towards getting un-CPU-bound. The aim wasn't really to get "un-CPU-bound". The intention behind the default distance-sorting was to try to improve the number of rejected primitives/fragments and trying to get rid of the depth-only pass without introducing a new performance hit after profiling yielded that most of our GPU time is spent in vertex processing. (note that I'm GPU bound for all RMs except rlcompat (which is bound by blocking GL calls) with ~30-40% cpu usage and 90-100% GPU usage). While the results weren't as big as I hoped, it yielded a notable difference for me (up to 5% FPS improvement) while the difference didn't seem to be notable on weltall's CPU bound system. regards, RlyDontKnow |