> Last month in Unix Today, there was an article about "PEX muscling in
> on SGI's Turf." Someone from Evans and Sutherland was even quoted as
> saying "GL's days are numbered." (However, the eye catching graphics
> for the article were done in GL, not PEX).
> OK. PHIGS is the primary API for PEX. People have realized that
> hierarchical display lists are great for some things, but poorly
> suited for others, e.g. many SciVis apps. So now they want to have
> low-overhead, immediate mode graphics. SGI and IBM have GL. Sun has
> XGL. But there are no industry wide standards. Hence, one might
> argue the need for immediate mode PEX.
PEX has immediate mode intrinsically. No need to add it. What is
needed is the API. There are currently three proposed interfaces to PEX
Immediate mode: PEXIM, PEXlib and PEXtk. PEXIM is actually a PHIGS
subset with immediate mode extensions. PEXlib is to the PEX protocol
what Xlib it to the X protocol. PEXtk is trying to capture the best of
the proprietary graphics interfaces.
Of course, PEXIM has the advantage that graphics hackers familiar with
PHIGS can pick it right up, or that can read one of the (great :-) PHIGS
books coming out.
The ANSI PHIGS committee started to add immediate mode to PHIGS. So,
eventually, the API for PEX immediate mode will probably fall back to
PHIGS, but that is just opinion.
Quote:> But does this actually address the problem? The main reason that
> PHIGS is well-suited for networked graphics is that once your large
> mass of geometry is downloaded, you can rapidly change attributes and
> transformations without blasting the whole object down the slow wire.
> But in immediate mode, one typically sends everything down the wire
> each draw cycle. With graphics speeds hitting 1 million polys per
> second, you certainly can't blast enough data down an ethernet to feed
> the graphics hardware.
You have to look at what is happening to the majority of the data. If
the geometry is stable but the attribute change, then you can store the
geometry in the server and use immediate mode to send the attributes.
This is referred to as "mixed mode" or mixing stored structures with
immediate mode. This is a very powerful model of graphics.
Quote:> Hence unless network bandwidth outpaces graphics performance, an
> immediate mode PEX API won't be particularly useful over a network.
> One could replace the PEX layer with local graphics access to get
> performance, thus making the immediate mode PEX API a standard for
> non-PEX graphics, but this is a rather convoluted path to such an end.
It's never safe to assume that the relative speeds of components of the
system will stay the same. You are comparing the high end of rendering
with the low end of networking. Compare the current high end of
networking, like FDDI at 12 MBytes per second and it works out just
fine. 1 M polygons/sec takes 12 MB / second. Of course both of those
numbers are PEAK numbers. When you start to look at what applications
really do, the peak numbers become irrelevant.
Quote:> Maybe GL and XGL's days aren't so numbered. Or am I missing
> something? Perhaps, local shared memory PEX request queues? The
> article didn't even mention bandwidth as a concern.
Yes, of course good implementations of PEX will have shared memory.
But let's talk about the bread and butter cases. The majority of the
market has not hit the 30 K triangles per second mark. Ethernet can
keep up with that quite easily, and shared memory does more than keep
But, there is overhead in a network transparent protocol. To get rid of
it would require the application to write thier data directly into the
shared memory, then there are no copies, still something to work for.
People used to say X would never work due to the overhead, or for that
matter that fancy UI's do not work due to the overhead. Depends on what
you want and where your priorities are.
My guess is that the combination of compute servers and PEX terminals
and workstations will help PEX become the graphics of choice. If you
are not recomputing your 1 million triangles they can be in the display
list. If you are recomputing them, how long does that take? on what
Disclaimer: I've had something to do with PEX and PEXIM and I always
speak on my own behalf, unless specifically stated otherwise.
Stardent Computer, 6 N.E. Tech Center, 521 *ia Rd,Concord, MA 01742