From: Angus Dorbie (dorbie++at++sgi.com)
Date: 03/21/2000 14:37:54
FYI -
There ws a lot of confusion on this thread and it turns out that
pfudownloadtexlist was all that was required to solve the underlying
problem.
CHeers,Angus.
Angus Dorbie wrote:
>
> Try testing the download time only by calling glFinish before the d/l
> then taking the start time then downloading then calling glFinish then
> taking the end time. You may find that what you are seeing is some delay
> due to context creation or something at the start and the subload forces
> a block, but subsequently passes straight through.
>
> Cheers,ANgus.
>
> christopher.g.dorosky++at++lmco.com wrote:
> >
> > 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
> > >
>
> --
> 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
-- For Performer+OpenGL tutorials http://www.dorbie.com/"In the middle of difficulty lies opportunity." --Albert Einstein
This archive was generated by hypermail 2b29 : Tue Mar 21 2000 - 14:38:07 PST