From: dwex@mtgzfs3.att.com (David E. Wexelblat) Subject: Re: PEX Performance Date: Tue, 1 Jun 1993 16:10:36 GMT
In article <1uea6k$mci@usenet.pa.dec.com> paik@mlo.dec.com (Samuel S. Paik) writes:
> In article <C7x1uI.836@cbnewsj.cb.att.com> dwex@mtgzfs3.att.com (David E. Wexelblat) writes:
> >No. In my opinion, NO Intel box is a reasonable platform for PEX.
> >PEX is floating-point hungry like nobody's business. I've run PEX on
> >a SparcStation LX (which includes the GX graphics coprocessor - 106k
> >xStones). The performance there is horrible. On an SVGA-based 486,
> >it's unbelievably bad; acceleration won't make much difference, because
> >the issue is the calculation, not the display.
> >
> >I don't believe that any platform with 3D support in hardware can
> ^^^^
> >possibly be considered a reasonable platform for PEX.
>
> I presume you meant "without".
And now I mean "oops" :->
> It seems to me that there are two
> hardware components to 3D (i.e. PEX, GL, Starbase) performance,
> geometry processing, which requires a lot of floating-point
> performance, and rasterization, which is typically limited by
> framebuffer bandwidth and latency.
Hardware geometry, clipping, HLHSR, lighting, etc, are all required
to get reasonable PEX performance.
>
> While 386 & 486 CPUs typically have awful floating point performance,
> the 586 seems to be more than competitive compared to the hot 3D boxes
> of only a few years ago.
>
Well, the Sparc in the SparcStation LX that I tested on has FP performance
as good as or better than the Pentium benchmarks I've seen. And as I
said, PEX performance is bad there as well. The issue is not how much FP
the main CPU can crunch. The point is to offload the PEX handling so that
the rest of the server can do its job. I would expect that PEX on a 150
specFP 92 processor (the Pentium isn't even half that) would still be bad,
without the geometry, clipping, etc, being done in HW, independent of the
main CPU.
> Memory bandwidth (and latency) can be attacked via smart frame buffer
> techniques like Joel McCormack's (send mail with "help" in subject to
> wrl-techreports@decwrl.dec.com). I don't know anything about PC video
> boards, but KPC's Dore got not unbearable 3D performance on stock
> workstations just using X calls to plot pixels.
Unfortunately, the actual display is much less of an issue. "Unfortunately"
because this we can handle. Current PC video hardware (S3 928, for example)
is pretty good at blasting things to the screen and moving them around.
The issue with Dore, and why I recommended something like 'sphigs' is that
it runs ON TOP of X, not INSIDE the X server. When the server is crunching
PEX, it isn't doing anything else. So using PEX destroys ALL of your
performance. Perhaps the multi-threaded X server, if that's in the
R6 public release, will help solve this issue.
>
> >David Wexelblat <dwex@mtgzfs3.att.com> (908) 957-5871 Fax: (908) 957-5627
> >AT&T Bell Laboratories, 200 Laurel Ave - 3F-428, Middletown, NJ 07748
>
> Sam Paik
Now, just lend me a pixel-planes, and we'll see what kind of PEX performance
we can get (:->).