I wrote:
> > Or the coprocessor.
> 
>  Yes! I think it is something to do with the copro. After reading
> thousands of technical reports and messages that I barely understand, I
> think there are some differences on how P-III and Athlon manage FPU
> exceptions. So perhaps compiling pov specifically for the athlon can be
> the solution ...

  Some news:

  As I said, I upgraded GCC to 3.0, and compiled pov with the default
makefile: slighty better performance(not more than a 5%), the ick was
still there. Then, I compiled with the flags for athlon (they are posetd
on the net on many sites): the ick was still on the renders, but
preformance improved greatly, almost a 15% on the test scene. I've not
done any other tests, but that scene is not simple (it is "oldroom.jpg"
from my gallery). That seems to
confirm the recent tests done by Steve.

  The only things I found that greatly mitigates the ick effect, is
removing all optimizations when compiling. That reduces the spots at
least in a 90%, and the only remaining spots are not so bright, more
close to the actual color for the pixel. With antializasing, it almost
desapears, but is still visible if you compare the image with a "clean"
render. Curiously, using optimization but adding the flag
-fno-fancy-math-387
leads to the same results... gives this any trail to find the cause? Any
pointers of where to look at?

  I'm starting to think on hardware damaged... I think the coprocessor
is
really buggy, perhaps bcos I'had the CPU running with a poor heatsink
during some weeks (altough temp never reached more than 70 Celsius, and
it is supposed to die at 90). the only thing that makes me doubt it, is
the fact that pov is the only application that shows problems.

  Also, FYI, I noticed that this error happens also on windows (I was
wrong), but is much less noticeable...

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org/

Post a reply to this message