Fast frame buffer animation question

[Kurt Akeley]

In article <1991May8.230648.17151 at thunder.mcrcim.mcgill.edu>, panisset at McRCIM.McGill.EDU (Jean-Francois Panisset ) writes:
|> Here is a question for all you GL gurus out there:
|> 
|> I am trying to generate short (a few seconds), fast (ideally 60 Hz) animation
|> sequences using small pre-computed images (probably around 128x128).
|> I have tried lrectwrite, but it seems
|> that the bandwidth from CPU memory to frame-buffer memory is just not there
|> (I have not tried this on a VGX though: what kind of throughput numbers can
|> you get? I'd be happy with 1Mb/s, happier with 4 Mb/s. Also, will setting
|> pixmode pixel size to 8 bits give me faster or slower performance?).

I benchmark the GTX rectwrite performance at 7.5 million 16-bit pixels per
second.  This is more than adequate to handle 60Hz update of a 256x256
image, so 60Hz update of a 128x128 image should be easy.  The key to actually
achieving this performance is to lock all images into memory before you begin
the animation.  The required IRIX call is

    mpin(buf,bytesize);

where buf points to the start of the image data.

|> So the next idea
|> is to store all the images in the frame buffer and use rectcopy to bitblt
|> them onto the same spot. I get better results this way, but the problem is
|> that I can only fit a few images in the frame-buffer. Since my images a
|> grey-scale, I only need 8 bits for each image: I know I can specify source
|> and destination for rectcopy between the front and the back buffer on
|> a system, but what about within a single buffer? One of the systems is
|> a GTX with (I believe) double-buffered 24 bits: if I could use the extra
|> 16 bits of each buffer which I don't need for my 8 bit images, I could
|> store many more images in the buffer.

In general it is a better strategy to copy images from host memory than
to copy them around in the framebuffer.  This is because the framebuffer
copy requires two framebuffer accesses per transfer (one read, one write),
hence twice the framebuffer bandwidth of the host memory transfer (one
read of host memory, one write of the framebuffer).  On the GTX framebuffer,
for example, copy peak performance is 4 million pixels per second, roughly
half the 7.5 million pixel per second rectwrite performance.

Still, the framebuffer copy method will work in your application.  You can
store up to 80 images in each of the front, back, and z buffers, for a total
of 240 images.  (It is not possible on the GTX to store separate 8-bit
images in the red, green, and blue bitplanes - there is no shift operation.)
Use the overlay bitplanes to obscure all but a single 128x128 region of the
screen.  Use readsource and rectcopy to transfer images from the front, back,
and z buffers to the backbuffer, swapping buffers after each transfer.  Note
that your notion of front or back for rectread purposes also swaps each time
swapbuffers is called!

I've seen code here at SGI to do this animation.  Perhaps someone else will
post a pointer to this code.

|> 
|> Thanks in advance for any information you might provide,
|> 
|> JF Panisset

-- Kurt