dshr@SUN.COM (David Rosenthal) (08/16/88)
> Is color support (on the Sun 4) planned for the Sun server under release 3 > of X11 ? How about backing store ? The R2 release supports color (at its normal lethargic pace) on Sun4/260C and Sun4/110C configurations. Adam de Boor has supplied MIT with backing store support that is machine independent - we use it on all Sun configurations. > > I also have a question about how the Sun server is implemented: > Does it use pixrect calls for all of the graphic operations ? > If not, where are all of the low level routines that write to the frame > buffer. I have been looking under server/ddx/sun for the source that > does this, but I am a little confused. > All the code to drive all Sun displays by treating them all as memory is contained in the directories ddx/sun, ddx/mi, ddx/mfb, and ddx/cfb. The fact that the server treats all Sun displays as memory, without using the hardware ROP support, is part of the reason why it is slow on color Suns. No pixrect code is used at all. For details, see the paper "Godzilla's Guide" that Adam & I wrote - it is in the R2 documentation. David.
schultz@NRL-AIC.ARPA (Alan Schultz) (08/16/88)
Will the MIT Sun server in R3 use "hardware ROP" or pixrect, or will it be implemented as it currently is?
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/16/88)
Date: Tue, 16 Aug 88 08:40:05 EDT
From: Alan Schultz <schultz@nrl-aic.arpa>
Will the MIT Sun server in R3 use "hardware ROP" or pixrect,
or will it be implemented as it currently is?
The R3 Sun server will be implemented as currently, except
hopefully with a number of performance improvements, unless
someone is willing to donate a hardware-specific ddx.rgs@corona.megatek.uucp (Rusty Sanders) (08/17/88)
From article <8808152051.AA00237@devnull.sun.com>, by dshr@SUN.COM (David Rosenthal): >> >> I also have a question about how the Sun server is implemented: >> Does it use pixrect calls for all of the graphic operations ? >> If not, where are all of the low level routines that write to the frame >> buffer. I have been looking under server/ddx/sun for the source that >> does this, but I am a little confused. >> > All the code to drive all Sun displays by treating them all > as memory is contained in the directories ddx/sun, ddx/mi, > ddx/mfb, and ddx/cfb. The fact that the server treats all > Sun displays as memory, without using the hardware ROP > support, is part of the reason why it is slow on color Suns. > No pixrect code is used at all. > > David. I disagree with the statement that the sun server needs to use pixrect and the hardware rop operations to get good performance. I've taken the current color server (which is practically unusable with it's current performance) and played with it a little bit. I have used no pixrect or hardware rop operations. In my examination of the code practically all of the operations to memory really need to be just source rop operations. It doesn't take much hardware to do that. The problem with the sun performance isn't that it's not using the hardware avaiable, it's that the cfb code is really really slow. I've reimplmented the sections of code that I cared about. Mostly that means I spent a lot of time on glyph generation, area copy (scrolling et al), and line generation. My glyphs now run about 16-20 times faster then the old terminal emulator code (cfbTEGlyphBlt), and only about 1/2 as fast as the mono code. The other glyph stuff runs about 60 times faster, since the cfb code uses the mi layer for clipped TE glyphs and for poly glyphs. Solid fill is sped up by about a factor of 10, scrolling and region move by a factor of 2 to 8 (just too many bits to move around). After all these changes the sun server is actually quite nice to use on a color monitor. And note I haven't had to use any sun specific functions, so the code could be made just as portable as the current cfb code. Note that last statement, the code is currently rather non portable. I don't take into account bit or byte order, and I tended to be lazy in places about word and pixel sizes and depths. It wouldn't be too hard to fix up tho. Unfortunatly, don't ask me to send the stuff out right now. The code is being used on Megatek's new workstation's implementation of X, and we're not releasing the code right now. Maybe later. In any case, the point is that the cfb code isn't slow because it doesn't use pixrects. It's slow because it's really stupid (altho portable and easy to implement). It also doesn't eat up much memory (I "threw memory at the problem" to get some performance, especially with glyphs). I'm trying to get permission to send my improvements, but it won't be soon (if at all). But it's just not true that to get X performance on a sun you have to use pixrects. In fact, I can probably get better performance without it just by useing good code. Rusty Sanders, Megatek Corp. --> rgs@megatek or... ...ucsd! ..hplabs!hp-sdd!megatek!rgs ...ames!scubed!
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/17/88)
Date: 16 Aug 88 17:43:47 GMT
From: ucsdhub!hp-sdd!megatek!corona!rgs@ucsd.edu (Rusty Sanders)
I disagree with the statement that the sun server needs to use pixrect and
the hardware rop operations to get good performance.
It does depend somewhat on which Sun hardware you use. As I recall, on
at least some Sun configurations, the frame buffer is being accessed
through a slow diagnostic port, which makes for inherent performance
problems, not matter how much you speed up the code. But, I certainly
believe you can do a lot to speed up cfb without resorting to hardware
specifics.david@sun.uucp (David DiGiacomo) (08/17/88)
In article <19880816201951.6.RWS@KILLINGTON.LCS.MIT.EDU> RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) writes: > > Date: 16 Aug 88 17:43:47 GMT > From: ucsdhub!hp-sdd!megatek!corona!rgs@ucsd.edu (Rusty Sanders) > > I disagree with the statement that the sun server needs to use pixrect and > the hardware rop operations to get good performance. > >It does depend somewhat on which Sun hardware you use. As I recall, on >at least some Sun configurations, the frame buffer is being accessed >through a slow diagnostic port, which makes for inherent performance >problems, not matter how much you speed up the code. But, I certainly >believe you can do a lot to speed up cfb without resorting to hardware >specifics. This is a little misleading. Of the Sun frame buffers supported by X11, only the "cgtwo" type has on board graphics hardware (the infamous "rasterop chips"). It also has an access mode where it appears to be an 8 bit memory frame buffer, and this is what is used by the X11 Sun ddx code. Note that this is not a "diagnostic port" and it is not slow! It is just another mode which is available. There is nothing magical about the pixrect library. The "memory pixrect" part of the code is just a fairly well-written (in my opinion anyway) and not very portable (although it runs on 680x0s, SPARCs, and 386s) implementation of ideas very similar to mfb/cfb. This is what drives the most common Sun frame buffers: "bwtwo", "cgthree" (Sun-386i), and "cgfour". No hardware specifics are involved. You can certainly get good performance from even a "cgtwo" by treating it as a memory frame buffer and driving it with well written code, but you can do even better by taking advantage of the hardware features: 128 bit data path, function unit, shifter, edge and plane masks, etc.