[fpc-devel]Russian locale informationnotcompatiblewithFPClocalevariables

[Boian Mitov]

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" <almindor at gmail.com>
To: "FPC developers' list" <fpc-devel at 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel