Rob Jenkins (robj++at++sgi.com)
Mon, 07 Dec 1998 06:25:55 -0800
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 can easily be 'pixel challenged' for a big pbuffer. What is likely
happening 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, I've tried this on iR, 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.
If you use Pbuffers on on Impact: 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.
Also, on O2 I expect the xscreen setting you have will effect hwo much
resource a pbuffer needs.
In the example you quoted of displaying remotely then you'd be using the
resources on the display machine.
The gfxinfo you have shows IMPACTSR which is Octane. You have 0TRAM (
texture memory ) so that makes it Octane SI ( SSI would be 2GEs and 2
REs, you only have one ).
Hope this helps.
Cheers
Rob
Liu Xiaoyan wrote:
>
> Hi, all,
>
> I'm badly comfused by Pbuffer, could you help me please?
>
> I managed to get /usr/share/Performer/libpf/pbuffer.c to work on O2.
> However, it failed on Octane(6.5, Performer 2.2) at the call
> glXMakeCurrentSGIX with an X Error:
> BadAlloc (.....insufficent resouce....). That function call tries to
> bind GL context to a normal pfPwin and a Pbuffer as well. Is it because
> of the following( from man pages):
>
> On RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality
>
> systems it is not possible to use a context for rendering to both
> windows
> and pixmaps.
>
> But I'm not rendering into both drawables, just reading from one of
> them.
>
> However, the program runs remotely from O2 by rlogin to the Octane? Why?
> Which frame buffer it uses in this case: octane's or O2's?
>
> What machine do I have when /usr/gfx/gfxinfo reports:
>
> Graphics board 0 is "IMPACTSR" graphics.
> Managed (":0.0") 1280x1024
> Product ID 0x2, 1 GE, 1 RE, 0 TRAMs
> MGRAS revision 1, RA revision 0
> HQ rev B, GE11 rev B, RE4 rev C, PP1 rev H,
> VC3 rev A, CMAP rev E, Heart rev E
>
> Another question, is it OK with multiple windows of different frame
> buffer attributes opened on one pfPipe?
>
> Thanks for your input,
>
> Liu
>
> ***********************************************************************
> Liu Xiaoyan Institute of High Performance Computing
> Research Engineer National University of Singapore
> Data Visualisation Group http://www.ihpc.nus.edu.sg Tel:(65)7709267
> ***********************************************************************
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- ________________________________________________________________ Rob Jenkins Silicon Graphics mailto:robj++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Dec 07 1998 - 06:33:34 PST