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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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