On Thu, Apr 05, 2001 at 12:45:52PM -0500, Kelly Martin wrote:
> Hm, it does not. The issue with whirlpinch is that there's only a
> weak locality relationship between destionation pixels (which are
> iterated across the image) and source pixels (which are fetched with
> the pixel fetcher). I haven't looked too closely at your blocking
That is right, but destination and source for themselves have good locality
(ie. the next pixel isn't 500 pixels away from the last).
I have tried whirl&pinch with huge distortion values, and the worst case was
8s instead of 6.5s, still better than 30s ;-)
> patch, but I suspect that much the same improvement would be had by
> using a pixel region (which respects tiles) to iterate across the
> destination region.
That is possible... Is there a filter that definitely uses the pixel region
stuff? Most filters I have seen only use one row, which may not be enough
"locally", since it uses only one pixel but has to fill a whole cacheline
(4/8 pixel). I will try whether I can speed up bumpmap also, since this
takes also the magical 30s and is much more often used in scripts than the
whirl&pinch module.
I don't know how large a tile is, but since IMHO the major impact of
blocking seems to come from the CPU cache, I suspect that is too big for
older CPUs. I have done the whirl&pinch blocking thing about three years ago
(and forgot to send the patch), and tried it on an Alpha21164 and a P5.
Both have only very small L1-caches (Alpha has 8K) and relatively slow L2
caches (+L3 for Alpha). The best blocking factor for those CPUs was between
64 and 128. My Athlon now also tolerates 512, 32 only is only slightly (2%)
slower, but should work for all CPUs fairly good.
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
