[tuhopuu-devel] Re: [tuhopuu-cvs] CVS commit: tuhopuu2/source/blender/render/intern/source rendercore.c

Robert Wenzlaff tuhopuu-devel@blender.org
Mon, 1 Dec 2003 08:36:15 -0500


On Sunday 30 November 2003 21:01, Chris Want wrote:
> hos (Chris Want) 2003/12/01 03:01:07 CET
>
>   Modified files:
>     tuhopuu2/source/blender/render/intern/source rendercore.c
>
>   Log:
>   A fix for the bf-blender back buf endless loop bug ... please test
>   (especially OS X).

While that method seems to work, we should avoid throwing divides around in 
the renderloop.  Here, it's an integer divide and a power of 2 and will 
probably get optimized to: 

	sp=ofs>>16;

Simplest thing I can think of is change the inner while to:

	while(ofs>65535){};

I also found making ofs and sp volatile stop the hang with the original tricky 
cast.

I tried it all three ways and I didn't see any significant differences in 
render time, (Actually both our ways seemed to be ~1% faster than the 
original, but not beyond the normal randomness in rendertimes, so 
statistically insignificant). 

But you know the problems we've had with optimzers lately...

(Tested on gcc  3.2.3 RH9 Linux)

FWIW:
Cost in instruction cycles per divide for Pentium:

byte/byte = 17, int_16/int_16=25, int_32/int_32= 41, 
float/float=39, double/double=39, float/int_32=41.   

They are performed in special hardware and can overlap other instructions, so 
the net times will be lower, but still can be costly.  The integer unit 
overlaps instructions better than the floating point unit, so the int_32 vs. 
the float times are somewhat misleading.

**********************************************************
Robert Wenzlaff                rwenzlaff@soylent-green.com