[Bf-committers] Backbuffer hang in oldrenderpipe.

[Robert Wenzlaff]

On Wednesday 12 November 2003 06:09, Ton Roosendaal wrote:

> This is code that exists in Blender since the beginning, and I didn't  
> encounter problems with it while doing the ports for freebsd, linux,  
> beos, alpha...
>
> I remember issues with optimizing, but the -O2 level seemed to work  
> everywhere. First I like to know what causes this error now... because  
> there are more such tricks in Blender, in rendering and the imbuf code  
> for example.

My thoughts exactly.

I set my compile switches back to default.  No luck.

I forced -O1 and it fixes it.  Maybe this should be the default level for 
jusst render and imbuf.  We should do some testing to see how this affects 
render speed.
 
It may be specific to a version of gcc as I have yet to see anyone else report 
that they can reproduce it.  And since various invocations of "volatile" 
didn't fix it, it may be a bug in gcc.

gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
glibc-2.3.2-27.9

But in general, we should write clear code and let the optimizer do our tricks 
for up.   Before scrolling up a page to see that sp was a pointer within ofs, 
I couldn't see how that loop ever worked.  If the code is clear to you and I, 
it's a very good bet that it was clear to the guy who wrote the optimzer and 
the optimizer will do the right thing.  

So instead of masking them with -O1, we should test at -O3 to see what else 
breaks, and neaten that up if we can.  But in any case, we shouldn't issue 
2.31 with a known hang in it, so I vote for "while(ofs>65536)" (not that this 
is entirely a democracy).   We can always change the code back and play at 
our expense and spare the user. 

>>>> On Tue, 11 Nov 2003, Robert Wenzlaff wrote:
>>>>> There's some odd code in rendercore.c around line 310 in
>>>>> scanlinesky().  It is invoked when using the old renderpipe with a
>>>>> backbuff image.
-- 
**********************************************
Robert Wenzlaff    rwenzlaff@soylent-green.com