Forums > Jitter

Problems rendering GL to a matrix

October 20, 2008 | 4:04 am

I have several patches which render a GL context to a jit.window with great results. I wanted to change the output of one of my patchers to a jit.matrix (mainly so I can jit.qt.record it). I am running into problems, error messages thrown like the following:

jit.gl.texture: setting texture wrap mode t: GL Error: Invalid enumeration
jit.gl.readback: unable to create framebuffer: pbuffers not supported!!
jit.gl.shader: graphics hardware is not capable of running CG vertex programs.
jit.gl.shader: graphics hardware is not capable of running CG fragment programs.
jit.gl.shader: CG not supported for current hardware config.
jit.gl.shader: unable to load program!
jit.gl.shader: unable to find usable language implementation.
jit.gl.shader: error loading shader!
jit.gl: invalid extension called

I know that the messages about graphics hardware are not accurate because the exact same patch on the exact same hardware rendering to a jit.window (or jit.pwindow) instead of a jit.matrix works flawlessly.

I have boiled this down to a much simpler patch to demonstrate what I’m seeing. Any help would be appreciated.

I also found that you can crash Max if you delete the jit.window object while rendering.

Thanks,
James

– Pasted Max Patch, click to expand. –

October 20, 2008 | 4:49 am

Hi,
Thanks for the patch. I can reproduce and will look into it.
wes


October 31, 2008 | 9:48 pm

After poking around in the examples, I found another way to tee the render output.

examples/jitter-examples/render/render/jit.gl.render-tomatrix.maxpat shows 3 methods, including the most recommended method of using a jit.gl.sketch on the same context and hooking it up to dump its pixels to another context by sending it a glreadpixels message.

I built this into my patch, but the cost of banging the jit.gl.sketch seems to be quite high.

Normally, my patch gets about 35 FPS, but banging a jit.gl.sketch which glreadpixels to a 320×240 matrix knocks it back to around 25 FPS. If I make the matrix 720×480, then I only get 11-12 FPS. I can jit.qt.record that matrix at around that rate by recording to a RAM disk (if I record to a file on a hard drive, the frame rate goes even lower – 8-9 FPS).

Is there a cheaper way to do this?

My goal is to get to DV output (720×480 @ 29.97 FPS) but it seems like HD should be attainable as well in this modern age.

Any tips?

Thanks,
James


November 1, 2008 | 10:45 am

There was a similar question recently and I posted a patch using
jit.gl.asyncread.

http://www.cycling74.com/forums/index.php?t=msg&goto=155540&rid=2461&S=626b4622bf209756e7b8562c41122ce1#msg_155540

pelado

On Fri, Oct 31, 2008 at 10:48 PM, James Drage wrote:

>
> After poking around in the examples, I found another way to tee the render
> output.
>
> examples/jitter-examples/render/render/jit.gl.render-tomatrix.maxpat shows
> 3 methods, including the most recommended method of using a jit.gl.sketch on
> the same context and hooking it up to dump its pixels to another context by
> sending it a glreadpixels message.
>
> I built this into my patch, but the cost of banging the jit.gl.sketch seems
> to be quite high.
>
> Normally, my patch gets about 35 FPS, but banging a jit.gl.sketch which
> glreadpixels to a 320×240 matrix knocks it back to around 25 FPS. If I make
> the matrix 720×480, then I only get 11-12 FPS. I can jit.qt.record that
> matrix at around that rate by recording to a RAM disk (if I record to a file
> on a hard drive, the frame rate goes even lower – 8-9 FPS).
>
> Is there a cheaper way to do this?
>
> My goal is to get to DV output (720×480 @ 29.97 FPS) but it seems like HD
> should be attainable as well in this modern age.
>
> Any tips?
>
> Thanks,
> James
>


November 2, 2008 | 9:08 pm

Thanks for the response Pelado. I tried the patch at the bottom of the thread on your link, and I get a little over 3 fps.

I also tried integrating the jit.gl.asyncread method into my patcher, and I get similar results, around 3 fps with a 720×480 matrix. If I do a 320×240 matrix it comes out around 11 fps. So this is even slower than using the jit.gl.sketch method.

Did some debugging here, and as soon as I send "automatic 1" to the jit.gl.asyncread, the frame rate drops through the floor. I get 35 fps with "automatic 0" (of course, I don’t get anything in the matrix). So it seems that the bottleneck is indeed pulling the read to the matrix.

It seems like that should be a lot higher. Any idea why it’s so slow?

Thanks,
James


November 2, 2008 | 9:15 pm

Objects like jit.gl.asyncread depend greatly on your GPU. What do you have?
wes


November 3, 2008 | 3:38 am

It’s an HIS Radeon X1550. Driver version 8.421.0.0.

I’ve got another machine with an eVGA GeForce 6200 LE in it. I’ll try the same patch and see what kind of results I get.

James


November 3, 2008 | 3:49 am

Well sheesh. I get close to 30 fps even recording 720×480 to the hard drive with the NVidia-based card. That’s much more palatable!

Thanks for the quick response!

James


November 3, 2008 | 3:52 am

Can you post a basic patch? I have a machine with an x1600 I can test with.
wes

On Sun, Nov 2, 2008 at 8:38 PM, James Drage wrote:
>
> It’s an HIS Radeon X1550. Driver version 8.421.0.0.
>
> I’ve got another machine with an eVGA GeForce 6200 LE in it. I’ll try the same patch and see what kind of results I get.
>
> James
>


Viewing 9 posts - 1 through 9 (of 9 total)