Re: [Paracomp-devel] Crash in pcSystemFinalize

[Shree K. <shr...@hp...>]

Stefan Eilemann wrote:
>> Can you explain what you mean by "Eq supports different sizes between
>> the images" ?
>>
>> Paracomp does it too. It only expects the width and height of the
>> compositing regions to match for all the source & destination
>> operands.
>> The test program you have doesn't exercise this case.
>>     
>
> This is true, since this case does not yet happen in Equalizer.
>
> We are planning a region-of-interest extension in Eq, where each draw
> operation specifies the screen-space area covered by data, which would
> yield to different sizes in the source images.
>   
That's interesting. We have a similar capability in Paracomp, where the 
programmer
can add pixel rectangles at arbitrary locations, and the library handles 
it. James, in his
presentation yesterday, had a slide on "framelets" and performance 
improvement due
to that. He had compared it with full screen compositing.

This "Region-of-interest" functionality is currently not accessible 
using the interface
I provided you, but it should be possible to add that (need a bit of 
thought here).

An example program is in samples/intermediate/multiple-framelets. Update 
to revision
 64, this includes a minor change to make the app more usable on a 
single node.
Run the program using ./multiple-framelets 1 -standalone. Controls are 
documented
on-screen.
>>> I assume you meant rev 62?!
>>>
>>>       
>> No I meant 63. I observe the following relation in terms of
>> performance
>> (I've quoted the table below):
>>
>> PC rev 62 < eq rev 1880 < PC rev 63
>>
>> Essentially, rev 63 = rev 62 + using your compositing code from rev
>> 1880
>> for your particular test case.
>>     
> I see. I am not so worried about 'eq rev 1880 < PC rev 63' due to the
> 'skip' calculations in Eq's compositor.
>   
Ok. At-least rev 63  paracomp performance now is not lagging compared to 
1880 now. I think the
cause for this is that the template code in paracomp's depth compositing 
code was not being handled
very well by the compiler. Finding the right compiler options may be an 
answer.

Cheers
-- Shree