If that's how you expect to use mutexes, an atomic integer would be a LOT more
efficient, e.g. the g_atomic_int functions in glib. Those are implemented with
processor instructions instead of OS system calls.
I've struggled mightily to make y4mdenoise more multiprocessor friendly, and
one of the methods I'd like to try is to slice the frame into pieces and
denoise them separately. I just fear visible artefacts at the boundaries
between slices. Having a day job pretty much kills the energy I'd need to code
in my spare time, so traditionally, y4mdenoise development happens during
periods of unemployment, thus I haven't had time to try this method yet.
Steven Boswell
________________________________
From: Mark Heath <mjp...@silicontrip.org>
To: MJPEG-tools user list <mjpeg-users@lists.sourceforge.net>
Sent: Thursday, September 22, 2011 5:23 PM
Subject: Re: [Mjpeg-users] writing multi threaded code
Thanks for the input.
I did read up about the Thread Pool (Boss/worker) Pattern and implemented
something along these lines.
I was thinking about the most likely places to divide a file.
* time range based
* Frame based
* Slice based (range of lines)
* line based
* pixel based
Time range is not possible with y4m streams.
Frame based has the problem that we have to wait for the threads finish in
order. Before assigning the next frame to the worker.
Slice based might be too course, if one cpu is tied up doing other tasks, one
thread may take significantly longer than the others.
All threads must finish before moving onto the next frame.
I thought for slow filters (I've written an NL-Means filter and it takes about
15 seconds per frame) that line based would probably be the most suited.
Any suggestions on these methods?
Here is my worker thread code;
it locks and reads the global threadline, then processes that line.
void *filterline (void *p) {
int thisline=0;
int startx;
int stopx;
int x;
struct threadarg *ptharg = (struct threadarg *)p;
//mjpeg_debug("trace filterline in");
while (thisline < ptharg->height) {
pthread_mutex_lock (&linemutex);
thisline = threadline++;
pthread_mutex_unlock (&linemutex);
if (thisline < ptharg->height) {
startx = thisline * ptharg->width;
stopx = ptharg->width + startx;
for (x=startx; x < stopx; x++) {
filterpixel(ptharg->outBuf,ptharg->inBuf,x);
}
}
}
//mjpeg_debug("trace filterline out");
}
Mark
On 23/09/2011, at 10:00 AM, Steven Boswell II wrote:
y4mdenoise does that sort of threading internally. It'll denoise the intensity
plane and color plane separately, plus it has reader threads and writer
threads. I wrote a small thread-related class hierarchy that should be
reusable. If nothing else, it should be inspirational.
>
>
>BTW, you probably don't want to literally assign a thread to each individual
>line -- the system-call overhead of the semaphores would more than outweigh
>your processing time. Mutexes are by no means free.
>
>
>
>Hope that helps.
>
>
>Steven Boswell
>
>
>
>
>________________________________
>From: Mark Heath <mjp...@silicontrip.org>
>To: MJPEG-tools user list <mjpeg-users@lists.sourceforge.net>
>Sent: Wednesday, September 21, 2011 3:21 PM
>Subject: [Mjpeg-users] writing multi threaded code
>
>Hi Guys,
>
>I'm wondering if anyone has some skeleton C code for writing
>multithreaded filters.
>
>Similar to this kind of pseudo code;
>
>while not end of file {
>
> read frame
>
> create threads (number of CPUs)
>
> for y = 1 to height {
>
> while no available threads { wait for a thread to finish; }
>
> run in thread { for x = 1 to width { process pixel} }
> }
> write frame
>}
>
>I've written a temporal bilateral filter and an nl-means filter and
>they are slow, so was looking to speed things up on my multi cpu
>machines.
>
>If not, I'll see if I can generate my own skeleton.
>
>Thanks
>Mark
>
>------------------------------------------------------------------------------
>All the data continuously generated in your IT infrastructure contains a
>definitive record of customers, application performance, security
>threats, fraudulent activity and more. Splunk takes this data and makes
>sense of it. Business sense. IT sense. Common sense.
>http://p.sf.net/sfu/splunk-d2dcopy1
>_______________________________________________
>Mjpeg-users mailing list
>Mjpeg-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/mjpeg-users
>
>
>------------------------------------------------------------------------------
>All of the data generated in your IT infrastructure is seriously valuable.
>Why? It contains a definitive record of application performance, security
>threats, fraudulent activity, and more. Splunk takes this data and makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2dcopy2_______________________________________________
>Mjpeg-users mailing list
>Mjpeg-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/mjpeg-users
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
