Bernd

my setup consists of a G5 DualCore2,3GHz, QT7.11,OSX4.6,

As soon as you start the metro the following message is sent for each bang to the MAX window,

error: jit.gl.texture: error binding readback mechanism for capture!

error: jit.gl.pbuffer: error binding invalid pbuffer!

Does not happen on a MacBook (no second screen attached).

my setup consists of a G5 DualCore2,3GHz, QT7.11,OSX4.6,
3x GForce6600.

error: jit.gl.texture: error binding readback mechanism for capture!
error: jit.gl.pbuffer: error binding invalid pbuffer!

jit-gl-slab-v1-6-bug-with-multiple-displays

Quote: Bernd wrote on Mon, 26 June 2006 03:30

----------------------------------------------------

> my setup consists of a G5 DualCore2,3GHz, QT7.11,OSX4.6,

> As soon as you start the metro the following message is sent for each bang to the MAX window,

> error: jit.gl.texture: error binding readback mechanism for capture!

> error: jit.gl.pbuffer: error binding invalid pbuffer!

> Does not happen on a MacBook (no second screen attached).

Quote: Bernd wrote on Mon, 26 June 2006 03:30
----------------------------------------------------
> Hi,
>
> my setup consists of a G5 DualCore2,3GHz, QT7.11,OSX4.6,
> 3x GForce6600.
>
> Just try the jit.gl.slab help file. 
>
> 1) Start qmetro
> 2) Start metro
>
> As soon as you start the metro the following message is sent for each bang to the MAX window,
>
>
> error: jit.gl.texture: error binding readback mechanism for capture!
> error: jit.gl.pbuffer: error binding invalid pbuffer!
>
> Does not happen on a MacBook (no second screen attached).
>
> Bernd
>
----------------------------------------------------

Am I the only one with this problem?
I tried with 4.6.1/1.6.1 same result?!

On Aug 26, 2006, at 4:54 AM, Bernd wrote:

Unfortunately I don't have a machine with a similar setup to test. 

You'll need to provide us more information about how you're using the 

After it reports that error, does it actually draw fine? There have 

been instances where this problem happens the first time rendering, 

Anyone else with a similar setup to Bernd?

> my setup consists of a G5 DualCore2,3GHz, QT7.11,OSX4.6,
> 3x GForce6600.
> Am I the only one with this problem?
> I tried with 4.6.1/1.6.1 same result?!

Unfortunately I don't have a machine with a similar setup to test.  
You'll need to provide us more information about how you're using the  
multiple displays.

After it reports that error, does it actually draw fine? There have  
been instances where this problem happens the first time rendering,  
but afterwards without problem.

> You'll need to provide us more information about how you're using the 

Currently 4 monitors are sitting side by side in the monitor setup pref pane, no mirroring. No matter on which I move the Finder bar, always the same result with the jit.gl.slab helpfile.

> After it reports that error, does it actually draw fine?

No drawing, each bang creates the error messages.

jit.gl.render: building GL on window "foo"...

? error: jit.gl.pbuffer: unable to create pbuffer context!

? error: jit.gl.texture: error attaching texture to readback mechanism for capture!

? error: jit.gl.pbuffer: error binding invalid pbuffer!

? error: jit.gl.texture: error binding readback mechanism for capture!

> You'll need to provide us more information about how you're using the  
> multiple displays.

>
> After it reports that error, does it actually draw fine?

No drawing, each bang creates the error messages.
It looks like this:

jit.gl.render: building GL on window "foo"...
? error: jit.gl.pbuffer: unable to create pbuffer context!
? error: jit.gl.texture: error attaching texture to readback mechanism for capture!
? error: jit.gl.pbuffer: unable to create pbuffer context!
? error: jit.gl.texture: error attaching texture to readback mechanism for capture!
? error: jit.gl.pbuffer: unable to create pbuffer context!
? error: jit.gl.texture: error attaching texture to readback mechanism for capture!
? error: jit.gl.pbuffer: error binding invalid pbuffer!
? error: jit.gl.texture: error binding readback mechanism for capture!
? error: jit.gl.pbuffer: error binding invalid pbuffer!
? error: jit.gl.texture: error binding readback mechanism for capture!
? error: jit.gl.pbuffer: error binding invalid pbuffer!
? error: jit.gl.texture: error binding readback mechanism for capture!
? error: jit.gl.pbuffer: error binding invalid pbuffer!
? error: jit.gl.texture: error binding readback mechanism for capture!
? error: jit.gl.pbuffer: error binding invalid pbuffer!
? error: jit.gl.texture: error binding readback mechanism for capture!
? error: jit.gl.pbuffer: error binding invalid pbuffer!
? er
...

Starting up with only one monitor, jit.gl.slab works well.

As soon as having a second monitor connected at the SECOND video card (which is in the 8-lane slot), the error occurs.

On Aug 27, 2006, at 5:31 AM, Bernd wrote:

> Further investigation: Starting up with only one monitor, 

> As soon as having a second monitor connected at the SECOND video 

> card (which is in the 8-lane slot), the error occurs.

Interesting. There might be some aspect of using these cards in this 

configuration that actually prevents using the appropriate driver for 

these cards, and it might be falling back on the software based 

renderer, or some other more basic OpenGL driver. Are there any other 

messages posted in the max window about using a software renderer?

- Does typing the following into a message box and clicking it result 

in a functional jit.gl.slab.help? ("; jitter glreadback fbo", which 

is the message to use an FBO rather than a pbuffer backend for each 

We may need to try and get our hands on this HW to better track down 

> Further investigation: Starting up with only one monitor,  
> jit.gl.slab works well.
> As soon as having a second monitor connected at the SECOND video  
> card (which is in the 8-lane slot), the error occurs.

Interesting. There might be some aspect of using these cards in this  
configuration that actually prevents using the appropriate driver for  
these cards, and it might be falling back on the software based  
renderer, or some other more basic OpenGL driver. Are there any other  
messages posted in the max window about using a software renderer?

- Does typing the following into a message box and clicking it result  
in a functional jit.gl.slab.help? ("; jitter glreadback fbo", which  
is the message to use an FBO rather than a pbuffer backend for each  
slab rendering pass).

We may need to try and get our hands on this HW to better track down  
these particular issues.

Quote: jkc wrote on Sun, 27 August 2006 16:30

> Interesting. There might be some aspect of using these cards in this 

> configuration that actually prevents using the appropriate driver for 

> these cards, and it might be falling back on the software based 

> renderer, or some other more basic OpenGL driver. Are there any other 

> messages posted in the max window about using a software renderer?

As far as I tested all works fine excluding jit.gl.slab.

No error messages when using the jit.gl.videoplane.help

and sending fsaa 0/1 messages to jit.window.

> - Does typing the following into a message box and clicking it result 

> in a functional jit.gl.slab.help? ("; jitter glreadback fbo", which 

> is the message to use an FBO rather than a pbuffer backend for each 

No, unfortunately not. The following error messages appear:

? error: jit.gl.fbo: unsupported framebuffer format!

? error: jit.gl.texture: error updating readback mechanism for capture!

> We may need to try and get our hands on this HW to better track down 

Would be great as currently multi-screen work with jit.gl.slab is completely broken here.

Ah, and I forgot to mention that it?s the same behaviour with the 1.5.3 beta version.

OSX 10.4.7, G5, QT 7.1.2, Max/MSP 4.6.1/Jitter 1.6.1

Quote: jkc wrote on Sun, 27 August 2006 16:30
----------------------------------------------------

> Interesting. There might be some aspect of using these cards in this  
> configuration that actually prevents using the appropriate driver for  
> these cards, and it might be falling back on the software based  
> renderer, or some other more basic OpenGL driver. Are there any other  
> messages posted in the max window about using a software renderer?

>
> A few random questions:
>
> - Do other OpenGL patches work fine?

>
> - Does FSAA work? (jit.window @fsaa 1)

No error messages when using the jit.gl.videoplane.help
and sending fsaa 0/1 messages to jit.window.

>
> - Does typing the following into a message box and clicking it result  
> in a functional jit.gl.slab.help? ("; jitter glreadback fbo", which  
> is the message to use an FBO rather than a pbuffer backend for each  
> slab rendering pass).

? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.fbo: unsupported framebuffer format!
? error: jit.gl.texture: error updating readback mechanism for capture!

>
> We may need to try and get our hands on this HW to better track down  
> these particular issues.

OSX 10.4.7, G5, QT 7.1.2, Max/MSP 4.6.1/Jitter 1.6.1


We've got the same problem here. Just upgraded to jitter 1.6. A patch that worked fine in 1.5 gives the following error:

after sending ; jitter glreadback fbo, we get

Quad G5 2,5 GHz (PPC), 1x GeForce 7800 (two of two monitors connected), 1x GeForce 6600 (one of two monitors connected), OSX 10.4.7, Max 4.6.1, Jitter 1.6.1

? error: jit.gl.pbuffer: unable to create pbuffer context!
? error: jit.gl.texture: error attaching texture to readback mechanism for capture!

The setup is:
Quad G5 2,5 GHz (PPC), 1x GeForce 7800 (two of two monitors connected), 1x GeForce 6600 (one of two monitors connected), OSX 10.4.7, Max 4.6.1, Jitter 1.6.1

On Sep 8, 2006, at 7:06 AM, Mattijs Kneppers wrote:

> We've got the same problem here. Just upgraded to jitter 1.6. A 

> patch that worked fine in 1.5 gives the following error:

Thanks for the report. We'll try to solve this one in the near 

>
> We've got the same problem here. Just upgraded to jitter 1.6. A  
> patch that worked fine in 1.5 gives the following error:

Thanks for the report. We'll try to solve this one in the near  
future, once we get some HW to test on.

i saw a posting from late august into september that addressed the same issue,

https://cycling74.com/forums/index.php?t=msg&goto=74345&rid=3287&S=3fe129ab65b1094c47bac3c7e45f9f44&srch=%22error+binding+invalid+pbuffer%21%22#msg_74345

the issue being the following errors in a setup with 4 screens:

jit.gl.texture: error binding readback mechanism for capture!

jit.gl.pbuffer: error binding invalid pbuffer!

my symptoms are just like those reported by bernd and others; i.e., i have a patch that works fine with one two gforce 6600's installed in a quad G5, but only so long as nothing is connected to the 2nd graphics card. as soon as i connect a monitor to the second graphics card, i get lots of errors and i only appear to get one of my openGL context rendered.

did anyone come up with a solution or a work around for this?

hello,
i saw a posting from late august into september that addressed the same issue, 

jit.gl.texture: error binding readback mechanism for capture!
jit.gl.pbuffer: error  binding invalid pbuffer!

my symptoms are just like those reported by bernd and others; i.e., i have a patch that works fine with one two gforce 6600's installed in a quad G5, but only so long as nothing is connected to the 2nd graphics card.  as soon as i connect a monitor to the second graphics card, i get lots of errors and i only appear to get one of my openGL context rendered.

On Oct 2, 2006, at 2:33 AM, Ali Momeni wrote:

> the issue being the following errors in a setup with 4 screens:

> jit.gl.texture: error binding readback mechanism for capture!

> jit.gl.pbuffer: error binding invalid pbuffer!

We are actively investigating this issue. The current workaround is 

to send jitter the message "; jitter glreadback fbo" to use the frame 

buffer object backend. Unfortunately with multiple graphics cards 

there seems to be trouble sharing resources with any windowed 

context. Not only window contexts which span multiple cards.

The frame buffer object backend isn't perfect, but largely works 

without problem. You can put the above line inside a file called 

jitter-config.txt which resides in the search path if you want this 

> the issue being the following errors in a setup with 4 screens:
>
> jit.gl.texture: error binding readback mechanism for capture!
> jit.gl.pbuffer: error  binding invalid pbuffer!

We are actively investigating this issue. The current workaround is  
to send jitter the message "; jitter glreadback fbo" to use the frame  
buffer object backend. Unfortunately with multiple graphics cards  
there seems to be trouble sharing resources with any windowed  
context. Not only window contexts which span multiple cards.

The frame buffer object backend isn't perfect, but largely works  
without problem. You can put the above line inside a file called  
jitter-config.txt which resides in the search path if you want this  
to always be the case.

error: jit.gl.fbo: unsupported framebuffer format!

errir: jit.gl.texture:error updating mechanism for capture!

and now, i don't know what glreadback mechanism was the default becuase with the current, some of my programmable shaders no longer work at all :(

hi joshua,
like the previous posters,
when i tell jitter glreadback fbo,
i get this error:

error: jit.gl.fbo: unsupported framebuffer format!
error: jit.gl.fbo: unsupported framebuffer format!
...
error: jit.gl.fbo: unsupported framebuffer format!
error: jit.gl.fbo: unsupported framebuffer format!
errir: jit.gl.texture:error updating mechanism for capture!

i like all the !'s in the errors,
as if it's as surprised as i am heehee.

just a note to say, i learned from the release notes that the default for glreadback is 'rtt' so i changed it back to 'rtt' and now my shaders work, but still lots of errors. in fact, aside from the errors, i don't see any harm; all screens works; did the others also find that the only problem is the posted errors?

just a note to say, i learned from the release notes that the default for glreadback is 'rtt' so i changed it back to 'rtt' and now my shaders work, but still lots of errors.  in fact, aside from the errors, i don't see any harm; all screens works; did the others also find that the only problem is the posted errors?

Fix for this is in the next version (finally figured out the real 

problem). I also hope to solve the jitter glreadback fbo issues 

claiming to not be supported. I was able to solve this problem with 

1.6.2 by sending the message sequence depthbuffer 0, depthbuffer 1 to 

jit.window to force a rebuild, however. I'm surprised that sending 

the message glreadback rtt made things work for you, as I didn't see 

such behavior as long as screens were attached to both cards and the 

So the recommended steps if you have multiple graphics cards on the 

- "depthbuffer 0, depthbuffer 1"->jit.window (or toggle off if you 

Fix for this is in the next version (finally figured out the real  
problem). I also hope to solve the jitter glreadback fbo issues  
claiming to not be supported. I was able to solve this problem with  
1.6.2 by sending the message sequence depthbuffer 0, depthbuffer 1 to  
jit.window to force a rebuild, however. I'm surprised that sending  
the message glreadback rtt made things work for you, as I didn't see  
such behavior as long as screens were attached to both cards and the  
readback mechanism was rtt.

So the recommended steps if you have multiple graphics cards on the  
Mac until we get 1.6.3 out the door is:

- "; jitter glreadback fbo"
- "depthbuffer 0, depthbuffer 1"->jit.window (or toggle off if you  
don't want one)

On 03.10.2006, at 18:30, Joshua Kit Clayton wrote:

> Fix for this is in the next version (finally figured out the real 

> hip hip hurray! I didn't notice spigot~ was back from the dead.

> for those in Brussels, I guess I m going to open a champagne bottle 

- but it will be in groningen, and it will just be sekt instead of 

champagne!! (well, i also have some beer, gary;-)

> Fix for this is in the next version (finally figured out the real  
> problem).

ah, i'll follow yacine's example as in
> hip hip hurray! I didn't notice spigot~ was back from the dead.
> for those in Brussels, I guess I m going to open a champagne bottle  
> to celebrate.
> i am so happy ;)

- but it will be in groningen, and it will just be sekt instead of  
champagne!! (well, i also have some beer, gary;-)
THANKS!!!!!

On Oct 3, 2006, at 10:23 AM, Jan Klug wrote:

> - but it will be in groningen, and it will just be sekt instead of 

> champagne!! (well, i also have some beer, gary;-)

Most disgusting drink award goes to Ben who, while in Berlin, somehow 

through miscommunication ordered sekt with tequila. Ick! Everytime I 

think about sekt I'm reminded of this horrible combo.

> - but it will be in groningen, and it will just be sekt instead of  
> champagne!! (well, i also have some beer, gary;-)

Most disgusting drink award goes to Ben who, while in Berlin, somehow  
through miscommunication ordered sekt with tequila. Ick! Everytime I  
think about sekt I'm reminded of this horrible combo.

jit.gl.slab v1.6 bug with multiple displays