rajeev@mit-caf.MIT.EDU (Rajeev Jayavant) (10/14/90)
Does anyone out there know how the X performance of a DEC 5000/200CX compares with a 5000/200PX? I know that the PX graphics subsystem utilizes the PixelStamp chipset to perform scan conversion, but does the X server take advantage of this hardware? Is there any hardware in the PX that is designed specifically with X performance in mind, or does the PX address other graphics API's, e.g. PHIGS? On a related note, how does the X performance of the 3D systems (the PXG and PXG-turbo) compare to the 2D systems? Did DEC make sacrifices in X performance in order to speed up the 3D cases? It appears that IBM made exactly that kind of tradeoff in their offerings for the RS6000 line..... Thanks for any info! --Rajeev /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ARPA: rajeev@caf.mit.edu UUCP: ....!mit-eddie!caf!rajeev "Do they think we can be frightened by men with plastic noses?" - Genghis Rex
allen@basalt.uucp (Allen Akin) (10/16/90)
In article <5239@mit-caf.MIT.EDU> rajeev@caf.mit.edu writes: >Does anyone out there know how the X performance of a DEC 5000/200CX >compares with a 5000/200PX? In general, the PX is *much* faster (2-3X) for vectors, polygons, XCopyArea, and filled primitives where the fill-style meets certain requirements (solid, or stipple or bitonal tile with sizes equal to a power-of-two less than or equal to 16). The CX is faster for image display (XPutImage) and for very small primitives whose drawing time is dominated by server overhead. Otherwise they're about the same. A summary comparison of the two options is available by anonymous ftp from decwrl.dec.com. Check out the file pub/DEC/ds5000.graphics.ps.Z. If you don't have ftp access, let me know and I'll mail you the PostScript (about 88KB). >... does the X server take advantage of this hardware? Yes. > ... Is there any hardware >in the PX that is designed specifically with X performance in mind, or >does the PX address other graphics API's, e.g. PHIGS? Although the PX was certainly designed with X in mind, it was also influenced significantly by PHIGS and PEX. The version of PHIGS that's currently available on the PX uses X11 requests for drawing, so it takes advantage of the graphics accelerator in that way. No comment on future versions that may use the PixelStamp for more sophisticated drawing operations not supported by X. :-) >On a related note, how does the X performance of the 3D systems (the >PXG and PXG-turbo) compare to the 2D systems? Did DEC make sacrifices >in X performance in order to speed up the 3D cases? The PXG is almost identical in performance to the PX for 2D operations. They both use the same speed PixelStamp chipset and video RAMS. The PXG Turbo varies from essentially the same speed as the PX to more than 2X faster, depending on the 2D operation you choose. The Turbo uses faster PixelStamps and two rendering chips instead of one, so large-area operations more then double in speed. Allen Akin Advanced Technology Development Group Digital Equipment Corporation
rajeev@mit-caf.MIT.EDU (Rajeev Jayavant) (10/24/90)
In article <1990Oct16.033743.4246@wrl.dec.com> allen@atd.dec.com (Allen Akin) writes: >In article <5239@mit-caf.MIT.EDU> rajeev@caf.mit.edu writes: >>Does anyone out there know how the X performance of a DEC 5000/200CX >>compares with a 5000/200PX? > >In general, the PX is *much* faster (2-3X) for vectors, polygons, >XCopyArea, and filled primitives where the fill-style meets certain >requirements [text deleted] > >A summary comparison of the two options is available by anonymous ftp >from decwrl.dec.com. Check out the file pub/DEC/ds5000.graphics.ps.Z. Thanks for the pointer to the document - there's a lot of good information in there. Does the PixelStamp chipset support the X line drawing primitives or is the 2-3x performance boost only for width=0 lines? Also, does X have similar guidelines for rendering filled polygons, and if so, does PixelStamp support those primitives also? It sure does seem to give a nice performance boost for polygon rendering.... Rajeev /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ARPA: rajeev@caf.mit.edu UUCP: ....!mit-eddie!caf!rajeev "Do they think we can be frightened by men with plastic noses?" - Genghis Rex -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ARPA: rajeev@caf.mit.edu UUCP: ....!mit-eddie!caf!rajeev "Do they think we can be frightened by men with plastic noses?" - Genghis Rex
allen@basalt.uucp (Allen Akin) (10/26/90)
In article <5282@mit-caf.MIT.EDU> rajeev@caf.mit.edu writes: > ... Does the PixelStamp chipset support the X line >drawing primitives or is the 2-3x performance boost only for width=0 >lines? The chipset accelerates the so-called ``zero-width'' X lines (which happen to be one pixel wide on all X servers that I've seen). I don't think there's any significant performance boost for wide lines, though I could be wrong for very wide lines. I'm a little confused by your question -- zero-width lines *are* X line drawing primitives, as are wide lines. > ... Also, does X have similar guidelines for rendering filled >polygons, and if so, does PixelStamp support those primitives also? The PixelStamp polygon-drawing semantics match those for X convex polygons, so it accelerates those nicely. Nonconvex polygons are tesselated by the server to form convex subpolygons in some cases, or scan-converted directly in others. There's always a performance advantage in using convex or non-self-intersecting polygons. For all primitives, performance is best for solid fill-style, stippled fill-style where the stipple has power-of-two dimensions less than or equal to 16, opaque-stippled fill-style with the same size constraints, and tiled fill-style with bitonal tiles meeting the same size constraints. Allen