Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!allen
From: allen@wrl.dec.com (Allen Akin)
Newsgroups: comp.windows.x
Subject: Re:  How to get 24-bit pictures on DECstation 5000/200PXG?
Message-ID: <1991Feb8.003711.18574@pa.dec.com>
Date: 8 Feb 91 00:37:11 GMT
References: <9102020056.AA25076@hydro.Saic.COM> <15870.27b18964@levels.sait.edu.au>
Sender: news@pa.dec.com (News)
Reply-To: allen@atd.dec.com (Allen Akin)
Organization: DIGITAL Advanced Technology Development, Palo Alto, CA
Lines: 90

In article <15870.27b18964@levels.sait.edu.au> Chris.Rusbridge@levels.sait.edu.au writes:
>In article <9102020056.AA25076@hydro.Saic.COM>, xpert@hydro.saic.COM 
>(xpert_news) writes:
>
>We have reports from at least two software companies of serious
>graphics performance difficulties with their ports to DECstation 5000s
>with the PX (8 bit plane) and PXG 24 bit plane options. 
>
>...

Paul Jensen replied to this note in comp.windows.x, but his reply was not
cross-posted.  Here it is:

>From: jensen@wrl.dec.com (Paul Jensen)
>Subject: Re:  How to get 24-bit pictures on DECstation 5000/200PXG?
>Message-ID: <1991Feb7.221431.9199@pa.dec.com>
>Keywords: DECstation PX PXG 24planes
>Organization: DEC Advanced Technology Development, Palo Alto, CA
>References: <9102020056.AA25076@hydro.Saic.COM> <15870.27b18964@levels.sait.edu.
>au>
>Date: Thu, 7 Feb 91 22:14:31 GMT
>Lines: 48
>
>>We would very much appreciate any advice
>>from users with actual experience of these PX and PXG 24 bit plane
>>options, to help us work out how to respond.
>
>By all means communicate with other users, but be sure
>1) that their application is similar enough to yours for comparisons
>to be valid; 2) to filter out unsubstantiated reports of problems,
>problems with low information content, and problems which have been
>corrected in subsequent releases.
>
>The rendering chips used in the PX[G] options were designed primarily
>to accelerate 2D & 3D drawing operations (points/lines/triangles).
>For the most common cases (e.g. 0-width solid lines), these primitives
>are 2-4 times faster than the DS3100 (as measured by X11perf), while
>using fewer host cycles.  Applications depending on XDrawSegments
>or XFillPolygon should run at hardware speed: I would be interested
>(as one of the principals of the PX[G] server port) in hearing
>*specific details by mail* about cases where this is not true.
>
>Imaging is more of a problem, because of two limitations in the
>PX[G] hardware: pixel-level access to the frame buffer is slower
>than the cfb options; and there are only 1.3-3.9 Mpix of offscreen
>memory available.  Contention for offscreen memory (which can
>be caused by cycling through a large set of pixmaps) is usually
>a worse problem than the slower access to the frame buffer.
>This does not imply that image display on the PX[G] is necessarily
>unacceptable: it does mean that achieving peak performance
>requires more care, and there are definitely some tar pits to avoid.
>
>Tuning graphics software is a tricky business, requiring knowledge
>of many factors, including the primitive mix, and the ratio of graphics
>to non-graphics computation.  Some time back I wrote a white paper
>discussing hardware differences between the PX and "dumb" frame buffers,
>and coding ramifications thereof.  Much of what I said there also applies
>to the PXG.  Even if you are not actively developing grahics software,
>you may find this useful.  You should be able to get a copy from your DEC
>sales rep: the title of the paper is "A Guided Tour of the PX Graphics
>Option" (or some close approximation).
>
>I would suggest that followups be directed to comp.sys.dec, or conducted
>by mail, in order to keep this newsgroup from growing beyond its present
>unmanageable :-) size.
>
>--
>                                        /Paul Jensen
>                                         Digital Equipment Corp.
>                                         Palo Alto, CA


I'd add the following observations:

	There is no difference in rendering or image-display performance
	between the 8-plane PXG and the 24-plane PXG.  There is very
	little difference in 2D graphics performance between the PX
	and PXG.

	8-plane applications run perfectly well on 24-plane PXGs, as
	long as they don't make unfounded assumptions (for example,
	assuming that the default visual type is 8-plane pseudocolor).

	Check out Paul's paper to understand the differences between
	PX and CX performance.  We've certainly never seen a 40-to-1
	performance degradation such as the one you cite.  If you
	still have contacts at the developer, please refer them to
	Paul or me.

Allen Akin