Re: pBuffer

New Message Reply Date view Thread view Subject view Author view

Phil Keslin (philk++at++cthulhu.engr.sgi.com)
Fri, 11 Dec 1998 11:33:25 -0800


Francois Sillion wrote:
>
> Rüdiger, Rob, Phil and others,
>
> Since there seems to be a lively discussion on Pbuffers, please let me ask my
> last question again: I ran into some similar problems trying to find a correct
> FB config for my Pbuffer: specifically I have to use a double-buffered buffer
> because none of the available single-buffered ones is accepted by X. I don't
> know if this double-buffering is the cause for my problem, but then I can't
> get a correct rendering unless I specify the GLX_PRESERVED_CONTENTS attribute.
> This is not an acceptable solution because it creates a huge performance
> penalty in Performer.

Hmm. I don't know why the Xserver will not allow allocation of single
buffered pbuffers. What is the config of your IR pipe (gfxinfo and
glxinfo output will suffice) and what is the framebuffer config you are
requesting?

More below...

[snip]

> In my application I have two pipeWindows, one rendering to a window on screen
> and one rendering to an (offscreen) P-buffer. This works fine on an O2.
>
> I have the following problem running it on an iR:
>
> - If I create my P-buffer with the GLX_PRESERVED_CONTENTS_SGIX attribute,
> rendering in the main (on-screen) window is slowed down terribly,
> even
> if the offscreen pipewindow is doing nothing (i.e. has no channel
> attached to it).
> SGI support identified this as the source of the performance problem
> (thanks a lot to them!), but

The Xserver is swapping drawables, very slow. We need to figure out how
to get a shallow pbuffer (e.g., non-double buffered).

> - if I do not specify the GLX_PRESERVED_CONTENTS_SGIX attribute,
> performance
> is as expected, but the image I extract from my Pbuffer is garbage.

Something is binding another drawable before you do your read. When the
pbuffer is invalidated, the framebuffer storage may be used by that
other drawable. Given the snippet you provided, it is not clear where
that could be happening though (another, unrelated process could also be
doing it).

> Looking at the Pbuffer doc, I found that when contents are not preserved, the
> Pbuffer can be trashed at any time, but with an (asynchronous) notification by
> means of a clobber event. The man page also suggests grabbing the X Server.
>
> - I tried grabbing the X server: the draw callback on my offscreen channel
> looks then like:
> =============================
> static void
> DrawOffScreenChannelCB ( pfChannel * pChannel , void * )
> {
> pfEnable(PFEN_LIGHTING);
>
> pChannel -> clear ();
>
> XGrabServer( pfGetCurWSConnection() );
>
> pfDraw();
> GatherOffscreenData(); // this function simply calls glReadPixels to get
> the
> // image from the Pbuffer into memory
>
> XUngrabServer( pfGetCurWSConnection() );
> }
> =============================
> but the contents of my image is still garbage...

I'm not quite sure that server grabs will prevent processes that have
already bound to the pipe from rendering and hence swapping your
pbuffer.

> - I also wanted to try reacting to CLOBBER events, but could not find
> any examples. the man page says I can use glXSelectEventSGIX to register
> for this type of event, but then what? I only know how to set an
> event
> handler for an Xt Widget using XtAddEventHandler.. but my pbuffer is
> not
> a widget! how do I specify how to react to a clobber event?

I've never found clobber events of much use. To make it work you'll need
a separate Display connection just for these events and you'll need to
query the event queue prior to every read. This must happen in the DRAW
process.

> - One final note: on the iR my program allocates a DOUBLE-BUFFERED pbuffer,
> because the (single) FB config found for single buffer pbuffers is
> refused by glXCreateGLXPbufferSGIX (BadAlloc (insufficient resources
> for
> operation). Could this have to do with my problem? in case you
> wonder,
> I HAVE tried reading pixels from the front and the back buffers, I
> have
> garbage in both!

Need to figure out why it won't let you have a single buffered visual.
The requested info should help quite a bit.

- Phil

-- 
Phil Keslin <philk++at++engr.sgi.com>

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Fri Dec 11 1998 - 11:33:33 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.