From: Angus Dorbie (dorbie++at++sgi.com)
Date: 04/03/2000 10:35:40
Jean-Luc Dery wrote:
>
> On Apr 3, 8:21am, Angus Dorbie wrote:
> > Subject: Re: Draw lock-up
> > Sounds like you are either oversubscribing texture memory or suddenly
> > drawing many new elements of the database with texture on them for the
> > first time forcing a significant download overhead.
>
>
> We have since then tracked down the SGI bug entries that might relate to this.
> You will find those in the attachments.
>
Only one of the bugs seemed remotely related, and it's not a bug. It's
closed in the tracking system and you're expressing a vague desire for
optimal performance.
The other issues you listed are important but unrelated. I hope your
other issues get resolved soon, looks like you got bitten by a
regression problem and a context sharing problem, that's really bad
news, but doesn't reflect on the status of this users problem.
> >
> > Try pfumaketexlist followed by pfudownloadtexlist after you build your
> > scene.
>
> This cannot resolve the problem when dynamic texture management is needed.
I hope I've made it clear what the solution is in either case. Mose of
the inquiries along these lines are resolved by this, so I offer the
information because more than likely it's very worthwhile to the person
suffering the problem.
>
> >
> > Also, use stats to count downloads.
> >
> > Reducing texture size as you have would prevent oversubscribing TRAM and
> > reduce any paging overhead by a factor of 4, so it's unclear which is
> > your problem.
>
> Could it be something in IRIX ???
I detect a negative undercurrent, that's unfortunate but beyond my
knowledge. I hope my view on this problem doesn't offend you further. It
seems to me we're a LONG way away from concluding that this users
problem is a bug in IRIX. There are two possible scenarios I've
outlined, both extremely common. In the case of oversubscribing texture
memory, memory has to be allocated on the host and the texture swapped
OUT of the graphics pipe and the new texture data downloaded TO graphics
after the old texture has been pulled from the pipe. That is a big burp
in a real-time system. The wise solution for the application is to avoid
this overhead and either don't oversubscribe or rigorously manage
texture memory yourself. Performer unfortunately does not provide
sophisticated texture memory management for conventional textures, it
simply relies on the underlying OpenGL and the application.
Cheers,Angus.
-- For Performer+OpenGL tutorials http://www.dorbie.com/"In the middle of difficulty lies opportunity." --Albert Einstein
This archive was generated by hypermail 2b29 : Mon Apr 03 2000 - 10:35:48 PDT