paracomp-devel

Re: [Paracomp-devel] Crash in pcSystemFinalize

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

Hi Stefan,

On Wed, 2008-05-14 at 11:14 +0000, Stefan Eilemann wrote:
> >
> > PC rev 63 seems to be faster than Eq rev 1880. Am I
> > missing something ?
> 
> No - I think it is due to the fact that Eq supports different sizes
> between the images, which makes the code a bit more complex.
> 

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.

> >
> >
> > Of course, I'm still puzzled about the perf difference between Eq and
> > rev 63 :-)
> 
> 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.

>> Eq, rev 1880:
>> ./Darwin/test: DB first op:  41.4328 ms (1272.77 MB/s)
>> ./Darwin/test: DB second op: 28.1947 ms (1870.36 MB/s)
>> ./Darwin/test: DB 15 images: 92.7198 ms (2843.75 MB/s)
>>
>>
>> PC, rev 63:
>> ./Darwin/test: DB first op:  39.5884 ms (1332.07 MB/s)
>> ./Darwin/test: DB second op: 26.9765 ms (1954.83 MB/s)
>> ./Darwin/test: DB 15 images: 87.6801 ms (3007.2 MB/s)
>>
>> PC, rev 62:
>>
>> ./Darwin/test: DB first op:  45.064 ms (1170.21 MB/s)
>> ./Darwin/test: DB second op: 32.2106 ms (1637.17 MB/s)
>> ./Darwin/test: DB 15 images: 111.401 ms (2366.88 MB/s)
>>
>

Cheers
-- Shree

Re: [Paracomp-devel] Crash in pcSystemFinalize

[Stefan E. <eil...@gm...>]

On 16. May 2008, at 12:28, Shree Kumar wrote:

> Hi Stefan,
>
> On Wed, 2008-05-14 at 11:14 +0000, Stefan Eilemann wrote:
>>>
>>> PC rev 63 seems to be faster than Eq rev 1880. Am I
>>> missing something ?
>>
>> No - I think it is due to the fact that Eq supports different sizes
>> between the images, which makes the code a bit more complex.
>>
>
> 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.

>> 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.


HTH,

Stefan.
-- 
http://www.eyescale.ch
http://www.equalizergraphics.com
http://www.linkedin.com/in/eilemann

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