2013/10/11 Nicholas Cameron <nick.r.came...@gmail.com> > The advantage to me is that we have a single shader and avoid the > combinatorial explosion when we add more shaders for things like SVG > filters/CSS compositing.
[...snip...] > > I have not recently been discussing new shaders, perhaps you are thinking > of mstange who is looking at HW implementations of SVG filters? > Incidentally, I just looked into the feasibility of implementing constant-time-regardless-of-operands (necessary for filter security) filters in OpenGL shaders, as a similar topic is being discussed at the moment on the WebGL mailing list, and there is a serious problem: Newer GPUs (since roughly 2008 for high-end desktop GPUs, since 2013 for high-end mobile GPUs) have IEEE754-conformant floating point with denormals, and denormals may be slow there too. https://developer.nvidia.com/content/cuda-pro-tip-flush-denormals-confidence http://malideveloper.arm.com/engage-with-mali/benchmarking-floating-point-precision-part-iii/ I suggest on the Khronos public_webgl list that one way that this could be solved in the future would be to write an OpenGL extension spec to force flush-to-zero behavior to avoid denormals. For all I know, flush-to-zero is currently a CUDA compiler flag but isn't exposed to OpenGL. The NVIDIA whitepaper above also hints at this only being a problem with multi-instruction functions such as square-root and inverse-square-root (which is already a problem for e.g. lighting filters, which need to normalize a vector), but that would at best be very NVIDIA-specific; in general, denormals are a minority case that requires special handling, so their slowness is rather universal; all x86 and ARM CPUs that I tested have slow denormals. Benoit _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
