jim@baroque.Stanford.EDU (James Helman) (05/06/91)
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 (jim@KAOS.stanford.edu) Work: (415) 723-9127
jch@Stardent.COM (Jan Hardenbergh) (05/07/91)
From: jim@baroque.Stanford.EDU (James Helman) > 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. > 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. > 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. > 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. -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742