[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