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