From: Dorosky, Christopher G (christopher.g.dorosky++at++lmco.com)
Date: 08/14/2002 11:19:33
Many of these read/writes from RAM to video memory are optimized
to work like cliptextures. Try loading in strips, and try swapping
length and width sizes.
Chris Dorosky
Lockheed Martin - TOPSCENE
-----Original Message-----
From: Performer Newsgroup [mailto:csklu_pf++at++yahoo.com]
Sent: Wednesday, August 14, 2002 10:51 AM
To: Benedikt Kessler; w.price++at++electronic-alchemy.co.uk
Cc: info-performer++at++sgi.com; Performer Newsgroup
Subject: Re: [info-performer] depth buffer write is slow.
I did try using the unsigned short and that was
actually much much slower??? Channel stats reported
(for 75Hz vertical refresh rate, 1024x1024 sized
channel, GeForce3):
draw to color buffers: 75Hz
draw to depth buffer using GL_FLOAT: 12Hz
draw to depth buffer using GL_UNSIGNED_SHORT: 3Hz
Performance increased slightly for smaller window
sizes.
I'll try the the tiling method to see if that works.
Unfortunately I am not running on an IR, it wouldn't
fit very nicely under my desk at home anyways.
--- Benedikt Kessler <bjk++at++munich.sgi.com> wrote:
> Hi!
>
> w.price++at++electronic-alchemy.co.uk wrote:
> >
> > csklu_pf++at++yahoo.com wrote:
> > > Performers,
> > >
> > > Again maybe another OpenGL question: I'm writing
> > > values to the depth buffer directly using:
> > >
> > > glDrawPixels( width,height, GL_DEPTH_COMPONENT,
> > > GL_FLOAT, depths).
> > >
> > GL_UNSIGNED_SHORT data will be faster than
> GL_UNSIGNED_INT since you have half as much data
> being sent (sizeof(int) is usually 4,
> sizeof(unsigned short) usually 2).
> >
> > Another possible speedup which I have found across
> using glDrawPixels() on Linux is to NOT send the
> entire chunk of data in one go. i.e. instead of
> using
> >
> > glDrawPixels(1024, 768, ....)
> >
> > use
> >
> > glRasterPos2i(0, 0);
> > glDrawPixels(128, 128, ...., buffer);
> > glRasterPos2i(128, 0);
> > glDrawPixels(128, 128, ...., buffer + offset);
> > .....
> > .....
> > (most likely this will be in a loop)
> >
> > I don't know the details of why, but this was
> twice as fast for me to draw pixels to the screen.
> Best tile sizes were 128x128 and 64x64, I think.
> >
> > You would have thought that the one call would
> have been faster since there's less overhead than
> multiple calls, but experiments have proved
> otherwise.
>
> Probably you were using an InfiniteReality* system.
>
> One these systems you might do some experiments with
> the two environment
> variables GLKONA_DMATHRESHOLD_IMAGE and
> GLKONA_DMATHRESHOLD_SCANLINE.
> These threshold values (in bytes) control weather a
> PIO (eats up CPU
> time) or DMA (CPY might be available for other
> things) will happen.
>
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
-----------------------------------------------------------------------
List Archives, Info, FAQ: http://www.sgi.com/software/performer/
Open Development Project: http://oss.sgi.com/projects/performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
-----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Wed Aug 14 2002 - 11:20:33 PDT