[GEM-dev] Re: threads in pix_video in GEM

[chaser]

> 
> hmm, i guess you are on linux (since lluis is involved ;-))
yes

> 
> so: both [pix_film] and [pix_video] are using threads (if available),
> though in a somewhat different manner.
> pix_film: creates a thread in the main object and uses the thread to
> grab the images from the decoder-classes.
> pix_video: each decoder class handles autonomously whether it uses
> threads or not. the main object does know nothing about threads.
> 
> why: i don't know, most likely historical reasons;
> [pix_videoLinux] has used threads for a long time, when it was converted
> to [pix_video] + videoV4L the threading code went into the videoV4L
> class (to make migration simplest for all platforms)
> [pix_film] has not used threads for a very long time; i added it last
> year since a project was depending on the performance gain we got from
> threads; since i was not sure which decoder class i was actually going
> to use, i decided to write the code only once and put it into the
> [pix_film] class (instead of filmQT4L and filmAVIPLAY and ...)
> 
> 
> so as a conclusion:
> [pix_video] should use threads with all grabber-classes on linux (v4l,
> v4l2, dv4l); these classes won't even compile without pthreads (as
> opposed to [pix_film] where the pthread-code is really optional)
> i wonder what makes you think it doesn't.

so.. everything seems ok. perhaps our problem is not pthread related then..

if you have more spare time i can try to describe our scenario:

we have here a dual xeon HT workstation with an smp kernel.
for linux that means 2 cpus disabling hyperthreading.

in practice when we create a new pix_film object, the system increase 
its cpu load a little, and for each new pix_film, a little more even to 
reach the 100% load for all cpus.

our problem is that, when we move to use pix_video with two firewire 
cards, only one cpu is used for both dv captures, so the total system 
load is 50% (about 25% for each dv capture in gem x 2), what means that 
only one cpu is working.

in this situation, all new separators we create to multiply each dv 
signal to map new primitives, makes the patch to run more and more slow, 
as all the dependent process fo the dv capture remains in the first cpu 
that is loaded at 100% while the second is at 0%.

it seems it would be good, if each dv capure main process could run in a 
different cpu, as we could have 50% of each cpu free to multiply videos 
and process other things..



> 
> 
>> thanks in advance
>> gem runs really good ;)
> 
> 
> good to hear.
> 
> mf.dar
> IOhannes