Well... This is probably the reason we develop our own libraries ;-) . Our
architecture was multithreaded since it was originally envisioned 7 years
ago. We still use other libraries but we call them from separated threads,
and we split the tasks upfront. In our latest design each video filter will
optionally perform in a separated thread thus distributing the video or
audio processing. We even plan to add distribution for large video frames
where each processor will be assigned only portion of the frame thus
utilizing multicore even in a single filter.
With best regards,
Boian Mitov
--------------------------------------------------------------------
Mitov Software
http://www.mitov.com
--------------------------------------------------------------------
----- Original Message -----
From: "Ales Katona" <[EMAIL PROTECTED]>
To: "FPC developers' list" <fpc-devel@lists.freepascal.org>
Sent: Thursday, July 31, 2008 1:39 AM
Subject: Re: [fpc-devel]Russian locale
informationnotcompatiblewithFPClocalevariables
I didn't want to add fire to this discussion, but I think one thing needs
to be mentioned, and that is graphics card usage from Threads and possible
APIs and their limitations.
I was at #opengl channel a few times recently due to work and personal
hobby too, and once I asked about doing basic texture loading in threads.
It came down to it that the openGL API is completely thread allergic,
however after a short discussion it was concluded that with today's cards
(and the trend here isn't changing AFAIK), the pipeline would serialize
all the calls in the end anyhow.
In other words, having a thread-safe API for gfx calls would bring only
overhead (e.g: DX 11 or original concept of GL 3.0)
Just thought I'd mention this little bottleneck of the future (for games
at least.. with 32+ cores, having only 1 doing the graphics I think could
be fatal, especially since data throughput probably won't get much better
on the main bus, e.g: RAM/Disk/VRAM transfers).
As a tidbit, I *heard* (rumor level truthfulness) that the "objective" GL
3.0 threadsafe concept was thrown away in the winter, and that GL 3.0 will
be a continuation of GL 2.0, not a rewrite. Take with a pinch of salt,
news on this front will arrive soon :)
Ales
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
