From: Angus Dorbie (dorbie++at++sgi.com)
Date: 03/21/2000 10:21:43
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
This archive was generated by hypermail 2b29 : Tue Mar 21 2000 - 10:22:00 PST