Johan mailed me a link to this site: http://stereopsis.com/sree/fpu2006.html Based on the routine proposed there I just implemented faster rounding in Gaussian blur (the IIR code uses it extensively). In my tests this speeds up blurring by about 10-20%, not insignificant for such a small change. However, the procedure does make use of the internal representation of a double, so I'm a little worried about it breaking on different architectures.
If you use a non-Intel architecture it would be great if you could try out the Gaussian blur currently in bzr (it's rev. 10144) and see if anything goes wrong.
I tried experimental custom filters in rev 10144 (on my low cost Intel Core I3 system) and found them much faster in rendering ! Some of them like "Drawing" or "Cross engraving" or "Poster paint" make extensive use of Gaussian blur and they are now a real pleasure to use on mid to high resolution images.
Thanks a lot Jasper for this very nice and important improvement !!!
ivan
________________________________ De : Jasper van de Gronde <th.v.d.gronde@...528...> À : Inkscape Devel List inkscape-devel@lists.sourceforge.net Envoyé le : Sam 2 avril 2011, 17h 39min 17s Objet : [Inkscape-devel] Faster rounding, might break?
Johan mailed me a link to this site: http://stereopsis.com/sree/fpu2006.html Based on the routine proposed there I just implemented faster rounding in Gaussian blur (the IIR code uses it extensively). In my tests this speeds up blurring by about 10-20%, not insignificant for such a small change. However, the procedure does make use of the internal representation of a double, so I'm a little worried about it breaking on different architectures.
If you use a non-Intel architecture it would be great if you could try out the Gaussian blur currently in bzr (it's rev. 10144) and see if anything goes wrong.
------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2-4-2011 17:39, Jasper van de Gronde wrote:
Johan mailed me a link to this site: http://stereopsis.com/sree/fpu2006.html Based on the routine proposed there I just implemented faster rounding in Gaussian blur (the IIR code uses it extensively). In my tests this speeds up blurring by about 10-20%, not insignificant for such a small change.
I knew it! :P
However, the procedure does make use of the internal representation of a double, so I'm a little worried about it breaking on different architectures.
If you use a non-Intel architecture it would be great if you could try out the Gaussian blur currently in bzr (it's rev. 10144) and see if anything goes wrong.
Perhaps you can #ifdef the faster implementation of rounding?
Ciao, Johan
On 2011-04-03 20:56, Johan Engelen wrote:
On 2-4-2011 17:39, Jasper van de Gronde wrote:
However, the procedure does make use of the internal representation of a double, so I'm a little worried about it breaking on different architectures.
If you use a non-Intel architecture it would be great if you could try out the Gaussian blur currently in bzr (it's rev. 10144) and see if anything goes wrong.
Perhaps you can #ifdef the faster implementation of rounding?
It already checks for big endian and little endian using byte order macros from glib (it even falls back on the usual code if the architecture is neither big nor little endian...), but I have no way of testing on a big endian machine at the moment.
On Apr 4, 2011, at 12:09 AM, Jasper van de Gronde wrote:
On 2011-04-03 20:56, Johan Engelen wrote:
On 2-4-2011 17:39, Jasper van de Gronde wrote:
However, the procedure does make use of the internal representation of a double, so I'm a little worried about it breaking on different architectures.
If you use a non-Intel architecture it would be great if you could try out the Gaussian blur currently in bzr (it's rev. 10144) and see if anything goes wrong.
Perhaps you can #ifdef the faster implementation of rounding?
It already checks for big endian and little endian using byte order macros from glib (it even falls back on the usual code if the architecture is neither big nor little endian...), but I have no way of testing on a big endian machine at the moment.
Did you look into adding some sanity check as part of autoconf, or is it a bit hard to tell when it breaks?
2011/4/2 Jasper van de Gronde <th.v.d.gronde@...528...>:
If you use a non-Intel architecture it would be great if you could try out the Gaussian blur currently in bzr (it's rev. 10144) and see if anything goes wrong.
All sensible architectures use natural-endian IEEE754 floating point numbers, so this should not be a problem.
The only counterexample I know of are some early ARM FPUs, specifically the "Floating Point Accelerator", which has mixed-endian doubles and is a software porter's nightmare. Fortunately it's very rare nowadays.
Regards, Krzysztof
participants (5)
-
Ivan Louette -
Jasper van de Gronde -
Johan Engelen -
Jon Cruz -
Krzysztof Kosiński