Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!ora!bloom-beacon!dont-send-mail-to-path-lines
From: Bob.Rocchetti@eng.sun.COM (Bob Rocchetti)
Newsgroups: comp.windows.x
Subject: Re: NeWS/X v. mit X11 server - summary of responses
Message-ID: <9106200156.AA16574@cupertino.Eng.Sun.COM>
Date: 20 Jun 91 01:56:10 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 74

>> It has been my understanding that the X11/NeWS servers (version 1.0
>> and 2.0) do not utilize accelerators, period.
>
>Unless you've got some strange release of OpenWindows, Xnews from 2.0
>uses the LEGO for operations which it can.

Xnews from version 1.0 on have used the GX (Lego) accelerator.

>The SBus doesn't run fast enough to give the rectangle fill and
>copyarea rates which I've measured here.

You are correct, rectangle fills and copyarea use hardware to do
the entire operation.  The SBus is only used to send coordinates
and initiate the operation.

>> 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 don't think this is a direct quote.  In particular, I know that the
>Sun LEGO accelerator is capable of drawing long zero-width lines,
>filling solid rectangles and copying data around on the screen faster
>than the completely dumb frame buffer.

The GX is capable of drawing all length zero-width lines, filling solid,
opaque stipple and stipple rectangles and copying data onto and around the
screen faster than the dumb framebuffer.

>These operations are very useful for many GUI-style activities.
>However, it is also true that for short lines, or for text, the
>overhead of communicating with that particular accelerator is greater
>than the performance gained by using it (or at least so my measurements
>using the OW2.0 server show).

I disagree, setting up the "pipeline" on the GX only requires a
few instructions.  For example, our measurements show GX 1 and 10
pixel line segments being 2 times faster than dumb framebuffer code.
Short text strings show a similar improvement.

>And the fancy polygon fill hardware doesn't match X pixelization
>rules, forcing the Xnews server to render them in software.

The GX pixelization rules do match the X pixelization
rules.  The hardware renders triangles, trapezoids, rectangles and most
quadralaterals directly.  Even if the GX can't render the object
directly it still renders the decomposed object. 

>It is also the case that the LEGO card provides slow access to the
>frame buffer for the CPU, making dumb frame buffer operations slower
>on this card than on the CG3 - this gives you an opportunity to
>choose the board which more closely matches your application needs.

The dumb framebuffer interface was added to the GX very late in its
design and gets little use from Sun software.

>If only Sun would allow the customer to make this choice -
>I, at least, was unable to purchase a SS2 with the dumb frame buffer,
>except by getting a monochrome SS2 and adding a separate CG3
>(total price > SS2+LEGO).

I'll pass your request on to Sun marketing.

>It is also possible to build hardware which doesn't suffer from
>these performance problems; simply design it carefully taking into 
>consideration the needs of the X server.

Other than dumb framebuffer accesses, exactly what performance problems
are you refering to?

The GX was designed to meet the needs of a wide range of graphics
needs.  The X11 graphics primitives represent a relatively small
subset of operations it can accelerate.

Bob Rocchetti (GX software) rjr@Sun.COM