Re: Urgent: OpenGL vs Performer Texture management

New Message Reply Date view Thread view Subject view Author view

Rob Jenkins (robj++at++sgi.com)
Thu, 04 Mar 1999 07:11:31 -0800

Isabelle Lafon wrote:
>
> Hello everybody,
>
> This is more an openGL question than a Performer question.
> But if someone could help us on this problem, it will be
> very very appreciate.
>
> Our program has two modules: The first one is built with openGL;
> the second one with Performer.
> We are running on an Onyx InfiniteReality2 with 512 Mbytes Main Memory
> and 64Mbytes Texture Memory.
> The performer module is able to handle scene with 70Mb of Textures
> without
> complaining. But the openGL module, crashes in the glTexImage2D call
> when
> 64Mbytes of texture is reached. See the dbx stack at the end of the
> mail.
> The error message displayed is
> ERROR: Failed Texture Manager Malloc -- Exiting
>
> What does performer relative to the texture memory management that
> openGL do not ?
>

Performer is probably using OpenGL functions like
glAreTexturesResident() and glPrioritizeTextures() to see what can fit
in and also let low pri textures get unloaded. Performer may also be
resuing texture memory space for different textures ( via
glTexSubImage2D ), it would depend on the pfTexture settings you have.
It's seem a bit hostile that the texture manager just bails on your
OpenGL when it runs out of memory ( which is the cause of the error ), I
think there's a request in to make it return GL_OUT_OF_MEMORY or
something instead of exit(), that would be more friendly but not solve
you problem. Can you implement some basic texture paging perhaps ?
Currently your don't really know when you'll be paging ( or about to run
out of memory ), if you defined some 'scratch pad' textures that you
paged into with glTexSubImage2D and prioritise textures you can control
the paging more. Do you really exit as soon as texture use >= 64Mb ? I'm
not sure but I would expect the OS/GL to handle that case, just start
paging. Do you have standard systune set up ? ( anything not default is
listed in /var/sysgen/stune ) I *think* systune increase of
gfxlockablemem could help this problem but I'd be very wary about
messing with parameters like that too much, in short:

You probably should make the OGL code manage texture usage and paging.
You might be able to tune the system to avoid the exit, or, maybe you
have hit a texture manager problem in patch 3543, can you emulate the
OGL texture loading you do in a short test case ?

What was it in the trace that made you think mip maps were being built ?

Cheers
Rob

> Looking at the stack below, it seems that openGL is trying to allocate
> a mipmap level even though there is no texture mipmaping specified
> (texture MIN_FILTER is GL_LINEAR and the glTexImage2D
> call passes a level 0 argument).
>
> There is a token GL_GENERATE_MIPMAP_SGIS in the openGL include
> file. I know that performer generate texture mipmap by default
> (the pfTexture PFTEX_GEN_MIPMAP_FORMAT default value is TRUE).
> Does OpenGL do a similar thing ?
> Do someone know when and where this GL_GENERATE_MIPMAP_SGIS token
> is used by openGL (which openGL function) ?
>
> dbx stack:
> ==========
> 0 __exit(0x1, 0xfb4cf00, 0xfb4d098, 0x0, 0xffffffff, 0xfb521d0,
> 0xfb512f8, 0x10ea7770)
> ["/xlv24/patches/3312/work/irix/lib/libc/libc_n32_M4/gen/cuexit.c":29,
> 0xfad1d60]
> 1 allocLevelImage(0x1, 0xfb4cf00, 0xfb4d098, 0x0, 0x0, 0xfb521d0,
> 0xfb512f8, 0x10ea7770)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_api.c":917,
> 0xda84924]
> 2 copyBackLods(0x0, 0x114928b8, 0xfb4d098, 0x0, 0xffffffff, 0xfb521d0,
> 0xfb512f8, 0x10ea7770)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_api.c":3532,
> 0xda8a918]
> 3 __glKonFreeAllocedTexObjBank(0x1, 0x114928b8, 0xfb4d098, 0x0,
> 0xffffffff, 0xfb521d0, 0xfb512f8, 0x10ea7770)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_api.c":6899,
> 0xda92af4]
> 4 getFreeBank(0x10eb1380, 0x0, 0x11576614, 0x11118, 0x14cd0200, 0x0,
> 0xfb512f8, 0x0)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_mem.c":679,
> 0xda94c18]
> 5 __glKonTexAlloc(0x10eb1380, 0x14cd0200, 0x0, 0x0, 0xffffffff, 0x0,
> 0x0, 0x10ea7770)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_mem.c":1076,
> 0xda956c4]
> 6 configTexture(0x1, 0x14cd0200, 0xfb4d098, 0x0, 0x0, 0xfb521d0,
> 0xfb512f8, 0x10ea7770)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_api.c":4209,
> 0xda8c214]
> 7 checkTexImage(0x2, 0x0, 0x0, 0x400, 0xffffffff, 0x0, 0x10eaede8, 0x0)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_api.c":5001,
> 0xda8e1c0]
> 8 __glkonim_TexImage(0xde1, 0x0, 0x8058, 0x400, 0x200, 0x0, 0x0, 0x0)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_api.c":5224,
> 0xda8e864]
> 9 __glkonim_TexImage2D(0x1, 0xfb4cf00, 0xfb4d098, 0x0, 0xffffffff,
> 0xfb521d0, 0xfb512f8, 0x10ea7770)
> ["/xlv11/patches/3543/work/gfx/lib/opengl/KONA/texture/kon_texture_api.c":5407,
> 0xda8ee8c]
> 10 adbTexture::bind(void)(0x11562630, 0xfb4cf00, 0x0, 0x0, 0xffffffff,
> 0xfb521d0, 0xfb512f8, 0x10ea7770)
>
> Thanks for your help,
>
> Isabelle.
>
> --
> Isabelle Lafon Discreet Logic
> Tel: (514) 954-7157 10 Duke
> Fax: (514) 393-0110 Montreal (Quebec)
> isabelle++at++discreet.com Canada, H3C 2L7
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
________________________________________________________________
Rob Jenkins	Silicon Graphics 	mailto:robj++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Thu Mar 04 1999 - 08:33:07 PST

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