paracomp-devel — Discussions related to this implementation of the API happen here

[Paracomp-devel] ParaComp 1.2 released !

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

Hi All,

I've just release ParaComp v1.2 . Do give it a try !

Release 1.2

         New Library Features
           - Support for 16 & 32 bit floating point values for compositing
             The tokens for these are :
                    PC_PF_RGB16F, PC_PF_RGBA16F,
                    PC_PF_RGB32F, PC_PF_RGBA32F.
             16 bit calculations are done using ILM's half library, so 
expect these to be slow.
           - Accumulation operator PC_COMP_ADD.
           - EXT_composite - an extension to use ParaComp as a 
compositing-only
             backend. This extension allows ParaComp to be used as a 
compositing
             backend for Equalizer (http://equalizergraphics.com).
           - Alterate operator, PC_COMP_ALPHA_SORT2_HP for 
alpha-blending. This
             is used for volume rendering by eVolve (volume rendering
             demo application that is part of Equalizer).
           - Added a way to control which TCP ports the library uses

         Works on new platforms
           - Mac OSX, Darwin (x86/x86_64, PPC)
           - SGI Prism (Linux on Itanium)
           - better support for 32 bit linux

         src
           - Fixed : Alpha blending bug in pure CPU code (SF Bug 1928113)
           - Fixed : MPI interaction issue (SF Bug 1827022, 1953910)
           - Improved build system, compiles with GCC 4.x
           - Cleaner & better compiles
           - Works with OFED 1.2 and above
           - Bumped up the version number to 1.2

         samples
           - Uses nVidia glh for trackball, much better than older trackball
             code
           - Easier to run multiple instances of samples on a single node
           - New sample programs
             - intermeditate/multithreaded : Multithreaded use of ParaComp

         test
           - new directory with test programs.

         doc
           - documentation of changes from API v1.1 to v1.2

Cheers
-- Shree

Re: [Paracomp-devel] Impending Parcomp Release...

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

Hi All,

I've integrated all the changes into the ParaComp trunk. I've already 
tested it a bit. I intend to do some more testing today.

I've bumped the ParaComp version to 1.2 as well. Chief API differences 
from 1.1 :

   1. 16 & 32 bit floating point datatypes
      PC_PF_RGB16, PC_PF_RGBA16, PC_PF_RGB32, PC_PF_RGBA32

   2. PC_COMP_ADD operator

   3. PC_COMP_ALPHA_SORT2_HP extension for Equalizer integration.

Let me know if you find any issues on the trunk.

Thanks
-- Shree

Planning for a release tomorrow !

Kumar, Shree (STSD) wrote:
> Hi,
> 
> It's been a long time since we had a Paracomp release. Good reason by
> itself to have one ;-)
> 
> There have been quite a few changes since the last release. Changes in
> the trunk include compilation fixes for a few platforms (OSX/Darwin most
> prominently).
> 
> There are several changes (that are not in the trunk)) that I think are
> worthwhile having in the release -
> 1. Support for floating point datatypes
> 2. Support for the accumulation operator.
> 3. Another alpha blending operator for Equalizer Integration
> 
> Any other changes you'd want me to include, please let me know.
> 
> IIRC, George/James (Univ of Manchester) were working on a Solaris Port.
> If that is finished, do let me know. I'd like to include that.
> 
> I'll start merging in the required changes into the trunk. The plan is
> to have a release early (optimistically Nov 17th).
> 
> Thanks
> -- Shree
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Paracomp-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
> .
> 

[Paracomp-devel] Impending Parcomp Release...

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

Hi,

It's been a long time since we had a Paracomp release. Good reason by 
itself to have one ;-)

There have been quite a few changes since the last release. Changes in 
the trunk include compilation fixes for a few platforms (OSX/Darwin most 
prominently).

There are several changes (that are not in the trunk)) that I think are 
worthwhile having in the release -
1. Support for floating point datatypes
2. Support for the accumulation operator.
3. Another alpha blending operator for Equalizer Integration

Any other changes you'd want me to include, please let me know.

IIRC, George/James (Univ of Manchester) were working on a Solaris Port. 
If that is finished, do let me know. I'd like to include that.

I'll start merging in the required changes into the trunk. The plan is 
to have a release early (optimistically Nov 17th).

Thanks
-- Shree

Re: [Paracomp-devel] Accessing compositor from multiple threads

[George L. <geo...@ma...>]

Hi Shree,

> There's another way out too I think. The render thread can get the
> pixel pointers (either using pcFrameResultChannel or WaitOutput) and
> send them to the display thread. The pixel pointers will be valid
> till the next FrameBegin(), so the display thread can draw the pixels
> before it releases the render thread for the next frame. This
> approach has the benefit of not changing the GL context in the
> threads.

Yes, thanks, I'll try that. I've just done something similar in that  
the render thread can now do a pcFrameResultChannel() and memcpy the  
final image to a supplied block of memory. This is then passed to the  
display thread so it can do a glDrawPixels(). Passing the pixel  
pointer would be more efficient (and allow the use of  
pcResultGetChannelHP). In our 'memcpy' method I still see problems  
with the free(iter2) call but only occasionally on window resizes.  
I've commented out the calls to free() that are causing a problem  
(accepting a mem leak :-) ) and replaced with a print of the pointer.  
Some of them look bad (on a 64bit linux box). Hence I see something  
like the following (where 0 is the master and 1,2 are render node  
processes).

0: pcFrameBegin(no framelets, _frameId 206 )
    Context::FrameBegin Not freeing iter2 0x2aaaadf16010
    Core::StartFrame    Not freeing iter2 0x2aaaade0d010

1: pcFrameBegin(1 framelet, _frameId 206 )
    Core::StartFrame Not freeing iter2 0x2aaaac423010
    Core::StartFrame Not freeing iter2 0xbded40

2: pcFrameBegin(1 framelet, _frameId 206 )
    Core::StartFrame Not freeing iter2 0x2aaaac607010
    Core::StartFrame Not freeing iter2 0xa114b0

  FrameEnds not printed

0: pcFrameResultChannel(_frameId 206 )

The fact this is only being done from the render thread suggests  
either the frame sizes are getting out of sink or some memory stomping  
is going on.

> A request : can you file this as a bug in SourceForge so that I can
> keep track of it ?

Yes, I'll summarize the discussion there.

Thanks,
George







> George Leaver wrote:
>
>   Hi Shree,Yes, the FrameID generate by pcFrameBegin() is used by
> pcFrameResultChannel(). I'm using rev72 from sourceforge. At least I
> now know the thread model is, in principle, allowed.I suspect I need
> to modify the sample code (hello-depth) to use the same thread model
> as below. Unfortunately I don't have any simple code demonstrating
> this problem. I'll also have a go at writing the output image to the
> display-thread's GL context at the end of the render loop rather than
> from the display loop to keep all pc calls in one thread.Regards,
> GeorgeQuoting Shree Kumar <shr...@hp...>:
>
>> Hi George,Logically, a host represents a thread of execution. Each
>> host has a context object(PCcontext). Using the same context object
>> simultaneously from two threads will not work.The scenario that you
>> are describing ought to work (with the existing implementation),
>> since both threads aren't making paracomp calls at the same time
>> using the same object.A quick sanity check (just to be sure) -- do
>> you have a mechanism to pass the FrameID returned by pcFrameBegin()
>> to the display thread ?---What version of Paracomp are you using
>> ?Regards -- ShreeGeorge Leaver wrote:   type=\"cite\">
>>
>>   Hi,Is it safe to make calls to the compositor from multiple
>> threads?The scenario is to have two threads: one for rendering, one
>> for display (if a display node):Thread 1 (render). All nodes have
>> this thread. ----------------------------------------------
>> pcSystemInitialize() pcSessionCreate() pcContextCreateMaster() (or
>> pcContextCreate()) while(1) { wait for render request
>> do_opengl_render(); if ( visible_framelet ) { pcFrameBegin( one
>> framelet x,y,w,h ); pcFrameAddFramelet( cbuf, zbuf ); pcFrameEnd();
>> } else { pcFrameBegin( no framelets ); pcFrameEnd(); } if ( master
>> ) request display (release thread 0) }Thread 0 (display). Only
>> master node has this thread.
>> ----------------------------------------------------- while(1) {
>> build scene graph request render (release thread 1) block until
>> display requested glClear(); pcFrameResultChannel( ...
>> &channelOut ); glDrawPixels( ..., channelOut.address ); }The
>> display thread can also use the pcFrameWaitOutputHP() extension to
>> loop over framelets.The problem we are seeing is that the
>> compositor is freeing invalid memory blocks in core.cpp:
>> Core::StartFrame() line 290: if (*iter2) free(*iter2)This doesn't
>> happen in the paracomp samples but they make all calls from the
>> same main thread. I know the above thread scheme is a little
>> contrived but we require a render/display thread model. Is it safe
>> to make pcFrameResultChannel calls from a thread that isn't doing
>> the pcFrameBegin/End() calls?Thanks in advance George-- George
>> Leaver Research Computing Services University of Manchester, UK.
> class=\"moz-txt-link-freetext\"
>>
> href=\"http://www.rcs.manchester.ac.uk\">http://www.rcs.manchester.ac.uk-------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge Build the coolest Linux based applications with Moblin
>> SDK & win great prizes Grand prize is a trip for two to an Open
>> Source event anywhere in the world  class=\"moz-txt-link-freetext\"
>>
> href=\"http://moblin-contest.org/redirect.php?banner_id=100&url=/\">http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________ Paracomp-devel
>> mailing list
> href=\"mailto:Par...@li...\">Par...@li...
>>
> href=\"https://lists.sourceforge.net/lists/listinfo/paracomp-devel\">https://lists.sourceforge.net/lists/listinfo/paracomp-devel
>> .
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK
> & win great prizes Grand prize is a trip for two to an Open Source
> event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________ Paracomp-devel
> mailing list Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
>
>   -- George Leaver Research Computing Services University of
> Manchester, UK.
> http://www.rcs.manchester.ac.uk-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK
> & win great prizes Grand prize is a trip for two to an Open Source
> event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________ Paracomp-devel
> mailing list Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel .
>



-- 
George Leaver
Research Computing Services
University of Manchester, UK.
http://www.rcs.manchester.ac.uk

Re: [Paracomp-devel] Accessing compositor from multiple threads

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi George,<br>
<br>
There's another way out too I think. The render thread can get the
pixel pointers (either using pcFrameResultChannel or WaitOutput) and
send them to the display thread. The pixel pointers will be valid till
the next FrameBegin(), so the display thread can draw the pixels before
it releases the render thread for the next frame. This approach has the
benefit of not changing the GL context in the threads.<br>
<br>
A request : can you file this as a bug in SourceForge so that I can
keep track of it ?<br>
<br>
Thanks<br>
-- Shree<br>
<br>
George Leaver wrote:
<blockquote
 cite="mid:200...@we..."
 type="cite">
  <pre wrap="">Hi Shree,

   Yes, the FrameID generate by pcFrameBegin() is used by
pcFrameResultChannel().
   I'm using rev72 from sourceforge. At least I now know the thread
model is, in principle, allowed.

   I suspect I need to modify the sample code (hello-depth) to use the
same thread model as below. Unfortunately I don't have any simple code
demonstrating this problem. I'll also have a go at writing the output
image to the display-thread's GL context at the end of the render loop
rather than from the display loop to keep all pc calls in one thread.

Regards,
George

Quoting Shree Kumar <a class="moz-txt-link-rfc2396E" href="mailto:shr...@hp...">&lt;shr...@hp...&gt;</a>:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi George,

Logically, a host represents a thread of execution. Each host has a
context object(PCcontext). Using the same context object simultaneously
from two threads will not work.

The scenario that you are describing ought to work (with the existing
implementation), since both threads aren't making paracomp calls at the
same time using the same object.

A quick sanity check (just to be sure) -- do you have a mechanism to
pass the FrameID returned by pcFrameBegin() to the display thread ?

---

What version of Paracomp are you using ?

Regards
-- Shree

George Leaver wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi,

   Is it safe to make calls to the compositor from multiple threads?

The scenario is to have two threads: one for rendering, one for
display (if a display node):

Thread 1 (render). All nodes have this thread.
----------------------------------------------
pcSystemInitialize()
pcSessionCreate()
pcContextCreateMaster() (or pcContextCreate())
while(1) {
   wait for render request
   do_opengl_render();
   if ( visible_framelet ) {
     pcFrameBegin( one framelet x,y,w,h );
     pcFrameAddFramelet( cbuf, zbuf );
     pcFrameEnd();
   }
   else {
     pcFrameBegin( no framelets );
     pcFrameEnd();
   }
   if ( master )
     request display (release thread 0)
}

Thread 0 (display). Only master node has this thread.
-----------------------------------------------------
while(1) {
    build scene graph
    request render (release thread 1)
    block until display requested
    glClear();
    pcFrameResultChannel( ... &amp;channelOut );
    glDrawPixels( ..., channelOut.address );
}

The display thread can also use the pcFrameWaitOutputHP() extension to
loop over framelets.

The problem we are seeing is that the compositor is freeing invalid
memory blocks in core.cpp: Core::StartFrame() line 290:
   if (*iter2)
     free(*iter2)

This doesn't happen in the paracomp samples but they make all calls
from the same main thread. I know the above thread scheme is a little
contrived but we require a render/display thread model. Is it safe to
make pcFrameResultChannel calls from a thread that isn't doing the
pcFrameBegin/End() calls?

Thanks in advance
George

--
George Leaver
Research Computing Services
University of Manchester, UK.
<a class="moz-txt-link-freetext" href="http://www.rcs.manchester.ac.uk">http://www.rcs.manchester.ac.uk</a>



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a>
_______________________________________________
Paracomp-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Par...@li...">Par...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/paracomp-devel">https://lists.sourceforge.net/lists/listinfo/paracomp-devel</a>
.


      </pre>
    </blockquote>
    <pre wrap="">
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a>
_______________________________________________
Paracomp-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Par...@li...">Par...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/paracomp-devel">https://lists.sourceforge.net/lists/listinfo/paracomp-devel</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->


--
George Leaver
Research Computing Services
University of Manchester, UK.
<a class="moz-txt-link-freetext" href="http://www.rcs.manchester.ac.uk">http://www.rcs.manchester.ac.uk</a>



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK &amp; win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a>
_______________________________________________
Paracomp-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Par...@li...">Par...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/paracomp-devel">https://lists.sourceforge.net/lists/listinfo/paracomp-devel</a>
.

  </pre>
</blockquote>
<br>
</body>
</html>

Re: [Paracomp-devel] Accessing compositor from multiple threads

[George L. <geo...@ma...>]

Hi Shree,

   Yes, the FrameID generate by pcFrameBegin() is used by  
pcFrameResultChannel().
   I'm using rev72 from sourceforge. At least I now know the thread  
model is, in principle, allowed.

   I suspect I need to modify the sample code (hello-depth) to use the  
same thread model as below. Unfortunately I don't have any simple code  
demonstrating this problem. I'll also have a go at writing the output  
image to the display-thread's GL context at the end of the render loop  
rather than from the display loop to keep all pc calls in one thread.

Regards,
George

Quoting Shree Kumar <shr...@hp...>:

> Hi George,
>
> Logically, a host represents a thread of execution. Each host has a
> context object(PCcontext). Using the same context object simultaneously
> from two threads will not work.
>
> The scenario that you are describing ought to work (with the existing
> implementation), since both threads aren't making paracomp calls at the
> same time using the same object.
>
> A quick sanity check (just to be sure) -- do you have a mechanism to
> pass the FrameID returned by pcFrameBegin() to the display thread ?
>
> ---
>
> What version of Paracomp are you using ?
>
> Regards
> -- Shree
>
> George Leaver wrote:
>> Hi,
>>
>>    Is it safe to make calls to the compositor from multiple threads?
>>
>> The scenario is to have two threads: one for rendering, one for
>> display (if a display node):
>>
>> Thread 1 (render). All nodes have this thread.
>> ----------------------------------------------
>> pcSystemInitialize()
>> pcSessionCreate()
>> pcContextCreateMaster() (or pcContextCreate())
>> while(1) {
>>    wait for render request
>>    do_opengl_render();
>>    if ( visible_framelet ) {
>>      pcFrameBegin( one framelet x,y,w,h );
>>      pcFrameAddFramelet( cbuf, zbuf );
>>      pcFrameEnd();
>>    }
>>    else {
>>      pcFrameBegin( no framelets );
>>      pcFrameEnd();
>>    }
>>    if ( master )
>>      request display (release thread 0)
>> }
>>
>> Thread 0 (display). Only master node has this thread.
>> -----------------------------------------------------
>> while(1) {
>>     build scene graph
>>     request render (release thread 1)
>>     block until display requested
>>     glClear();
>>     pcFrameResultChannel( ... &channelOut );
>>     glDrawPixels( ..., channelOut.address );
>> }
>>
>> The display thread can also use the pcFrameWaitOutputHP() extension to
>> loop over framelets.
>>
>> The problem we are seeing is that the compositor is freeing invalid
>> memory blocks in core.cpp: Core::StartFrame() line 290:
>>    if (*iter2)
>>      free(*iter2)
>>
>> This doesn't happen in the paracomp samples but they make all calls
>> from the same main thread. I know the above thread scheme is a little
>> contrived but we require a render/display thread model. Is it safe to
>> make pcFrameResultChannel calls from a thread that isn't doing the
>> pcFrameBegin/End() calls?
>>
>> Thanks in advance
>> George
>>
>> --
>> George Leaver
>> Research Computing Services
>> University of Manchester, UK.
>> http://www.rcs.manchester.ac.uk
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win   
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Paracomp-devel mailing list
>> Par...@li...
>> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
>> .
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Paracomp-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
>



-- 
George Leaver
Research Computing Services
University of Manchester, UK.
http://www.rcs.manchester.ac.uk

Re: [Paracomp-devel] Accessing compositor from multiple threads

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

Hi George,

Logically, a host represents a thread of execution. Each host has a 
context object(PCcontext). Using the same context object simultaneously 
from two threads will not work.

The scenario that you are describing ought to work (with the existing 
implementation), since both threads aren't making paracomp calls at the 
same time using the same object.

A quick sanity check (just to be sure) -- do you have a mechanism to 
pass the FrameID returned by pcFrameBegin() to the display thread ?

---

What version of Paracomp are you using ?

Regards
-- Shree

George Leaver wrote:
> Hi,
>
>    Is it safe to make calls to the compositor from multiple threads?
>
> The scenario is to have two threads: one for rendering, one for
> display (if a display node):
>
> Thread 1 (render). All nodes have this thread.
> ----------------------------------------------
> pcSystemInitialize()
> pcSessionCreate()
> pcContextCreateMaster() (or pcContextCreate())
> while(1) {
>    wait for render request
>    do_opengl_render();
>    if ( visible_framelet ) {
>      pcFrameBegin( one framelet x,y,w,h );
>      pcFrameAddFramelet( cbuf, zbuf );
>      pcFrameEnd();
>    }
>    else {
>      pcFrameBegin( no framelets );
>      pcFrameEnd();
>    }
>    if ( master )
>      request display (release thread 0)
> }
>
> Thread 0 (display). Only master node has this thread.
> -----------------------------------------------------
> while(1) {
>     build scene graph
>     request render (release thread 1)
>     block until display requested
>     glClear();
>     pcFrameResultChannel( ... &channelOut );
>     glDrawPixels( ..., channelOut.address );
> }
>
> The display thread can also use the pcFrameWaitOutputHP() extension to
> loop over framelets.
>
> The problem we are seeing is that the compositor is freeing invalid
> memory blocks in core.cpp: Core::StartFrame() line 290:
>    if (*iter2)
>      free(*iter2)
>
> This doesn't happen in the paracomp samples but they make all calls
> from the same main thread. I know the above thread scheme is a little
> contrived but we require a render/display thread model. Is it safe to
> make pcFrameResultChannel calls from a thread that isn't doing the
> pcFrameBegin/End() calls?
>
> Thanks in advance
> George
>
> --
> George Leaver
> Research Computing Services
> University of Manchester, UK.
> http://www.rcs.manchester.ac.uk
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Paracomp-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
> .
>
>   

[Paracomp-devel] Accessing compositor from multiple threads

[George L. <geo...@ma...>]

Hi,

   Is it safe to make calls to the compositor from multiple threads?

The scenario is to have two threads: one for rendering, one for  
display (if a display node):

Thread 1 (render). All nodes have this thread.
----------------------------------------------
pcSystemInitialize()
pcSessionCreate()
pcContextCreateMaster() (or pcContextCreate())
while(1) {
   wait for render request
   do_opengl_render();
   if ( visible_framelet ) {
     pcFrameBegin( one framelet x,y,w,h );
     pcFrameAddFramelet( cbuf, zbuf );
     pcFrameEnd();
   }
   else {
     pcFrameBegin( no framelets );
     pcFrameEnd();
   }
   if ( master )
     request display (release thread 0)
}

Thread 0 (display). Only master node has this thread.
-----------------------------------------------------
while(1) {
    build scene graph
    request render (release thread 1)
    block until display requested
    glClear();
    pcFrameResultChannel( ... &channelOut );
    glDrawPixels( ..., channelOut.address );
}

The display thread can also use the pcFrameWaitOutputHP() extension to  
loop over framelets.

The problem we are seeing is that the compositor is freeing invalid  
memory blocks in core.cpp: Core::StartFrame() line 290:
   if (*iter2)
     free(*iter2)

This doesn't happen in the paracomp samples but they make all calls  
from the same main thread. I know the above thread scheme is a little  
contrived but we require a render/display thread model. Is it safe to  
make pcFrameResultChannel calls from a thread that isn't doing the  
pcFrameBegin/End() calls?

Thanks in advance
George

-- 
George Leaver
Research Computing Services
University of Manchester, UK.
http://www.rcs.manchester.ac.uk

Re: [Paracomp-devel] Standard Alpha Blending problems

[James S P. <jam...@ma...>]

Hi Shree,

Shree Kumar wrote:

> However, I have had success in minimizing artifacts with 8 bit RGBA 
> buffers(looks like your current case). I was able to minimize artifacts 
> without reducing the number of planes or increasing the alpha.
> 
> I believe there is a precision issue with the blending function
> 
> glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ONE, 
> GL_ONE_MINUS_SRC_ALPHA)
> 
> while accumulating lots of slices when the alpha values are small (which 
> seems to be your case).
> 
> I had found that the following rendering approach reduces artifacts 
> significantly (to almost nil):


We tried this method but it seems to make no difference at all. I even 
substracting final images rendered with and without the method. I think 
we will try testing with higher precision buffers if only to confirm the 
problem. Unfortunately I don't have anymore time I can dedicate to this 
problem at the moment though we will surely come back to it in the near 
future.

BTW our SVA has FX3400 gfx cards.

Thanks for your help and support.
James
-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

Re: [Paracomp-devel] Standard Alpha Blending problems

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

Hi James,

James S Perrin wrote:
> 
> 
> I finished reading through
> http://www.ices.utexas.edu/ccv/papers/Smpark-VolVis02.pdf
> on the train home last night. It does point out a problem which it
> refers to as "Seam Planes" caused by very small alpha and colour values
> being multiplied together, but the result is too small to be
> accumulated. Their solution is essentially to decrease the number of
> planes and increase the alpha. I've tried this with several datasets but
> no matter how large the alpha I'm still seeing significant artefacts
> where a translucent part of a front frame is composited over a back
> frame.
> 

Must confess I haven't read that paper (though I intend to!).

However, I have had success in minimizing artifacts with 8 bit RGBA 
buffers(looks like your current case). I was able to minimize artifacts 
without reducing the number of planes or increasing the alpha.

I believe there is a precision issue with the blending function

glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ONE, 
GL_ONE_MINUS_SRC_ALPHA)

while accumulating lots of slices when the alpha values are small (which 
seems to be your case).

I had found that the following rendering approach reduces artifacts 
significantly (to almost nil):

   glClearColor(0,0,0,1); // note - alpha = 1 is important for eqn below!
   glClear(GL_COLOR_BUFFER_BIT);
   glEnable(GL_BLEND);
   glBlendFuncSeparateEXT(
     GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, // Color
     GL_ZERO, GL_ONE_MINUS_SRC_ALPHA); // Alpha

   /* draw slices back to front */

   /* draw a full screen quad to invert all alpha values */
   glColor4f(1,1,1,1);
   glBlendFunc(
        GL_ZERO, GL_ONE, // don't touch the color values
        GL_ONE_MINUS_DST_ALPHA, GL_ZERO); // alpha = (1-alpha)
   -- draw full screen quad to invert all pixel alpha values --

   -- add as framelet --

This approach computes the same alpha, but seems to provide better 
precision. In our rendering of the McMaster volume dataset, we were 
getting purple color artifacts where we were supposed to see blue. Using 
the above approach, we were able to eliminate the artifact.

--------

Another solution is to use 16/32 bit floating point RGBA pbuffers for 
rendering. Alternatively, you could use Framebuffer objects as well. 
These features may/may not be available depending on your graphics card 
(what graphics card is on your systems, BTW?).

Note that using higher precision buffers _immediately_ solves most 
precision issues. However, the price to pay is performance :-)

>>
>> This is the hard way, but gives results at times.
> 
> OK I thing we can do this without too much trouble I'll have a go next week.

Ok.

Regards
-- Shree

Re: [Paracomp-devel] Standard Alpha Blending problems

[James S P. <jam...@ma...>]

Hi Shree,

Shree Kumar wrote:

> Other than that - I hope you are computing the "order" numbers right. 
> This is the last parameter of pcFrameBegin().

We know when we've done that things look really silly! :)

> The .PNG images you sent - are they your current images ?

Yes.

I finished reading through 
http://www.ices.utexas.edu/ccv/papers/Smpark-VolVis02.pdf
on the train home last night. It does point out a problem which it 
refers to as "Seam Planes" caused by very small alpha and colour values 
being multiplied together, but the result is too small to be 
accumulated. Their solution is essentially to decrease the number of 
planes and increase the alpha. I've tried this with several datasets but 
no matter how large the alpha I'm still seeing significant artefacts 
where a translucent part of a front frame is composited over a back 
frame.

> -----
> 
> I find that single node debugging works better sometimes. One debugging 
> method I have found useful is the following --
> 
> 1. Load the full volume on a single node
> 2. Clear.
> 3. Render half the volume back to front (the farther from the eye part)
> 4. Render the other half of the volume back to front.
> 5. save the image
> 6. Clear & do (3), save image
> 7. Clear & do (4), save image
> 8. Manually blend (using OpenGL) 6 & 7. Compare the result with (5).
> 
> This is the hard way, but gives results at times.

OK I thing we can do this without too much trouble I'll have a go next week.

Thanks,
James

-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

Re: [Paracomp-devel] Standard Alpha Blending problems

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

Hi James,

James S Perrin wrote:
> Hi Shree,
> 
>         A demo app would definitely be nice especially as alpha blending's main
> use will be volume rendering.
> 
>         I looked at Budapest's code last week. To be honest everything is
> abstracted by several layers of API, the PC code I think is accessed in
> the parallel-mingle code so it was quite hard to find what state
> everything is actually being set to.
> 
>         I couldn't find anything though that differed from the instructions in
> the PC docs and hello_alpha demo.

That's a good case for minimalistic volume rendering code. I have some 
code which needs to be beaten into shape. I'll convert that to a sample. 
But can't say at the moment when that will be ready. So let me see how I 
can help you debug the problem :-)

> 
>         One difference from the demos and texturevr is that we're using GLX not
> GLUT. I note that for GLUT you need to use GLUT_RGBA and GLUT_ALPHA for
> alpha compositing to work. There is no direct equivalent in GLX however
> we do set the buffer sizes:
> 
>      attrib[i++] = GLX_RGBA;
>      attrib[i++] = GLX_RED_SIZE;   attrib[i++] = 1;
>      attrib[i++] = GLX_GREEN_SIZE; attrib[i++] = 1;
>      attrib[i++] = GLX_BLUE_SIZE;  attrib[i++] = 1;
>      if ( alpha_compositing() ) {
>        attrib[i++] = GLX_ALPHA_SIZE; attrib[i++] = 1;
>      }
>      else {
>        attrib[i++] = GLX_DEPTH_SIZE; attrib[i++] = 1;
>      }
>      attrib[i++] = GLX_DOUBLEBUFFER;
>      attrib[i++] = None;

This seems fine.

> 
> On the renders:
>   glClearColor( 0., 0., 0., 0. );
>   glClear( GL_COLOR_BUFFER_BIT );
> 
>   glBlendFuncSeparateEXT(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
>         GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
>   glEnable(GL_BLEND);
> 
>   Render the volume using Back to Front textures.
> 
>   pcFrameAddGLFrameletEXT();
> 
> On the master:
>   glClearColor( 0., 0., 0., 0. );
>   glClear( GL_COLOR_BUFFER_BIT );
>   pcFrameResult();
>   glDisable(GL_BLEND);
>   glDrawPixels();

I don't see a problem with the steps you have shown here. Essentially 
you are following the same steps as in the "hello-alpha" program, but 
replacing the rendering with your back to front rendering.

Other than that - I hope you are computing the "order" numbers right. 
This is the last parameter of pcFrameBegin().

The .PNG images you sent - are they your current images ?

-----

I find that single node debugging works better sometimes. One debugging 
method I have found useful is the following --

1. Load the full volume on a single node
2. Clear.
3. Render half the volume back to front (the farther from the eye part)
4. Render the other half of the volume back to front.
5. save the image
6. Clear & do (3), save image
7. Clear & do (4), save image
8. Manually blend (using OpenGL) 6 & 7. Compare the result with (5).

This is the hard way, but gives results at times.

Regards
-- Shree

Re: [Paracomp-devel] Standard Alpha Blending problems

[James S P. <jam...@ma...>]

Hi Shree,

	A demo app would definitely be nice especially as alpha blending's main 
use will be volume rendering.

	I looked at Budapest's code last week. To be honest everything is 
abstracted by several layers of API, the PC code I think is accessed in 
the parallel-mingle code so it was quite hard to find what state 
everything is actually being set to.

	I couldn't find anything though that differed from the instructions in 
the PC docs and hello_alpha demo.

	One difference from the demos and texturevr is that we're using GLX not 
GLUT. I note that for GLUT you need to use GLUT_RGBA and GLUT_ALPHA for 
alpha compositing to work. There is no direct equivalent in GLX however 
we do set the buffer sizes:

     attrib[i++] = GLX_RGBA;
     attrib[i++] = GLX_RED_SIZE;   attrib[i++] = 1;
     attrib[i++] = GLX_GREEN_SIZE; attrib[i++] = 1;
     attrib[i++] = GLX_BLUE_SIZE;  attrib[i++] = 1;
     if ( alpha_compositing() ) {
       attrib[i++] = GLX_ALPHA_SIZE; attrib[i++] = 1;
     }
     else {
       attrib[i++] = GLX_DEPTH_SIZE; attrib[i++] = 1;
     }
     attrib[i++] = GLX_DOUBLEBUFFER;
     attrib[i++] = None;

On the renders:
  glClearColor( 0., 0., 0., 0. );
  glClear( GL_COLOR_BUFFER_BIT );

  glBlendFuncSeparateEXT(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
	GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
  glEnable(GL_BLEND);

  Render the volume using Back to Front textures.

  pcFrameAddGLFrameletEXT();

On the master:
  glClearColor( 0., 0., 0., 0. );
  glClear( GL_COLOR_BUFFER_BIT );
  pcFrameResult();
  glDisable(GL_BLEND);
  glDrawPixels();

Regards
James
	

Shree Kumar wrote:
> Hi James,
> 
> (Given the confusion) Do you think it would be a good idea to have a 
> minimal volume rendering app ? The sample can assume that the volume 
> does not rotate & doesn't have to deal with slicing.  It can just render 
> a stack of alpha blended polygons which illustrates how volume rendering 
> can work.
> 
> BTW, TU Budapest's source code is available. So you can cross check with 
> that one. The texture rendering source is at
> 
> http://paracomp.svn.sourceforge.net/viewvc/paracomp/branches/developer/domi/demos/texturevr/
> 
> I think updated versions of the volume rendering app are available as 
> well at http://amon.ik.bme.hu/texturevr . TU Budapest's other apps are 
> at http://amon.ik.bme.hu/. Note that source code, documentation and 
> packages (including dependencies) are all available from that link.
> 
> HTH
> -- Shree
> 
> James S Perrin wrote:
>> Hi Shree,
>>
>> I've gone back to the CEI documentation which had a couple of useful
>> links about alpha compositing.
>>
>> http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Volume%20Rendering/Interactive%20Texture-Based%20Volume%20Rendering%20for%20Large%20Data%20Sets.pdf
>> http://www.ices.utexas.edu/ccv/papers/Smpark-VolVis02.pdf
>>
>> Shree Kumar wrote:
>>
>>> Now I'm confused. Can you elaborate on what you mean by "only two inputs
>>> can be composited in a single OVER operation" ?
>> I would disregard most of what I've said before as it appears my
>> understanding of what was going on was badly floored and the alpha
>> compositing code is most likely correct, sorry. After all Budapest seem
>> to be able to get it to work!
>>
>> The issue that the composited image is wrong still stands.
>>
>>>>> Currently, I don't see anybody using the broken alpha value. So I see it
>>>>> safe to fix this. Fixing this won't break existing apps either...
>>>> Looking a the code in compositecpu.cpp we're confused again as it
>>>> actaully looks like more like glBlend(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
>>>> as the src values are not mutliplied by SRC_ALPHA?
>>> Oop! Sorry. I missed mentioning that glBlendFunc(GL_SRC_ALPHA,
>>> GL_ONE_MINUS_SRC_ALPHA) is the intended operator.
>>>
>>> Since we expect premultiplied alpha values, we effectively implement
>>> glBlendFuncSeparate(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).
>> Yes, having just read the above papers that became apparent.
>>
>>> (So does that mean the final alpha would be correct if the initial
>>> alphas are correct ? Apologies for creating more confusion. I'm a bit
>>> confused myself at this point. So let me check this again and get back
>>> to you.)
>>>
>>> (Note to self: some documentation is in order here!)
>> Erm yeah, that's why I went back the the CEI docs :)
>>
>>> Looks like the Gimp approach may not work...
>> I tried gimp and the composited image was wrong but a different wrong
>> than the PC output.
>>
>> Thanks for your help,
>> James
>>
>> --
>> ------------------------------------------------------------------------
>>    James S. Perrin
>>    Visualization
>>
>>    Research Computing Services
>>    The University of Manchester
>>    Kilburn Building, Oxford Road
>>    Manchester, M13 9PL
>>
>>    t: +44 (0) 161 275 6945
>>    e: jam...@ma...
>>    w: www.manchester.ac.uk/researchcomputing
>> ------------------------------------------------------------------------
>>   "The test of intellect is the refusal to belabour the obvious"
>>   - Alfred Bester
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Paracomp-devel mailing list
>> Par...@li...
>> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
>> .
>>
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Paracomp-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel

-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

Re: [Paracomp-devel] Standard Alpha Blending problems

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

Hi James,

(Given the confusion) Do you think it would be a good idea to have a 
minimal volume rendering app ? The sample can assume that the volume 
does not rotate & doesn't have to deal with slicing.  It can just render 
a stack of alpha blended polygons which illustrates how volume rendering 
can work.

BTW, TU Budapest's source code is available. So you can cross check with 
that one. The texture rendering source is at

http://paracomp.svn.sourceforge.net/viewvc/paracomp/branches/developer/domi/demos/texturevr/

I think updated versions of the volume rendering app are available as 
well at http://amon.ik.bme.hu/texturevr . TU Budapest's other apps are 
at http://amon.ik.bme.hu/. Note that source code, documentation and 
packages (including dependencies) are all available from that link.

HTH
-- Shree

James S Perrin wrote:
> Hi Shree,
> 
> I've gone back to the CEI documentation which had a couple of useful
> links about alpha compositing.
> 
> http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Volume%20Rendering/Interactive%20Texture-Based%20Volume%20Rendering%20for%20Large%20Data%20Sets.pdf
> http://www.ices.utexas.edu/ccv/papers/Smpark-VolVis02.pdf
> 
> Shree Kumar wrote:
> 
>> Now I'm confused. Can you elaborate on what you mean by "only two inputs
>> can be composited in a single OVER operation" ?
> 
> I would disregard most of what I've said before as it appears my
> understanding of what was going on was badly floored and the alpha
> compositing code is most likely correct, sorry. After all Budapest seem
> to be able to get it to work!
> 
> The issue that the composited image is wrong still stands.
> 
>>>> Currently, I don't see anybody using the broken alpha value. So I see it
>>>> safe to fix this. Fixing this won't break existing apps either...
>>> Looking a the code in compositecpu.cpp we're confused again as it
>>> actaully looks like more like glBlend(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
>>> as the src values are not mutliplied by SRC_ALPHA?
>> Oop! Sorry. I missed mentioning that glBlendFunc(GL_SRC_ALPHA,
>> GL_ONE_MINUS_SRC_ALPHA) is the intended operator.
>>
>> Since we expect premultiplied alpha values, we effectively implement
>> glBlendFuncSeparate(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).
> 
> Yes, having just read the above papers that became apparent.
> 
>> (So does that mean the final alpha would be correct if the initial
>> alphas are correct ? Apologies for creating more confusion. I'm a bit
>> confused myself at this point. So let me check this again and get back
>> to you.)
>>
>> (Note to self: some documentation is in order here!)
> 
> Erm yeah, that's why I went back the the CEI docs :)
> 
>> Looks like the Gimp approach may not work...
> 
> I tried gimp and the composited image was wrong but a different wrong
> than the PC output.
> 
> Thanks for your help,
> James
> 
> --
> ------------------------------------------------------------------------
>    James S. Perrin
>    Visualization
> 
>    Research Computing Services
>    The University of Manchester
>    Kilburn Building, Oxford Road
>    Manchester, M13 9PL
> 
>    t: +44 (0) 161 275 6945
>    e: jam...@ma...
>    w: www.manchester.ac.uk/researchcomputing
> ------------------------------------------------------------------------
>   "The test of intellect is the refusal to belabour the obvious"
>   - Alfred Bester
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Paracomp-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
> .
> 

Re: [Paracomp-devel] Standard Alpha Blending problems

[James S P. <jam...@ma...>]

Hi Shree,

I've gone back to the CEI documentation which had a couple of useful 
links about alpha compositing.

http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Volume%20Rendering/Interactive%20Texture-Based%20Volume%20Rendering%20for%20Large%20Data%20Sets.pdf
http://www.ices.utexas.edu/ccv/papers/Smpark-VolVis02.pdf

Shree Kumar wrote:

> Now I'm confused. Can you elaborate on what you mean by "only two inputs 
> can be composited in a single OVER operation" ?

I would disregard most of what I've said before as it appears my 
understanding of what was going on was badly floored and the alpha 
compositing code is most likely correct, sorry. After all Budapest seem 
to be able to get it to work!

The issue that the composited image is wrong still stands.

>>> Currently, I don't see anybody using the broken alpha value. So I see it
>>> safe to fix this. Fixing this won't break existing apps either...
>> Looking a the code in compositecpu.cpp we're confused again as it
>> actaully looks like more like glBlend(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
>> as the src values are not mutliplied by SRC_ALPHA?
> 
> Oop! Sorry. I missed mentioning that glBlendFunc(GL_SRC_ALPHA, 
> GL_ONE_MINUS_SRC_ALPHA) is the intended operator.
> 
> Since we expect premultiplied alpha values, we effectively implement
> glBlendFuncSeparate(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).

Yes, having just read the above papers that became apparent.

> (So does that mean the final alpha would be correct if the initial 
> alphas are correct ? Apologies for creating more confusion. I'm a bit 
> confused myself at this point. So let me check this again and get back 
> to you.)
> 
> (Note to self: some documentation is in order here!)

Erm yeah, that's why I went back the the CEI docs :)

> Looks like the Gimp approach may not work...

I tried gimp and the composited image was wrong but a different wrong 
than the PC output.

Thanks for your help,
James

-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

Re: [Paracomp-devel] Standard Alpha Blending problems

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

Hi James,

James S Perrin wrote:
>>>
>> Your conclusions about "incorrect Alphas" and "incorrect image" are spot
>> on. Alpha values you get out of the operation from Paracomp will not be
>> correct.
>>
>> If you use ParaComp to do (I0+I1+I2+I3) in one swoop, then you'll get
>> the right image, but wrong alpha values again.
> 
> We're not using the final resultant alpha. But to me it seems necessary
> to preserve it throughout the compositing procedure since only two
> inputs can be composited in a single OVER operation.
> 

Now I'm confused. Can you elaborate on what you mean by "only two inputs 
can be composited in a single OVER operation" ?

>> The right thing to do seems to be to fix Paracomp. Will changing
>> ParaComp's blending function from the current (faulty) equation
>>
>>   glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
>>
>> to an equivalent of
>>
>>   glBlendFuncSeparateEXT(
>>     GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
>>     GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
>>
>> work for you ?
>>
>> Currently, I don't see anybody using the broken alpha value. So I see it
>> safe to fix this. Fixing this won't break existing apps either...
> 
> Looking a the code in compositecpu.cpp we're confused again as it
> actaully looks like more like glBlend(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
> as the src values are not mutliplied by SRC_ALPHA?

Oop! Sorry. I missed mentioning that glBlendFunc(GL_SRC_ALPHA, 
GL_ONE_MINUS_SRC_ALPHA) is the intended operator.

Since we expect premultiplied alpha values, we effectively implement
glBlendFuncSeparate(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).

(So does that mean the final alpha would be correct if the initial 
alphas are correct ? Apologies for creating more confusion. I'm a bit 
confused myself at this point. So let me check this again and get back 
to you.)

(Note to self: some documentation is in order here!)

> 
>>> I forgot to say we also see that translucent parts of the front image
>>> that are composited against "nothing" in the rear image are being
>>> attenuated.
>> That's interesting.  Could be a bug. I'll look at this. Images, if you
>> can send them, will be useful.
> 
> This has been sorted. Blending was enabled in old code that was trying
> to support coloured backgrounds, similar to what Stefan has talked
> about,  when the frameresult was passed to gldrawpixels.
> 
Ok. Good to know that.

> Anyway the RGBA images are attached. I haven't tried the gimp thing yet.
> 

Looks like the Gimp approach may not work...

Regards
-- Shree

> Regards
> James
> 
> --
> ------------------------------------------------------------------------
>    James S. Perrin
>    Visualization
> 
>    Research Computing Services
>    The University of Manchester
>    Kilburn Building, Oxford Road
>    Manchester, M13 9PL
> 
>    t: +44 (0) 161 275 6945
>    e: jam...@ma...
>    w: www.manchester.ac.uk/researchcomputing
> ------------------------------------------------------------------------
>   "The test of intellect is the refusal to belabour the obvious"
>   - Alfred Bester
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 

Re: [Paracomp-devel] Standard Alpha Blending problems

[James S P. <jam...@ma...>]

Hi Shree,

Shree Kumar wrote:
> Hi James,
> 
> James S Perrin wrote:
>> Shree Kumar wrote:
>> This is what we don't understand. If presumably intermediate images
>> generated from an over operation will be used in a subsequent operation
>> and therefore the alpha needs to be maintained.
>>
>> If you have input images F0-3 then lets assume F0 OVER F1 and F2 OVER F3
>> producing intermediate images iF0 and iF1 to produce the final composite
>>    we need iF0 OVER iF1 however if Alpha is not preserved by the
>> operator iF0 and iF1 will not have the correct alpha values for the
>> final operation?
>>
>> I0 + I1  I2 + I3    <-- correct Alphas
>>    \ /      \ /
>>    iF0   +  iF1      <-- incorrect Alphas?
>>       \    /
>>       Output         <-- incorrect image?
>>
> 
> Your conclusions about "incorrect Alphas" and "incorrect image" are spot 
> on. Alpha values you get out of the operation from Paracomp will not be 
> correct.
> 
> If you use ParaComp to do (I0+I1+I2+I3) in one swoop, then you'll get 
> the right image, but wrong alpha values again.

We're not using the final resultant alpha. But to me it seems necessary 
to preserve it throughout the compositing procedure since only two 
inputs can be composited in a single OVER operation.

> The right thing to do seems to be to fix Paracomp. Will changing 
> ParaComp's blending function from the current (faulty) equation
> 
>   glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
> 
> to an equivalent of
> 
>   glBlendFuncSeparateEXT(
>     GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
>     GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
> 
> work for you ?
> 
> Currently, I don't see anybody using the broken alpha value. So I see it 
> safe to fix this. Fixing this won't break existing apps either...

Looking a the code in compositecpu.cpp we're confused again as it 
actaully looks like more like glBlend(GL_ONE, GL_ONE_MINUS_SRC_ALPHA); 
as the src values are not mutliplied by SRC_ALPHA?

>> I forgot to say we also see that translucent parts of the front image
>> that are composited against "nothing" in the rear image are being
>> attenuated.
> 
> That's interesting.  Could be a bug. I'll look at this. Images, if you 
> can send them, will be useful.

This has been sorted. Blending was enabled in old code that was trying 
to support coloured backgrounds, similar to what Stefan has talked 
about,  when the frameresult was passed to gldrawpixels.

Anyway the RGBA images are attached. I haven't tried the gimp thing yet.

Regards
James

-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

Re: [Paracomp-devel] Standard Alpha Blending problems

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

Hi James,

James S Perrin wrote:
> Shree Kumar wrote:
> This is what we don't understand. If presumably intermediate images
> generated from an over operation will be used in a subsequent operation
> and therefore the alpha needs to be maintained.
> 
> If you have input images F0-3 then lets assume F0 OVER F1 and F2 OVER F3
> producing intermediate images iF0 and iF1 to produce the final composite
>    we need iF0 OVER iF1 however if Alpha is not preserved by the
> operator iF0 and iF1 will not have the correct alpha values for the
> final operation?
> 
> I0 + I1  I2 + I3    <-- correct Alphas
>    \ /      \ /
>    iF0   +  iF1      <-- incorrect Alphas?
>       \    /
>       Output         <-- incorrect image?
> 

Your conclusions about "incorrect Alphas" and "incorrect image" are spot 
on. Alpha values you get out of the operation from Paracomp will not be 
correct.

If you use ParaComp to do (I0+I1+I2+I3) in one swoop, then you'll get 
the right image, but wrong alpha values again.

The right thing to do seems to be to fix Paracomp. Will changing 
ParaComp's blending function from the current (faulty) equation

  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

to an equivalent of

  glBlendFuncSeparateEXT(
    GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
    GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

work for you ?

Currently, I don't see anybody using the broken alpha value. So I see it 
safe to fix this. Fixing this won't break existing apps either...

> I forgot to say we also see that translucent parts of the front image
> that are composited against "nothing" in the rear image are being
> attenuated.

That's interesting.  Could be a bug. I'll look at this. Images, if you 
can send them, will be useful.

Regards
-- Shree

Re: [Paracomp-devel] Standard Alpha Blending problems

[James S P. <jam...@ma...>]

Hi Shree,

Shree Kumar wrote:

>> However when we looked at the PClib compositing code it was performing
>> the same operation on both RGB *and* Alpha, I presume the equivalent of:
>>
>> glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
>>
> 
> That's right. Paracomp's alpha blending was written to mimic base OpenGL 
> directly.
> 
> With this blending function, the composited color values come out right. 
> But the composited alpha value is incorrect. So you can't use the final 
> alpha. This is a drawback of Paracomp compositing. I sometimes veer to 
> the opinion that this is a bug that needs to be fixed.

This is what we don't understand. If presumably intermediate images 
generated from an over operation will be used in a subsequent operation 
and therefore the alpha needs to be maintained.

If you have input images F0-3 then lets assume F0 OVER F1 and F2 OVER F3 
producing intermediate images iF0 and iF1 to produce the final composite 
   we need iF0 OVER iF1 however if Alpha is not preserved by the 
operator iF0 and iF1 will not have the correct alpha values for the 
final operation?

I0 + I1  I2 + I3    <-- correct Alphas
   \ /      \ /
   iF0   +  iF1      <-- incorrect Alphas?
      \    /
      Output         <-- incorrect image?

>> When we changed the operator to "preserve alpha" by explicitly
>> performing the equivalent of:
>>
>>         glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)
>>
>> on the alpha value we got the correct result!?
> 
> You mean you changed the paracomp operator itself ? I have no 
> explanation at the moment about why this worked.
> 
> Can you describe the method by which you are rendering the volume on 
> every host ?

We are using Back-to-Front Texture rendering. The RGBA texture slices 
are Axis aligned to X, Y or Z depending on the view orientation (we know 
screen aligned is better but this is direct port of the serial code).

>> Attached are some images showing the problem, render0 and render1 are
>> the inputs and composite the output. The problem can specifically seen
>> in the blue halo which doesn't show the expected smooth progression
>> across the volume.
>>
> 
> The images are missing the alpha channel, since .JPG cannot take them. 
> To help debugging this, we'll need the alpha values.
> 
> Can you create .PNG files with an alpha channel and send them across ?
> 

I will try to do this shortly. Thanks for the code.

I forgot to say we also see that translucent parts of the front image 
that are composited against "nothing" in the rear image are being 
attenuated.

Regards
James
-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

Re: [Paracomp-devel] Standard Alpha Blending problems

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

Hi James,

James S Perrin wrote:
> Hi,
>         We've run into some problems using alpha blending for HW volume
> rendering. We've been carefully through our code an everything seems
> correct. Each render is using the recommended glBlend function:
> 
> glBlendFuncSeparateEXT(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
>                  GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
> 
> This is necessary to preserve the correct alpha value, correct?

Yes.

> 
> However when we looked at the PClib compositing code it was performing
> the same operation on both RGB *and* Alpha, I presume the equivalent of:
> 
> glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
> 

That's right. Paracomp's alpha blending was written to mimic base OpenGL 
directly.

With this blending function, the composited color values come out right. 
But the composited alpha value is incorrect. So you can't use the final 
alpha. This is a drawback of Paracomp compositing. I sometimes veer to 
the opinion that this is a bug that needs to be fixed.

> When we changed the operator to "preserve alpha" by explicitly
> performing the equivalent of:
> 
>         glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)
> 
> on the alpha value we got the correct result!?

You mean you changed the paracomp operator itself ? I have no 
explanation at the moment about why this worked.

Can you describe the method by which you are rendering the volume on 
every host ?

> 
>         Since other people have done alpha blending we had assumed it was our
> code that is wrong or at least we were passing incorrect data. Can
> someone explain where the mistake is? Are we just correcting for our
> error by changing the compositor operation?
> 

The key to getting the right results is to generate the right alpha 
value on each host. But I can't say more till you tell us how you are 
rendering sub-volumes on each host.

If you are drawing slicing planes in a back-to-front order, then using 
the above equation should work.

> Attached are some images showing the problem, render0 and render1 are
> the inputs and composite the output. The problem can specifically seen
> in the blue halo which doesn't show the expected smooth progression
> across the volume.
> 

The images are missing the alpha channel, since .JPG cannot take them. 
To help debugging this, we'll need the alpha values.

Can you create .PNG files with an alpha channel and send them across ?

I've attached some source code (pngfile.cpp) which will help you write 
png files. Note that you'll have to readback RGBA values and feed that 
array to the WritePNG function.

As an aside --you can actually use an image editor like GIMP to see the 
final result of the compositing, as follows --
   - Dump .PNG files with alpha channels from all the hosts
   - import each of them as a layer in GIMP, and
   - arrange the layers with the nearest one on top

If your program works you won't need this, but it's an easy debugging tool.

HTH
-- Shree

[Paracomp-devel] Standard Alpha Blending problems

[James S P. <jam...@ma...>]

Hi,
	We've run into some problems using alpha blending for HW volume 
rendering. We've been carefully through our code an everything seems 
correct. Each render is using the recommended glBlend function:

glBlendFuncSeparateEXT(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
		 GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

This is necessary to preserve the correct alpha value, correct?

However when we looked at the PClib compositing code it was performing 
the same operation on both RGB *and* Alpha, I presume the equivalent of:

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

When we changed the operator to "preserve alpha" by explicitly 
performing the equivalent of:

	glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)

on the alpha value we got the correct result!?

	Since other people have done alpha blending we had assumed it was our 
code that is wrong or at least we were passing incorrect data. Can 
someone explain where the mistake is? Are we just correcting for our 
error by changing the compositor operation?

Attached are some images showing the problem, render0 and render1 are 
the inputs and composite the output. The problem can specifically seen 
in the blue halo which doesn't show the expected smooth progression 
across the volume.

Regards
James


-- 
------------------------------------------------------------------------
   James S. Perrin
   Visualization

   Research Computing Services
   The University of Manchester
   Kilburn Building, Oxford Road
   Manchester, M13 9PL

   t: +44 (0) 161 275 6945
   e: jam...@ma...
   w: www.manchester.ac.uk/researchcomputing
------------------------------------------------------------------------
  "The test of intellect is the refusal to belabour the obvious"
  - Alfred Bester
------------------------------------------------------------------------

[Paracomp-devel] Alpha Blending for Equalizer (WAS: Crash in pcSystemFinalize)

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

Hi Max,

Maxim Makhinya wrote:
> Thanks for patch, looks like it works well.
>   
That's good to know.
> Here are numbers I've got on my G5 (ppc) (-O2 was used).
> I used two sets of images: images from test directory
> and randomly created images of the same size. Reason for
> this is that resulted image after blending from initial
> images is completely empty, that means CPU prediction
> of results for "if" statements will always work and in
> the end it could work faster (it looks from numbers
> that it actually happens):
>
>   
That's a good idea if there are "if" statements in the compositing. I've 
seen
 people have a preferrence for "level/predictable" performance, but
that's another story.
>
> I included patch in revision 1917 but left paracomp blending
> compositing disabled since it works slower for me. Maybe
> results on "intel" will be different so we can enable it, that
> needs some more testing.
>
>   
The performance difference shouldn't be too difficult to fix now. 
Basically on PPC
you are running the generic CPU code for compositing in Paracomp. This 
uses a
 look up table. A 64k lookup table is not good with today's technology &
compilers :-) I'll intimate you when I fix the performance. Then maybe you
 can can give it another try.

With x86_64, the alpha blending is much faster with the SSE3 code we 
use. I'll report
some results to you once I try out this version.

Cheers
-- Shree
>
> On May 20, 2008, at 7:06 AM, Shree Kumar wrote:
>
>   
>> Hi Stefan/Max,
>>
>> I've created a temporary extension PC_COMP_ALPHA_SORT2_HP which
>> provides the alpha blending support you need.
>>
>> The specifics of the extension may change later, but the changes
>> will be easy to make. Changes are in SVN - just update to get them.
>> The
>> test_compositeEXT sample is changed to show how to use the extension.
>>
>> Plus, attached is a patch which uses the new alpha blending
>> capability inside equalizer (includes a small change in the test
>> program too).
>>
>> Do let me know if the patch works for you. You'd want to check it
>> with the actual application (eVolve) too - to keep away blending
>> surprises ;-)
>>
>> Cheers
>> -- Shree
>>
>> Kumar, Shree (STSD) wrote:
>>     
>>> I just updated my sandbox to get the changes. I think it's fairly
>>> easy to add support
>>> for the sort of compositing you are looking for. I had a good look
>>> at the code : changing the blending equation
>>> is quite easy in the C code. In the assembly language code for
>>> x86_64, the number/type of instructions remain the same :-)
>>>
>>> Quick preliminary tests on my x86_64 desktop (these are with the
>>> wrong blending equation, but I expect the same to
>>> hold on the correct blending equation too)
>>> ------ Without Paracomp ------
>>> ./Linux/test: Alpha first op:  66.7899 ms (394.778 MB/s)
>>> ./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s)
>>> ./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s)
>>> -------- With Paracomp ---------
>>> ./Linux/test: Alpha first op:  40.5636 ms (650.021 MB/s)
>>> ./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s)
>>> ./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s)
>>> --------------------------------------
>>>
>>> Small note : test.cpp isn't using alpha blending in the "Alpha 15
>>> images" case. This is due to a missing "true" parameter to
>>>  assembleFramesCPU. In line 108, you need to add a true param to
>>> assembleFramesCPU()
>>>
>>> I'll change the blending function as an experiment on monday & send
>>> you some patches.
>>>
>>> Note to myself : How to provide the same functionality as a
>>> standardized function in paracomp.
>>>
>>> Cheers
>>> -- Shree
>>>       
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Paracomp-devel mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/paracomp-devel
> .
>
>   

Re: [Paracomp-devel] Crash in pcSystemFinalize

[Maxim M. <mak...@if...>]

Thanks for patch, looks like it works well.


Here are numbers I've got on my G5 (ppc) (-O2 was used).
I used two sets of images: images from test directory
and randomly created images of the same size. Reason for
this is that resulted image after blending from initial
images is completely empty, that means CPU prediction
of results for "if" statements will always work and in
the end it could work faster (it looks from numbers
that it actually happens):


Images in test directory
--- with Paracomp ---
./Darwin/test: Alpha first op:  108.974 ms (241.959 MB/s)
./Darwin/test: Alpha second op: 105.008 ms (251.097 MB/s)
./Darwin/test: Alpha 15 images: 672.45 ms (196.053 MB/s)

-- without ---
./Darwin/test: Alpha first op:  104.519 ms (252.272 MB/s)
./Darwin/test: Alpha second op: 88.7426 ms (297.12 MB/s)
./Darwin/test: Alpha 15 images: 494.496 ms (266.607 MB/s)


My "random" images
--- with Paracomp ---
./Darwin/test: Alpha first op:  114.453 ms (230.376 MB/s)
./Darwin/test: Alpha second op: 123.207 ms (214.008 MB/s)
./Darwin/test: Alpha 15 images: 800.529 ms (164.686 MB/s)

-- without ---
./Darwin/test: Alpha first op:  115.309 ms (228.666 MB/s)
./Darwin/test: Alpha second op: 82.4361 ms (319.85 MB/s)
./Darwin/test: Alpha 15 images: 613.568 ms (214.868 MB/s)


I included patch in revision 1917 but left paracomp blending
compositing disabled since it works slower for me. Maybe
results on "intel" will be different so we can enable it, that
needs some more testing.


Regards,

Max




On May 20, 2008, at 7:06 AM, Shree Kumar wrote:

> Hi Stefan/Max,
>
> I've created a temporary extension PC_COMP_ALPHA_SORT2_HP which  
> provides the alpha blending support you need.
>
> The specifics of the extension may change later, but the changes  
> will be easy to make. Changes are in SVN - just update to get them.  
> The
> test_compositeEXT sample is changed to show how to use the extension.
>
> Plus, attached is a patch which uses the new alpha blending  
> capability inside equalizer (includes a small change in the test  
> program too).
>
> Do let me know if the patch works for you. You'd want to check it  
> with the actual application (eVolve) too - to keep away blending  
> surprises ;-)
>
> Cheers
> -- Shree
>
> Kumar, Shree (STSD) wrote:
>>
>> I just updated my sandbox to get the changes. I think it's fairly  
>> easy to add support
>> for the sort of compositing you are looking for. I had a good look  
>> at the code : changing the blending equation
>> is quite easy in the C code. In the assembly language code for  
>> x86_64, the number/type of instructions remain the same :-)
>>
>> Quick preliminary tests on my x86_64 desktop (these are with the  
>> wrong blending equation, but I expect the same to
>> hold on the correct blending equation too)
>> ------ Without Paracomp ------
>> ./Linux/test: Alpha first op:  66.7899 ms (394.778 MB/s)
>> ./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s)
>> ./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s)
>> -------- With Paracomp ---------
>> ./Linux/test: Alpha first op:  40.5636 ms (650.021 MB/s)
>> ./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s)
>> ./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s)
>> --------------------------------------
>>
>> Small note : test.cpp isn't using alpha blending in the "Alpha 15  
>> images" case. This is due to a missing "true" parameter to
>>  assembleFramesCPU. In line 108, you need to add a true param to  
>> assembleFramesCPU()
>>
>> I'll change the blending function as an experiment on monday & send  
>> you some patches.
>>
>> Note to myself : How to provide the same functionality as a  
>> standardized function in paracomp.
>>
>> Cheers
>> -- Shree

Re: [Paracomp-devel] Crash in pcSystemFinalize

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

Hi Stefan/Max,

I've created a temporary extension PC_COMP_ALPHA_SORT2_HP which provides 
the alpha blending support you need.

The specifics of the extension may change later, but the changes will be 
easy to make. Changes are in SVN - just update to get them. The
test_compositeEXT sample is changed to show how to use the extension.

Plus, attached is a patch which uses the new alpha blending capability 
inside equalizer (includes a small change in the test program too).

Do let me know if the patch works for you. You'd want to check it with 
the actual application (eVolve) too - to keep away blending surprises ;-)

Cheers
-- Shree

Kumar, Shree (STSD) wrote:
> I just updated my sandbox to get the changes. I think it's fairly easy 
> to add support
> for the sort of compositing you are looking for. I had a good look at 
> the code : changing the blending equation
> is quite easy in the C code. In the assembly language code for x86_64, 
> the number/type of instructions remain the same :-)
>
> Quick preliminary tests on my x86_64 desktop (these are with the wrong 
> blending equation, but I expect the same to
> hold on the correct blending equation too)
> ------ Without Paracomp ------
> ./Linux/test: Alpha first op:  66.7899 ms (394.778 MB/s)
> ./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s)
> ./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s)
> -------- With Paracomp ---------
> ./Linux/test: Alpha first op:  40.5636 ms (650.021 MB/s)
> ./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s)
> ./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s)
> --------------------------------------
>
> Small note : test.cpp isn't using alpha blending in the "Alpha 15 
> images" case. This is due to a missing "true" parameter to
>  assembleFramesCPU. In line 108, you need to add a true param to 
> assembleFramesCPU()
>
> I'll change the blending function as an experiment on monday & send 
> you some patches.
>
> Note to myself : How to provide the same functionality as a 
> standardized function in paracomp.
>
> Cheers
> -- Shree

Re: [Paracomp-devel] Crash in pcSystemFinalize

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

Hi Stefan,

Stefan Eilemann wrote:
> On 13. May 2008, at 13:34, Stefan Eilemann wrote:
>
>   
>> I'll send you a link to the alpha-compositing patch. We do things
>> not quite straight-forward in order to support colored backgrounds
>> in eVolve. Basically we blend as if using
>> glBlendFuncSeparate( GL_ONE, GL_SRC_ALPHA, GL_ZERO, GL_SRC_ALPHA ).
>>
>> Can I do this with ParaComp as well?
>>     
>
> Here you go: <http://equalizer.svn.sourceforge.net/equalizer/?rev=1879&view=rev
>  >
>   
I just updated my sandbox to get the changes. I think it's fairly easy 
to add support
for the sort of compositing you are looking for. I had a good look at 
the code : changing the blending equation
is quite easy in the C code. In the assembly language code for x86_64, 
the number/type of instructions remain the same :-)

Quick preliminary tests on my x86_64 desktop (these are with the wrong 
blending equation, but I expect the same to
hold on the correct blending equation too)
------ Without Paracomp ------
./Linux/test: Alpha first op:  66.7899 ms (394.778 MB/s)
./Linux/test: Alpha second op: 69.5435 ms (379.147 MB/s)
./Linux/test: Alpha 15 images: 307.675 ms (428.491 MB/s)
-------- With Paracomp ---------
./Linux/test: Alpha first op:  40.5636 ms (650.021 MB/s)
./Linux/test: Alpha second op: 51.9242 ms (507.802 MB/s)
./Linux/test: Alpha 15 images: 152.929 ms (862.071 MB/s)
--------------------------------------

Small note : test.cpp isn't using alpha blending in the "Alpha 15 
images" case. This is due to a missing "true" parameter to
 assembleFramesCPU. In line 108, you need to add a true param to 
assembleFramesCPU()

I'll change the blending function as an experiment on monday & send you 
some patches.

Note to myself : How to provide the same functionality as a standardized 
function in paracomp.

Cheers
-- Shree