From: christopher.g.dorosky++at++lmco.com
Date: 03/21/2000 00:33:17
Ok, but first, I have to take back the pipe statement. It is more likely
that pipe1 takes a long time. Pipe0 can take a long time too.
It is difficult to get code out of our area, so here are some fragments:
This is a Pre-draw callback, tied to channel 0 (pipe 0)
mytex is initialized to a pftexture.
static int times=0;
mytex->getImage(&image, &comp, &s, &t, &r);
if(!times){
if(mytek->isLoaded()) return; // plus do some logic so that this texture is
not set up to be loaded again
}
check to make sure its a 1024 by 1024 texture
gettimeofday(&tp, &tzp);
oldsec=tp.tv_sec;
oldusec=tp.tv_usec;
mytex->subload(0, image, 0,500,1024,0,500,1024,1);
// I didn't understand the subload documentation. I set the format to allow
subloading when the texure was created, then
// couldn't figure out the setimage comment about loading from the bottom
up. Tried many different origins, and decided that
// I could load somewhere in the middle and it would be ok for a test.
// if there is no subloading, and I call up the texture either by a direct
load, or by virtue of looking at it, then it has correct coordinates, which
show up as 0,0 for src and dest, and sizes of -1 -1
gettimeofday(&tp, &tzp);
tempt=(double)(tp.tv_sec - oldsec) + ((double) (tp.tv_usec
-oldsec))*.000001;
if(tempt>.002)
printf("Took %lf sec to load part %d of '%s'\n", tempt, times,
mytex->getName());
times++;
if(times>63) {
times = 0;
logic to make that texture not go through this again.
}
Originally I had a more complex subload that tried to index the 1024 by
1024, but since I thought I might be doing something wrong, I thought I
would settle for the same piece in the middle, over and over as a test.
When it causes problems, it takes anywhere from 33.3335 ms (we run 30Hz) to
108ms to load the first line only.
Each successive time though it takes a couple of usecs.
Playing with the numbers (origins) can result in strange times to almost
exact multiples of the frame time 1-3 times + 4-5 usecs)
A forced load() usually has better results.
I am running ONYX2, RE2, 2 pipes both with 64M texture, 16 cpu, irix 6.5.6
Help!
Christopher Dorosky
Senior Electronic Systems Engineer - Real Time Simulation
Lockheed Martin Missiles and Fire Control - Dallas
christopher.g.dorosky++at++lmco.com
972-603-2349
> ----------
> From: Angus Dorbie[SMTP:dorbie++at++sgi.com]
> Sent: Monday, March 20, 2000 7:10 PM
> To: christopher.g.dorosky++at++lmco.com
> Cc: info-performer++at++sgi.com
> Subject: Re: Texture pre-loading
>
> I can't explain this. Can you post your code?
>
> It should just download, maybe you have some software lock or perhaps
> pipe 0 is busy with something else or maybe you download twice to pipe
> 1. Perhaps you have oversubscribed TRAM on pipe 0. Does it have the same
> texture memory capacity? Maybe it's the duplicate system memory access
> but I very much doubt it.
>
> What is the hardware? Are you sure you do this in separate processes
> draw callbacks? From some of your comments it doesn't sound like it.
>
> The pipes don't share texture memory so it's very much required that you
> d/l to each pipe.
>
> Cheers,ANgus.
>
> christopher.g.dorosky++at++lmco.com wrote:
> >
> > Hello,
> >
> > I am trying to pre-download texture in my application.
> >
> > In a post draw callback, I found that I can use the pftexture->subload
> to
> > load in pieces of a large texture at a time.
> > However, the operation is not equally efficient in both pipes.
> >
> > On our two pipe system, if I do the subloading in pipe 0 only, each
> piece
> > takes usecs of time.
> > On pipe1, it can take 34ms to load the same piece which pipe 0 has
> already
> > loaded in.
> > Our frame rate is 30Hz, so I suspect that most of the 34 ms is 33 ms
> frame
> > hang waiting for pipe0 to do something.
> >
> > Does anybody have any idea why a texture that was just loaded into
> pipe0's
> > texture memory could take so long to load into pipe1's?
> >
> > Is this even necessary? Do pipe0 and pipe1 implicitly share the texmem?
> >
> > Chris
> >
> > Christopher Dorosky
> > Senior Electronic Systems Engineer - Real Time Simulation
> > Lockheed Martin Missiles and Fire Control - Dallas
> > christopher.g.dorosky++at++lmco.com
> > 972-603-2349
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --
> For Performer+OpenGL tutorials http://www.dorbie.com/
>
> "In the middle of difficulty lies opportunity."
> --Albert Einstein
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
This archive was generated by hypermail 2b29 : Tue Mar 21 2000 - 00:34:13 PST