[PD] Gem - CPU usage 98%

chris clepper cgc at humboldtblvd.com
Thu Jun 8 17:57:11 CEST 2006


On 6/8/06, klaas de Baas <kdebaas at hotmail.com> wrote:
>
>
>
> CPU utilization is still high. My questions:
> - was I wrong in supposing that the GPU would take over processing tasks
> of
> the CPU?


Only the 3D OpenGL parts of GEM (Geos, Manips, Particles) are accelerated by
the GPU.  You can do image processing using the GPU and objects like
fragment_program though.  Any pix_ object is handled by the CPU.

- what would be a realistic cpu load for 24 hours a day, 2 months?


As long as the CPU and other components are properly cooled and stay within
the rated specs any CPU load should be tolerated.  CPUs are usually tested
using a 'thermal virus' code that is at an extremely high level of
efficiency, which GEM (or any real world program) will never reach.

- Does anyone on the list have experience with running fullscreen
> gem-patches with specs such as pentium III, 800Mhz, 384 Mb, and do they
> have
> any pointers on how to optimize (such as using a different size video,
> codec, etc..?)


That is fairly old hardware so don't expect a lot out of it.  It should do
320x240 video with some processing though.  I would recommend a PCI cpature
card with efficient DirectShow drivers that do things like scaling, color
space conversion (overlay), deinterlacing and other functions in hardware on
the card.  I suspect the device you are using relies on inefficient software
to do those things, hence the high CPU load.

Also, use a spigot object to gate the path going to the motion detection
objects.  You usually don't need 30fps for motion detection and int your
case you could probably play several frames per detection with similar
effect to full rate.

I am also working on another computer (faster pIV, 512MB etc, etc...). I
> noticed that playing a video in mediaplayer requires less than half the
> cpu
> load of playing it in pix-movie or pix-film.
> - Can anyone explain why this is?


GEM uses old VideoForWindows code to play AVI files which is slower than
DirectShow.  Mediaplayer uses a full DirectShow path and there are a number
of efficient paths when you can do that.  GEM has a full OpenGL rendering
engine so we cannot use things like the DirectShow hardware mixer and
scaler, and once you get off the narrow predetermined DS path things slow
down qite a bit.  There are plans to use Directshow for loading AVI files in
the future, but it will still not be as efficient as MediaPlayer (hopefully
it will be close though).

cgc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060608/289c198a/attachment.htm>


More information about the Pd-list mailing list