Immediate mode PEX???

Immediate mode PEX???

Post by James Helm » Wed, 08 May 1991 00:37:44



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.

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.

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.

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.

(This is the same mag which just stated that SGI's new SkyWriter
visual simulation platform can do 5000 polys/frame at a 30MHz frame
rate.  Wow!  That's 150 GigaPolys/sec!!!  I want one!)

Jim Helman
Department of Applied Physics                   Durand 012
Stanford University                             FAX: (415) 725-3377

 
 
 

Immediate mode PEX???

Post by Jan Hardenber » Thu, 09 May 1991 00:39:02



Quote:> 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
up.

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
machine?

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

 
 
 

1. what's the difference between immediate mode and retained mode

hi,

can anybody enlighten me on what's the difference between immediate and
retain mode rendering.
which is faster and what's the advantages/disadvantages?

appreciate if there any web link with more info.

thanks so much!!

kien

2. TOP JOBS AVAILABLE

3. QD3D Immediate mode rendering

4. Timage & Cursor

5. display list vs immediate mode performance

6. saving a jpeg as an action

7. GL objects vs immediate mode

8. NEED A LIGHTNING FILTER

9. Immediate mode vs Display lists

10. What is immediate mode

11. Follow up to immediate mode and PHIGS query.

12. immediate mode graphics versus display-list graphics

13. Immediate mode in PHIGS.