[PD] GEM: openGL and CPU usage
chris clepper
cclepper at artic.edu
Thu May 29 21:29:32 CEST 2003
>I'm working on some VJ-type pd patches at the moment, and am a bit
>puzzled by how GEM uses openGL, and what is processed on the CPU.
>
>Hewlett-packard is lending us a twin 2.8GHz Xeon machine with 1gig of
>DDR ram, which is fitted at the moment with a matrox G400 (don't ask,
>we've got a GeForce 4 Ti4600 card coming our way imminently.)
well lucky you ;) i think the matrox card might not have any GL
drivers installed from the sound of it. the geforce will help
immensely, just be sure to get a good set of drivers from nvidia (not
all of the drivers work great so try a few from their site and use
the best).
>I was doing some testing using gem and pd, playing with a large avi divx
>file (ca 500MB).
divx is a terrible codec for real-time work, i strongly recommend
using a production codec like photo-jpeg or DV rather than a delivery
codec like divx or mpeg. anything with keyframes will kill
performance.
>If I use pix_movie and use it to display on a rectangle geo, the movie
>plays fine. If however I apply any transformations, the whole thing
>slows down considerably. I understand that it must be because of the
>graphics card.
it looks like there is no hardware acceleration. is this on windows or linux?
>Can anyone elaborate a little on how GEM exploits openGL, and what
>objects use the CPU for processing? I would in particular know what
>kinds of approaches would help get good video processing performance.
anything with pix_ in the name uses the cpu for processing pixels.
the geos can also use some cpu but only for calculating the GL
instructions to send to the card - newwave for example uses the cpu
to calculate the wave movements but GL does the actual pixel
manipulation.
>Here's another question. If I apply two videos to two rectangles, put
>them in front of one another, and make the frontmost one half
>transparent, the black pixels are not transparent (in other words, they
>are grey and half opaque). I suppose that must be to do with how openGL
>works, but is there a way to make it behave in such a way that a pixel
>that has no color is actually transparent?
without seeing the patch, im guessing you are using the alpha object
and fading using the color object? this method applies a single
constant alpha value to the entire texture and blends based on that.
at the moment GEM doesn't really have a way to do per-pixel
compositing using GL, only pix_ CPU based processing will do that.
in the (near?) future, GEM will make use of pixel/fragment shaders to
do various types of compositing for textures, so hold onto that
geforce 4600 card as it has some shader support.
cgc
>- martin
>
>
>
>_______________________________________________
>PD-list mailing list
>PD-list at iem.kug.ac.at
>http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
More information about the Pd-list
mailing list