Talk:PHIGS

DirectX

OpenGL is the standard? What about DirectX? The phrase "the standard" certainly needs substantiation.

I don't believe DirectX is a standard. For it to be a standard it has to be open and recognized by a standards organization such as the IEEE or the ISO. DirectX just has a large market share. That doesn't make it a standard. Rilak (talk) 07:43, 12 September 2008 (UTC)

Regardless of whether you think it's a standard or not, I would argue that DirectX is too important as a 3D API to just ignore. It has widespread support among both software and hardware vendors, and has all but eclipsed OpenGL in games, and companies such as Autodesk are also starting to prefer Direct3D for professional 3D software such as 3DSMax and Autocad. Besides, the article says 'de facto standard', and that definition certainly applies to Direct3D. 213.10.103.38 (talk) 20:27, 17 February 2010 (UTC)

You have a point there, but PHIGS vs OpenGL (indeed, anything vs OpenGL) happened way back in prehistory as far as DirectX is concerned. This article is really about old stuff - DirectX has no relevance to PHIGS at all. I've revised the intro statement to make it clear this is a historical article - David Gerard (talk) 23:49, 28 February 2010 (UTC)

Fair enough David. I added 'professional', to make the distinction with the gamer/consumer market. PHIGS and OpenGL battled on the professional market only. In the 1990s, Glide was arguably the most popular 3D API in the consumer market. Direct3D doesn't belong here, as PHIGS was already 'gone' by the time D3D became an alternative to OpenGL in certain professional applications. However, the original phrasing didn't leave any room for D3D being an alternative to OpenGL. 212.189.46.155 (talk) 13:14, 25 March 2010 (UTC)

Umm, hey ... the PHIGS vs. OpenGL (IrisGL) wars happened in the early 1990's. DirectX did not even exist at the time; the war was over before DirectX was born. 67.198.37.16 (talk) 16:50, 26 August 2015 (UTC)

PHIGS still "widely used"

Please cite projects in the games and/or film industry known to use PHIGS; before stating it as "still widely used." Particularly given that the previous text listed it as "no longer used." PHIGS does not support a number of features considered standard in games (ie. shadows, texture mapping, etc.) PHIGS is a very old standard, with no low-level access to hardware. It has not been suitable for games or film for quite some time. — Preceding unsigned comment added by 98.247.38.56 (talk) 19:27, 19 February 2012 (UTC)

Gaming and hollywood dudes always seem to forget that they are Johnny-come-lately customers of computer graphics technology. For a long time, the dominant market for computer graphics was engineering design work. That market is still important today, but doesn't get all the hype and attention that are lavished on the latest first person shooter game or Hollywood special effects extravaganza. PHIGS+, and other ISO standards like CGM, are often times mandated in government contract work. Think about the amount of graphical data that goes into designing all the pieces of a modern aircraft carrier. When broken down into the smallest parts, like nuts and bolts, the part count probably reaches the billions. Somewhere all of that design work is captured in an engineering system. Most of the engineering systems in use for these sorts of jobs have very long lineages. Eventually I suspect that most of them will migrate to OpenGL, but they will probably still need to support CGM and other ISO standards for funtionality that aren't covered by OpenGL, which only addresses rendering. Only the vendors themselves can comment on how much of their code base is using PHIGS and how much is using OpenGL and I suspect that they are not likely to be very forthcoming with that information.

As for PHIGS not supporting shadows or texture mapping, there are two misconceptinos here. First, neither OpenGL or Direct3D have an explicit API for shadows. All shadow algorithms implemnted in games are implemented entirely within the application using the features of the API. Secondly, while PHIGS did not support texture-mapping in the standard, there were always standard ways of extending the standard through the use of the ESCAPE or GDP (generalized drawing primitive) mechanism, as well as a means of registering the semantics of those extension elements with the standards body so that they could be adopted by more than one vendor. More than one vendor used these mechanisms to provide texturing and other functionality in the early 90s. OpenGL has a similar mechanism with it's extensions as well. Direct3D takes the approach that when new core functionality is needed in the API, a new interface will be published.

Finally, it should be noted that no graphics API provides low-level access to the hardware; they all provide an abstraction of the hardware. When I program in OpenGL or Direct3D, there is always an abstract command stream that is generated by the API, the device driver, or both, that results in making the hardware do something. I am never exposed to the low-level details of the hardware when I program in these graphics APIs. Exactly how many registers the hardware has, what address it has on the PCI bus, and so-on, are all kept hidden from me. Some small tiny bits of information about the hardware environment are exposed to me so that I know what kinds of shader language models it supports, or the size of the depth buffer for instance. Other than that, everything is an abstraction. This is a good thing because it keeps my program running on a wide variety of hardware and not just the one I happen to have in my machine when I develop the application.

It is a common misconception that only immediate-mode can provide high performance graphics because it is "low level". I suspect that this meme largely comes from SGI's marketing department and other workstation manufacturers to emphasize the ability of a workstation to immediately get results when compared to a graphics terminal at the other end of a slow communications line. Compared to terminals, graphics workstations were expensive and they needed a marketing pitch to justify the additional expense. PHIGS's concept of a structure store, and GKS's concept of a segment before that, largely come from a codification of the existing practice in graphics terminals at the time. In order to get interactive rates with any piece of 3D graphics hardware, you have to get the data close to the hardware. For a workstation with integrated 3D hardware, the compute hardwrae and the rendering hardware are all in the same box and this is relatively easy. For a graphics terminal, the compute hardware is separated from the graphics hardware by a (potentially slow) communications line, so getting the data close to the rendering hardware means storing it in the rendering hardware and manipulating it remotely from the application. The irony is that SGI's own hardware required the same kind of mechanism in order to get the highest performance, although that's not what they'll tell you in the marketing hype as they bash "structure store" and hype "immediate mode". Many vendors make high performance graphics devices, both in the past and in the present, that rely on the data being loaded into the device in order to achieve maximum performance. This is just as true today with a modern GPU as it was true in the 1970s and 1980s when GKS and PHIGS were being standardized. Legalize (talk) 22:44, 25 March 2012 (UTC)

??? In what way is PHIGS still "widely used"? All of the IBM 5080's that ran it got ripped out in the early 1990's. Yes, both HP and Sun provided PHIGS products in the early 1990's, on their unix workstations. But neither Sun (now Oracle) nor HP sell unix workstations any more (where "workstation"==desktop/deskside single-user). So the only way to run PHIGS is to run it on 20-year-old hardware ... who, exactly, is doing that? Or are you claiming that someone has ported PHIGS to run on modern hardware? I find that very hard to believe. 67.198.37.16 (talk) 16:57, 26 August 2015 (UTC)

This begs the question: why are there no WP articles on the IBM 5080 and the IBM 6090 ? 67.198.37.16 (talk) 17:05, 26 August 2015 (UTC)

The obvious answer: because nobody's written them yet? :-) - David Gerard (talk) 11:49, 28 August 2015 (UTC)

OpenGL vs. PHIGS

The section here talks about OpenGL as only having immediate mode. This is a widely held misconception about IRIS GL and its successor OpenGL. IRIS GL and OpenGL have always had display lists that are very similar to the structure store in PHIGS. You can add geometry and rendering state to display lists. The main difference between display lists in OpenGL and structure storage in PHIGS is that the former is write-only and the latter can be queried and modified.

The whole point of structure storage in PHIGS, and segments in GKS before that, was to get geometry data as far down into the device for rapid interactive drawing. IRIS GL and OpenGL don't just provide display lists as a nicety, they are essential to getting the maximum performance out of a particular piece of graphics hardware. SGI's own benchmark application posted to usenet by Kurt Akeley made this abundantly clear when it become known that the quoted 1 M poly/sec benchmark figure for the VGX touted by SGI at the time was only achievable through display lists and not immediate-mode.[1] Extensions to OpenGL have broadened the set of items that can be downloaded into the graphics card and a modern application would probably prefer vertex buffer objects for storing vertex and index data instead of a display list, but the concept is the same.

The structure store concept of PHIGS is also present to some degree in the buffer objects in Direct3D. In order to maximize performance when using buffer objects in Direct3D, the application supplies semantic hints that indicate the usage patterns for reads and writes to those buffers.

The PHIGS standard only specifies so-called "retained mode" style operation where information must first be put into the structure store and then traversal of the structure store initiated to perform rendering. During the late 80s and early 90s, OpenGL was not yet available and PHIGS started to gain traction among workstation vendors due to the PEX (PHIGS Extensions for X) implementation that was part of the X Window System distribution from MIT. Unfortunately the sample implementation of PEX was limited and did not provide a performant solution "out of the box". Evans & Sutherland with it's ESV Workstation series, and several other vendors such as Hewlett-Packard and DEC, provided a performant hardware implementation of PEX.

The initial implementation of PEX focused on providing a PHIGS+ compatible API for the underlying protocol. However, the underlying protocol itself supported immediate-mode style rendering. A subsequent PEXlib binding to the protocol exposed this immediate-mode style rendering, along with structure storage, to application programs. However, PEXlib had neither the backing of the international standards community like PHIGS, nor the market dominance of SGI, and while support was available through a standard client library supplied with the X Window System distribution, application adoptance was slow. Legalize (talk) 22:44, 25 March 2012 (UTC)

Are you Greg Laib? 67.198.37.16 (talk) 17:13, 26 August 2015 (UTC)

Good discussion. I plan to round up some old press releases and make the case that pressure from the PEX Consortium forced SGI to turn GL into OpenGL. Bodysurfinyon (talk) 20:11, 8 August 2021 (UTC)

Separation of mechanism and policy

Back in the 1990's, it was commonly seen that PHIGS was on the wrong side of the separation of mechanism and policy debate. That is, OpenGL exposed mechanism (i.e. the hardware), whereas PHIGS was a collection of policies about how you were allowed to use that hardware. The software programmers were constantly bumping into the PHIGS policies, preventing them from doing what they wanted. The hardware designers felt that PHIGS was preventing them from building high-performance hardware, by imposing crazy, non-sensical policies about what was allowed and what wasn't. So this really was a two-pronged revolution, both hardware and software aligned against it, and it as all about the separation of mechanism and policy debate. One can't understand the history of PHIGS without understanding this. 67.198.37.16 (talk) 16:47, 26 August 2015 (UTC)