helman@isl.Stanford.EDU (Jim Helman) (10/25/88)
In article <20940@sgi.SGI.COM> mtoy@xman.SGI.COM (Michael Toy -- The S.G.I. XMAN) writes: >I believe the published speed for copying pixels to the screen from user memory >on the GTX series machines IS 8 million pixels per second. . . . It should have >been "on the multi-processor 4D series". If 8 megapixels/sec is a real number for the GTX series, I'm glad to see the problem is resolved on the new machines. But, the fact remains that the pixel performance is much lower on the single processor 4D machines. On our 4D/70GT, I've observed writepixels() performance of around 150,000 pixels per second. If this poor performance is caused by a fundamental limitation in the GT hardware, then there won't be much improvement from future versions of GL or the microcode. Could someone from SGI please give us a straight line on this? Does all this pose a hard limit on the performance of X, even in plain monochrome windows? And what improvement can we reasonably expect in future releases? In article <128@mlogic.UUCP>, marcel@mlogic.UUCP (Marcel Samek) writes: > >If you wish to read pixels from the frame buffer, the performance is >significantly slower than if you wish to write pixels. Then it should be possible for the server to shadow the window with a pixmap resident in processor memory. Unless reads and writes are concurrent, this would eliminate the read time, which should make raster ops that require both reading and writing to the window more than twice as fast. That's nothing to sneeze at, and I'd gladly trade the memory usage for the speed. In article <128@mlogic.UUCP>, marcel@mlogic.UUCP (Marcel Samek) writes: > >It is disappointing to see Silicon Graphics employees post such deceptive >garbage to the net. I doubt it was intentional. Actually, I'm more disappointed by SGI's lack of forthrightness in addressing this issue. More than two months ago, I raised it with our salesman, demonstrated the problem for him and his manager, called the hotline and finally posted to this newsgroup. I got a little information from various people by private mail. Then, I gave up. So far no one at SGI has been willing to openly say what the problem is, in which products it exists and what if any solutions are possible. Why doesn't someone at SGI put all the speculation and false expectations to rest? Jim Helman (jim@thrush.stanford.edu) Department of Applied Physics Stanford University