skk@netcom.com (Stuart Kreitman) (06/18/91)
In article <1991Jun17.155835.26173@thyme.jpl.nasa.gov>, kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: |> On a separate, but related subject, Keith Packard, in his discussion of |> Server internals at Xhibition a couple of weeks ago, indicated that he has |> tested, and found that (almost) none of the accelerated frame buffers (Sun, |> or otherwise) provide any usable performance improvement for GUI type drawing |> activity. In a nutshell, he said that the overhead of setting up the |> accelerator pipeline, putting the instructions into the pipeline, and then |> closing the pipeline, negated any possible advantage. I agree that setting up and tearing down the pipeline puts a coprocessor type graphics accelerator at a disadvantage with respect to the successes of Keith Packard and Joel McCormick (decwrl) in optimized dumb FB support. On the other hand, there are situations where even the theoretically perfect (X.V11R2001?) single processor X server on a workstation is a dog: + If one or a number of windows are displaying continuous output. + If the system load average is significant for even an non-X reason. + Interesting X Extensions. ...because the window system and your GUI activities compete for constricted resources. Clicking, moving, and resizing can become painfull. x11perf numbers are less relevent IN THESE ENVIRONMENTS. Peak performance != performance under load. In these cases, off-loading server drawing and protocol stack to coprocessors is attractive. Flamers: go for it, but keep things in context! skk -------------------------- Why must I be like that? Why must I chase that cat? Must be the DOG in me! uh-tom-mic DO-OG!