steve@cs.hw.ac.uk (Steven Salvini) (06/15/91)
A couple of weeks ago I posted a request for views on the comparative utility of the Sun NeWS/X server versus the mit X11R4 server. I have had an overwhelming response and I would like to take this opportunity of thanking all those who replied. I have tried to summarise the responses in the article below - in case anyone is interested, the jury is still out as to whether or not I trash OW completely in favour of the mit server. However, it is certain that even if OW does survive it will only do so to allow the use of old sunview applications awaiting upgrading to X compatibility and not because anyone actually *wants* it! The main points in favour of the mit server for us is its availability for a wide range of hardware - pretty essential for a network consisting of Sun3s, Sun4s in all their various possible configurations, HPs & DECstations - and the wide range of public domain software - again pretty essential in a poor university environment! ;-( (A number of people suggested that there is a need for something in the FAQ on the OW v. mit server debate - FAQ looker-afterers, wha'd'ya think?) Steve. Pro MIT server: ^^^^^^^^^^^^^^^ Server itself is smaller thus uses less disk space, less swap space and less real memory. The "installables" are also smaller. Extensions available include the "SHAPE" extension but not Display PostScript although this will be in R5. (Note that scalable fonts are still possible in R4 but you must build actual physical font files rather than simple Unix pipes.) Has better XDMCP support. Allows the creation of a uniform system across a wide range of different vendor platforms. Arguably less "buggy". Free - including free software, free "support" via the net. Lots of additional software in the public domain in a form that builds easily with the X11R4 setup; note that this is not generally so for the OpenWindows setup. Con: no Display PostScript, no commercial support, no accelerator board support, sunview compatibility must be built yourself, no "pageview". Pro NeWS/X server: ^^^^^^^^^^^^^^^^^^ Extensions available include Display PostScript allowing scalable fonts, etc. although "SHAPE" is unavailable in OW 2.0 despite Display PostScript in the base server!? "pageview" PostScript previewer as standard although "ghostscript", "xps" and "ralpage" are all public domain alternatives which run on the mit server. It is a commercial system thus you can demand commercial support. The server includes support for graphics accelerator boards plus server optimisation for Sun hardware. Easy compatibility for sunview applications. Con: memory/disk hog, no SHAPE extension, arguably buggier with slow turn-around times for bug fixes, must buy source, public domain software tough to build for OW, requires a higher spec machine, poor XDMCP support. ----- A number of people gave suggested "minimum configurations" for running OpenWindows - the consensus seemed to be a Sun3 with 8Mb or a Sun4 with 12Mb plus an appropriate graphics accelerator. ---- In summary, it would appear that the X/NeWS server is probably the server of choice for people who like to run "vendor-supplied software straight out of the box", who are happy to rely on Sun for software maintenance and who run only or mainly Sun hardware, preferably Sun4s with loadsamemory and graphics accelerator cards. On the other hand, the mit X11 server will appeal to those who don't mind "getting their hands dirty", who are happy to rely on the net, etc. for support and who regularly make use of public domain software. It would appear to be faster and less of a memory hog especially on Sun3s and machines lacking loadsamemory and "go-faster" boards. It is probably especially useful in environments running a wide range of machines from a wide range of vendors where a uniform system is required - important when trying to minimise the load on support staff and when trying to encourage use by novice users. =============================================================================== Steven Salvini 79 Grassmarket JANET steve@uk.ac.hw.cs Heriot-Watt University Internet steve%cs.hw.ac.uk@cunyvm.cuny.edu Computer Science NSFNET steve%cs.hw.ac.uk@nsfnet-relay.ac.uk EDINBURGH EH1 2HJ Scotland U.K. EARN/BITNET steve%cs.hw.ac.uk@UKACRL Phone (+44) 31 225 6465 (x455) UUCP steve%cs.hw.ac.uk@ukc.uucp
datri@convex.com (Anthony A. Datri) (06/16/91)
>Has better XDMCP support. Oh boy. >Con: no Display PostScript, no commercial support, I'm sure that there are plenty of people willing to take money to "support" MIT's X. ICS springs to mind, for example. >no accelerator board >support It'll "support" a GX, but not utilize it fully. >Pro NeWS/X server: >Extensions available include Display PostScript allowing scalable fonts, etc. >although "SHAPE" is unavailable in OW 2.0 despite Display PostScript in the >base server!? As I understnad it, "Display PostScript" is NeXT's stuff. Be careful not to confuse it with "NeWS". >"pageview" PostScript previewer as standard although "ghostscript", "xps" >and "ralpage" are all public domain alternatives which run on the mit server. Xps is an old version of ralpage. >It is a commercial system thus you can demand commercial support. For what it's worth. >The server includes support for graphics accelerator boards It'll run on a GS only in monochrome. It won't run on the cg8 or cg9, and won't take advantage of the gp's. It claims to take advantage of the cg6, but in practice the MIT server "feels" smoother. >plus server optimisation for Sun hardware. Read above. >Easy compatibility for sunview applications. When running a suntools program under the xnews server, you can't place any normal windows over the suntools window. >Con: memory/disk hog, no SHAPE extension, arguably buggier with slow turn-around >times for bug fixes, must buy source, public domain software tough to build for >OW, requires a higher spec machine, poor XDMCP support. I'll agree with most of that. You can always delete the things you don't use, though -- like any package. To my knowledge, XDMCP is used solely by xdm, and thus isn't of interest anyway. >On the other hand, the mit X11 server will appeal to those who don't mind >"getting their hands dirty", who are happy to rely on the net, etc. for support I've gotten more help from the net about the xnews server than from Sun. -- Fly to the sky on GI-GI____________ and shout to datri@convex.com
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (06/17/91)
In article <3241@odin.cs.hw.ac.uk> steve@cs.hw.ac.uk (Steven Salvini) writes: > >Pro MIT server >^^^^^^^^^^^^^^ > ... >Con: ..., no accelerator board support, ... > > >Pro NeWS/X server: >^^^^^^^^^^^^^^^^^^ > >The server includes support for graphics accelerator boards plus server >optimisation for Sun hardware. > It has been my understanding that the X11/NeWS servers (version 1.0 and 2.0) do not utilize accelerators, period. I have heard rumors that version 3.0 will. My benchmarks (using x11perf) show that the R4 MIT Server is, for the most part, faster than xnews for all but a few operations. 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. Keith also indicated that the R5 server will be even faster than the R4 server due, among other things, to newer, more efficient rasterization algorithms, and the judicious use of assembly. Perhaps Keith would like to comment? -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov No flashy sig. No clever quips. No famous quotes. This space for rent.
keith@expo.lcs.mit.EDU (Keith Packard) (06/18/91)
> 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. The SBus doesn't run fast enough to give the rectangle fill and copyarea rates which I've measured here. > In 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 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. 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). And the fancy polygon fill hardware doesn't match X pixelization rules, forcing the Xnews server to render them in software. 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. For example, if your application doesn't use any of the accelerated operations, you'd probably be better off with the dumb frame buffer, while applications which can take advantage of the fast operations will see substantial performance benefits when using the more expensive hardware. 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). 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. The new HP Snake series seems to fit in here - all of the X performance data I could get indicates that this is one hot piece of hardware (except that it doesn't render to VM - I don't know how it handles pixmap rendering). > Keith also indicated that the R5 server will be even faster than the R4 > server due, among other things, to newer, more efficient rasterization > algorithms, and the judicious use of assembly. R4 is a dog.
uad1077@dircon.co.uk (Ian Kemmish) (06/20/91)
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: >In article <3241@odin.cs.hw.ac.uk> steve@cs.hw.ac.uk (Steven Salvini) 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. >Kaleb Keithley kaleb@thyme.jpl.nasa.gov >No flashy sig. No clever quips. No famous quotes. This space for rent. Both unlikely and untrue. I added sun GX support to the X11r4 server and it was sufficiently much faster that I was very unwilling to give the card back when the owners wanted it back. Painting and scrolling were very fast. I could have tall emacs windows and go through files by sitting with my fingers om C-z and M-z, no problems. Wallclock performance on many things was better than 2D performance on a Personal Iris (which really *did* surprise me). I was developing a drawing program, and dragging large, complicated shapes round on the screen was a joy. Now, admittedly, the GX accelerator does seem to have been designed with X support firmly in mind, but even so, I was quite impressed. If only I didn't dislike using X so much:-) -- Ian D. Kemmish Tel. +44 767 601 361 18 Durham Close uad1077@dircon.UUCP Biggleswade ukc!dircon!uad1077 Beds SG18 8HZ United Kingdom uad1077@dircon.co.uk
Bob.Rocchetti@eng.sun.COM (Bob Rocchetti) (06/20/91)
>> 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