Forums > Jitter

rtt,ctt and fbo example file crashes max 5

May 1, 2008 | 12:43 pm

the file jit.gl.slab-float-readback.maxpat, found in the jitter 1.7
examples/render/slab folder causes max to crash. there isn’t a render
destination in the patch. what confuses me is that when i place a
destination (a jit.window or pwindow) in the patch it still crashes. can
someone tell me why?

i’m intrigued to get a better understanding of the rtt fbo and ctt readback
mechanisms, but am not convinced that this patch will provide the answers.
can someone explain how these operate in jitter together with the advantages
of each, or point me to somewhere that has a succinct explanation?

as i understand these mechanisms:

a) copy to texture (ctt), is a basic gl operation that copies the back
buffer and and uses it to replace the previous texture that was rendered.

b) render to texture (rtt) bypasses the buffer and renders directly to a
texture.

c) the frame buffer object (fbo) has textures rendered to it before calling
the rtt step, and this operation speeds up the overall rendering of a scene.

presumably when a message is sent to jitter to use the fbo the set up for
the object is injected into the rendering process. But, if this operation
speeds up rendering why not use it all the time in place of other the other
options? why does it need an explicit instruction? or are there occasions
when using a fbo is pointless, eg when not using depth testing?

thanks

pelado

i’m on a mac powerbook, ATI radeon 9700, using OSX 10.4.11


May 1, 2008 | 4:37 pm

Sorry for the crash, and other issues with this patch.

First off, your graphics card doesn’t support floating point data, so
it’s kind of moot. However for people whose graphics cards do support
floating point data, I’ve added a jit.window display @size 8 8 @border
0 for the next release to have an almost invisible context. This makes
the patch load and work properly the first time on my machine. However
I’m experiencing some issues with "jit.gl.texture: error entering
unbind: GL Error: Invalid operation" after loading and closing the
patch. We’ll be investigating this issue.

Thanks,
Joshua


May 1, 2008 | 4:44 pm

Sorry for jumping the trigger on that one. I double checked http://developer.apple.com/graphicsimaging/opengl/capabilities/
and your card *does* support float pixels. We’ll try to reproduce
your crash.

On May 1, 2008, at 5:43 AM, pelado wrote:
>
> presumably when a message is sent to jitter to use the fbo the set
> up for the object is injected into the rendering process. But, if
> this operation speeds up rendering why not use it all the time in
> place of other the other options? why does it need an explicit
> instruction? or are there occasions when using a fbo is pointless,
> eg when not using depth testing?

We don’t use fbo as the default case as it has issues on certain
graphics cards. We leave the various backends for advanced users to
experiment with.

-Joshua


May 1, 2008 | 5:06 pm

yes, i had checked that my card supported floats. I’ve just come across
another issue with the ‘jit.gl.slab.float.maxpat’ patch which i guess is
related to the float issue. i get these error messages when starting the
patch:

jit.gl.pbuffer: error binding invalid pbuffer!

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

then max crashes when i close the patch.

in relation to the fbo issue then, is it a good idea to be using fbo
readback for each episode of jitter? my card does support fbos. .

pelado

On Thu, May 1, 2008 at 6:44 PM, Joshua Kit Clayton wrote:

>
> Sorry for jumping the trigger on that one. I double checked
> http://developer.apple.com/graphicsimaging/opengl/capabilities/ and your
> card *does* support float pixels. We’ll try to reproduce your crash.
>
>
> On May 1, 2008, at 5:43 AM, pelado wrote:
>
> >
> > presumably when a message is sent to jitter to use the fbo the set up
> > for the object is injected into the rendering process. But, if this
> > operation speeds up rendering why not use it all the time in place of other
> > the other options? why does it need an explicit instruction? or are there
> > occasions when using a fbo is pointless, eg when not using depth testing?
> >
>
>
>
> We don’t use fbo as the default case as it has issues on certain graphics
> cards. We leave the various backends for advanced users to experiment with.
>
> -Joshua
>
>

http://www.pelado.co.uk


May 1, 2008 | 5:36 pm

On May 1, 2008, at 10:06 AM, pelado wrote:
> yes, i had checked that my card supported floats. I’ve just come
> across another issue with the ‘jit.gl.slab.float.maxpat’ patch which
> i guess is related to the float issue. i get these error messages
> when starting the patch:
>
> jit.gl.pbuffer: error binding invalid pbuffer!
> jit.gl.texture: error binding readback mechanism for capture!

Well, there might be some special restrictions to floating point
pbuffers working on this card, which we might not be following. We can
investigate further, but a fix for this might not happen soon.

> in relation to the fbo issue then, is it a good idea to be using fbo
> readback for each episode of jitter? my card does support fbos. .

I would suggest using an empirical strategy to see if it works better
or worse for you + your card. If you like, you can add a line in
jitter-config.txt to this end so that you can always have it enabled.

-Joshua


May 1, 2008 | 6:49 pm

This is one of the really annoying issues with GPUs. You card might
support FBOs and float textures, but have limited support for the 2
together. The same goes for pbuffers. Often on older cards like the
Radeon 9700, pbuffers are actually faster than FBOs (at least from
what I remember back when I had a similar machine as yours). On more
recent GPUs, FBOs are much better supported and float support is also
vastly improved.

On an nvidia 8600M with osx 10.4.11, the float readback patch works
properly, so it appears we’re not properly handling some fallback from
errors in the 9700 case.

wes

On Thu, May 1, 2008 at 10:06 AM, pelado

wrote:
> yes, i had checked that my card supported floats. I’ve just come across
> another issue with the ‘jit.gl.slab.float.maxpat’ patch which i guess is
> related to the float issue. i get these error messages when starting the
> patch:
>
>
>
>
>
> jit.gl.pbuffer: error binding invalid pbuffer!
>
> jit.gl.texture: error binding readback mechanism for capture!
>
>
> then max crashes when i close the patch.
>
> in relation to the fbo issue then, is it a good idea to be using fbo
> readback for each episode of jitter? my card does support fbos. .
>
>
> pelado
>
>
> On Thu, May 1, 2008 at 6:44 PM, Joshua Kit Clayton wrote:
> >
> > Sorry for jumping the trigger on that one. I double checked
> http://developer.apple.com/graphicsimaging/opengl/capabilities/ and your
> card *does* support float pixels. We’ll try to reproduce your crash.
> >
> >
> >
> > On May 1, 2008, at 5:43 AM, pelado wrote:
> >
> > >
> > > presumably when a message is sent to jitter to use the fbo the set up
> for the object is injected into the rendering process. But, if this
> operation speeds up rendering why not use it all the time in place of other
> the other options? why does it need an explicit instruction? or are there
> occasions when using a fbo is pointless, eg when not using depth testing?
> > >
> >
> >
> >
> > We don’t use fbo as the default case as it has issues on certain graphics
> cards. We leave the various backends for advanced users to experiment with.
> >
> > -Joshua
> >
> >
> >
> >
>
>
>
> –
> http://www.pelado.co.uk
>
>


May 1, 2008 | 7:01 pm

On Thu, May 1, 2008 at 7:36 PM, Joshua Kit Clayton wrote:

I would suggest using an empirical strategy to see if it works better or
> worse for you + your card. If you like, you can add a line in
> jitter-config.txt to this end so that you can always have it enabled.
>

Thanks, I’ll give it a go. I’ve created a file called ‘jitter-config.txt’
which contains the line ‘jitter glreadback fbo;’ (no quotes, semi-colon
included) and saved it to the Cycling’74/init/ folder. Is that the correct
way to do it? I can’t find anything in the docs about it, and can’t think
of any way to question whether or not jitter is in fact configured this way.

Thanks again

pelado


May 1, 2008 | 8:03 pm

>
> [...] on older cards like the
> Radeon 9700, pbuffers are actually faster than FBOs (at least from
> what I remember back when I had a similar machine as yours). On more
> recent GPUs, FBOs are much better supported and float support is also
> vastly improved.
>

ok Wes,

I’ll take that as a hint to upgrade my hardware!

pelado



efe
May 22, 2010 | 12:40 pm

Has some one experienced switching jitter configuration for using FBO? any performance improvements?
Emmanuel


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