Rob Jenkins (robj++at++quid)
Mon, 11 Aug 1997 16:32:20 -0700
It could be that the error is exactly what the X error says, you just asked for
too big a pbuffer. The glXMakeCurrentReadSGI man page says:
BadAlloc may be generated if the server has delayed allocation of
ancillary buffers until glXMakeCurrentReadSGI is called, only to find
that it has insufficient resources to complete the allocation.
You only have 1 RM so you could easily be 'pixel challenged' for a big pbuffer.
What might be happening ( this is a guess ) is that an assumption gets made
when you configure the pbuffer that while reasonable (ish) ends up giving you a
much deeper pbuffer than you need ( or in your case, can have ).
glXChooseFBConfigSGIX actually returns a *list* of GLX frame buffer
configurations that match the specified attributes, the code you have might
just uses the first element in that list to then do glXCreateGLXPbufferSGIX.
The man page for glXChooseFBConfigSGI has detail but essentially, the list is
sorted by order of things like bits per component etc. It also mentions the use
of glXGetFBConfigAttribSGIX to retrieve additional attributes for the frame
buffer configurations and then select between them. This might be what you need
to do. If you look at the first config in the list, I expect that it's RGBA12
and might have a huge accumulation buffer and all sorts of things that you
don't need, and that makes the pixels too deep to make the Pbuffer. The list
returned would vary from platform to platform so it just maybe that on O2 the
first one is OK. On iR you could try adding logic like this:
int attributeList[] =
{GLX_RENDER_TYPE_SGIX, GLX_RGBA_BIT_SGIX,
GLX_DRAWABLE_TYPE_SGIX, GLX_PBUFFER_BIT_SGIX|GLX_WINDOW_BIT_SGIX,
GLX_RED_SIZE, 1,
GLX_BLUE_SIZE, 1,
GLX_GREEN_SIZE, 1,
GLX_DEPTH_SIZE, 1,
None};
GLXContext cx;
GLXFBConfigSGIX *fbc;
int nitems, i, match, a[5];
/* Choose a FB config which fits the above description */
fbc = glXChooseFBConfigSGIX(dpy, 0, attributeList, &nitems);
/* find an FBconfig in list with RGB == 10 and Zbuffer > 1 */
for(i = 0; i < nitems; i++)
{
glXGetFBConfigAttribSGIX(dpy, fbc[i], GLX_RED_SIZE, &a[0]);
glXGetFBConfigAttribSGIX(dpy, fbc[i], GLX_GREEN_SIZE, &a[1]);
glXGetFBConfigAttribSGIX(dpy, fbc[i], GLX_BLUE_SIZE, &a[2]);
glXGetFBConfigAttribSGIX(dpy, fbc[i], GLX_ALPHA_SIZE, &a[3]);
glXGetFBConfigAttribSGIX(dpy, fbc[i], GLX_DEPTH_SIZE, &a[4]);
printf("r = %d, b = %d g = %d a = %d z = %d\n",
a[0],a[1],a[2],a[3],a[4]);
if(a[0] == 10 && a[1] == 10 && a[2] 10 && a[3] == 0 && a[4] > 1)
{ match = i; break; }
}
if(!(cx = glXCreateContextWithConfigSGIX(dpy, fbc[match],
GLX_RGBA_TYPE_SGIX,
NULL, GL_TRUE)))
{
printf("Unable to create pbuffer context\n");
exit(0);
}
then use fbc[match] in glXCreateGLXPbufferSGIX or glXGetVisualFromFBConfigSGIX
as you need to.
You might implement a more clever scheme, I was just looking at the listing of
'findvis' and shooting for an RGB10 Z23 db visual ( with no accum buffer etc ),
you could specifically select no accum bits, check that it's db and all that to
make it more flexible. You might also what to make it flexible enough to get
the right thing on other platforms too.
Do you use Impact ? if you use Pbuffers on them: on a High Impact there are 3
special pbuffer timing tables available to you (1024x768_60_pbuf,
1024x768_72_pbuf, and 1024x768_76_pbuf).
You'll need to do
/usr/gfx/setmon -x 1024x768_76_pbuf
and then restart graphics.
Do you have an Maximum Impacts? There should be enough frame buffer space
available to run 1280x1024 and use a 12/12/12 pbuffer.
There is quite a bit of detail in the release notes for gl_dev in chapter 7.
BTW make sure you have a recent iR gfx patch. In order of age ( one replacing
the other, they are 1355, 1699 and now the most recent: 1808
Cheers
Rob
On Aug 11, 12:53pm, Robert Doyle wrote:
> Subject: glXMakeCurrentReadSGI
> Performers:
>
> On an Onyx1 IR (1 RM), Performer 2.1, the use of:
> glXMakeCurrentReadSGI(dsp, pw->getWSDrawable(),
> pbuffer, pw->getGLCxt); in the draw callback
> generates a bad match error ("X Error of failed request:
> BadMatch (invalid parameter attributes)"). The function
> is used to attach the GLX context to both the pfPipeWindow
> and a previously configured pbuffer. The object is to
> use glCopyPixels() to copy an image from the pbuffer to
> the visible color buffer. No error is generated from
> a previous rendering into the pbuffer. This code works
> fine on an O2.
>
> In addition, Roger Corron's demo program using pbuffers
> as backing store (backingstore.c) generates an
> "X Error of failed request: BadAlloc (insufficient
> resources for operation) at the glXMakeCurrentReadSGI()
> call on an IR but works fine on an O2.
>
> Is there a problem specific to the IR and if so, has
> anyone found a workaround?
>
> Thanks,
> Bob Doyle
>
>
> --
> Robert J. Doyle, Jr. http://overlord.nrl.navy.mil
> Code 5594 e-mail: doyle++at++overlord.nrl.navy.mil
> Naval Research Laboratory phone: 202-767-8395
> Washington, DC 20375-5000 fax: 202-404-7402
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Robert Doyle
--
________________________________________________________________
Rob Jenkins mailto:robj++at++sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:43 PDT