panisset@McRCIM.McGill.EDU (Jean-Francois Panisset ) (05/09/91)
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?).
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.
Thanks in advance for any information you might provide,
JF Panisset
--
Jean-Francois Panisset
INET: panisset@mcrcim.mcgill.ca
panisset@larry.mcrcim.mcgill.edu
UUCP: ...!mcgill-vision!panisset kurt@cashew.asd.sgi.com (Kurt Akeley) (05/09/91)
In article <1991May8.230648.17151@thunder.mcrcim.mcgill.edu>, panisset@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