Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ames!ucbcad!zen! ucbvax!ZERMATT.LCS.MIT.EDU!RWS From: R...@ZERMATT.LCS.MIT.EDU (Robert Scheifler) Newsgroups: comp.windows.x Subject: Minutes of X11 3D Workshop, 18-19 Jun 1987 Message-ID: <870630090409.5.RWS@KILLINGTON.LCS.MIT.EDU> Date: Tue, 30-Jun-87 09:04:00 EDT Article-I.D.: KILLINGT.870630090409.5.RWS Posted: Tue Jun 30 09:04:00 1987 Date-Received: Thu, 2-Jul-87 00:55:46 EDT Sender: c...@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 860 X11 3D Workshop minutes, 18-19 June 1987, MIT. Tom Morrissey (HP) and Jim Michener (Apollo) Attendees: Marcel Meth, AT&T Bell Labs Mark Hood, Applicon/Schlumeberger Tony Barkans, Applicon/Schlumeberger Dave Gorgen, Apollo Computer Inc. Jim Michener, Apollo Computer Inc. Jud Harward, Center for Remote Sensing, Boston University Hann-Bin Chuang, Astronomy Dept, Boston University Bernard Servolle, Bull-MTS David Bailey, CalComp Patricia Barstow, CalComp Jan Silverman, CalComp Jan Hardenbergh, Cognition, Inc. Steve Blank, Dana Computer Bruce Borden, Dana Computer Mark Patrick, Dana Computer Dana Marnell, Data General Corp Ying-Sheng Wen, Data General Corp Brian A. Axtell, Digital Equipment Corp Laurence Cable, Digital Equipment Corp Dave Carver, Digital Equipment Corp George Champine, MIT / Project Athena William Clifford, Digital Equipment Corp. Dick Coulter, Digital Equipment Corp Jeff Friedberg, Digital Equipment Corp. Branko J. Gerovac, Digital Equipment Corp. Elana Granston, Digital Equipment Corp. Harry Hersh, Digital Equipment Corp. Robert Holt, Digital Equipment Corp. Kathleen Langone, Digital Equipment Corp. Leszek Kotsch, Digital Equipment (Europe) S.A.R.L. John McConnell, Digital Equipment Corp Rico Piantoni, Digital Equipment Centre Technique Europe Randy Nickel, Digital Equipment Corp. Pete Nishimoto, DEC - VMS Workstations Randi J. Rost, Digital Equipment Corp. Jeffrey S. Saltz, Digital Equipment Corp Reinhild Schwarz, Digital Equipment Corp Shreyas B. Shah, EDS/GM Roy Wirthlin, EDS/GM Stefan Noll, FhG AGD Gregg Orangio, General Electric, Silicon Systems Tech Dept Tom Morrissey, Hewlett-Packard John Howard Palevich, Hewlett Packard Laboratories Jeff Stevenson, Hewlett Packard Greg Laib, IBM Mitch Kuninsky, Masscomp David Wolfendale, Masscomp Mike Bailey, Megatek Corporation Paul Dworkin, MIT / Media Lab Bob Scheifler, MIT / LCS Y. Obi and Y. Hongo (Japan), NEC Systems Lab Robert L. Gordon, Prime Computer,Inc. Salim Abi-Ezzi, RPI / CICG Dan Reece, SDRC Mark Callow, Silicon Graphics Nai-Ting Hsu, Silicon Graphics Inc. Allen Leinwand, Silicon Graphics Inc. Andy van Dam, Stellar Computer & Brown University David Laidlaw, Stellar Computer Jerry Evans, Sun Microsystems Lewis Knapp, Sun Microsystems Eileen McGinnis, Sun Microsystems David Rosenthal, Sun Microsystems Dennis Doughty, Symbolics, Inc. Bill York, Symbolics, Inc. John Dalrymple, Tektronix (Information Display Group) Dave Verhoeven, Tektronix Georges Grinstein, University of Lowell, Graphics Research Lab Zhong-Yu Zhou, University of Lowell, Graphics Research Lab Deyang Song, University of Lowell, Graphics Research Lab Greg Cockcroft, Univ. of Michigan, Center for Info. Tech. Integration Bertram Herzog, Univ. of Michigan, Center for Info. Tech. Integration Michael Foody, Visual Edge Software Ltd Larry Atwood, Visual Information Technologies 9.30 Called to order by Branko Gerovac. Branko did some straw polls to characterize the group. Lots of vendors, x-windows users and implementers, 3D graphics systems implementers, graphics and windowing standard folk. Not many application developers/users. Some X history. Emphasize omission of "policy" in X. Discussion of possible meeting logistics. Version 2.07 X3D was distributed prior to the meeting. This proposal has been revised from comments from, and work with, Sun. This new version is version 2.08, which will be presented at this meeting along with the deltas between version 2.07 and 2.08. What is the goal/focus of the meeting? Just to discuss the DEC/Sun (version 2.08 X3D) proposal? The only proposal received as input to the workshop is the 2.07/2.08 X3D doc. There was some discussion of whether we should talk about goals before we talk about a particular proposal. One goal of the meeting is to solicit participation. Context / overview of effort (Randy Nickel & Eileen McGinnis) What were they (DEC) trying to accomplish? 1. to extend X for 3D graphics, 2. to support graphics standards (especially PHIGS & PHIGS+ (the stable parts of PHIGS+)), 3. to expose features and functionality that are provided in the newer technologies, and 4. to do this in a timely manner, (requirements / need is there now for high performance 3D graphics within the X windowing environment). (before 1990) Questions from group: What is explicitly not be addressed by this? Imaging, CSG, 3D text are NOT explicitly addressed. Explicit support for PHIGS/PHIGS+ IS provided. Is a sample server to be provided? Simple answer - yes. What is being proposed (protocol, library)? Just a protocol. The library and C-binding in 2.07 were just examples. Technical overview "high order bits" (Randi Rost) Why is X3D necessary? - The X window system needs 3D graphics capabilities - PHIGS and PHIGS+ need an X window system binding - Current hardware products have more functionality than is exposed in graphics standards (not so true since PHIGS+ development has progressed) X3D Product Goals - Provide 3D graphics functionality as compatible X extension - Support efficient layered implementations of graphics standards products - Support workstation products from low end to high end - expose features of high end systems - allow efficient implementations on low end systems - Provide timely implementations on a variety of platforms X3D support for standards - PHIGS most important - Incorporate stable PHIGS+ functionality - Synchronize with October 87 PHIGS draft (DIS text) - Support other standards like GKS-3D Standardization goals and non-goals - create a standard 3D extension by working within the X community - no current plans to attempt ANSI/ISO standardization - must standardize X3D protocol to ensure network compatibility - may standardize X3D client library (X3lib) - X3lib provides thinnest layer on protocol - may not want to expose X3lib to standards users - vendors have existing libraries to support - don't need to standardize utilities - examples are included in proposal document - vendors may have own preferred conventions Primary features of X3D - X-compatible, extends X capabilities of 3D - full 3D graphics in window environment - network based - industry standard - hope for multi-vendor support - efficient PHIGS, GKS support - PHIGS, GKS developed before widespread use of window systems - based on modern graphics model - includes support for reflection, lighting, antialiasing - flexible, efficient on a variety of systems - supports new hardware/software technology - Feasible, practical (actually a goal not a feature); can be implemented in a timely manner - X, X3lib prototype X3D (DEC) design team: (note: across many DEC groups) Randi Rost, DEC Workstation Systems Engineering Jeffrey Saltz, DEC Base Graphics Systems William Clifford, DEC Base Graphics Systems Peter Nishimoto, DEC VMS Jeffrey Friedberg, DEC High Performance Workstations Branko Gerovac, DEC High Performance Workstations Dick Coulter, DEC High Performance Workstations Brian Axtell, DEC Base Graphics Systems John McConnell, DEC Corporate Standards Technical details (Jeff Friedberg) X3D technical goals - promote illusion that each window is an independent 3D workstation - support structure mode and immediate mode with one interface - strive to keep interface "policy free" (no favors) - provide extensible, long-lived 3D interface - K.I.S.S. Keep It Simple Stupid (simplicity) ? Since there is this list of deferred things, is there a second order extension mechanism (for things like GDPs, GSEs, escapes)? Not yet, may be needed. X Client/Server model client client \ \ / \ \ / v v v X server Connections are atomic-command oriented. X and X3D dispatchers (figure) X3D Request -> Connection -> Core X ----------------> X3D Queue Dispatcher Requests Dispatcher / | \ / | \ v v v v v v C o r e X X 3 D Resources in X3D - GContexts (extended) - Windows (extended) - Pixmaps (extended) - Fonts (extended) - Font families (new) - Structures (new) - Format contexts (new) e.g. floating point Possibly not appropriate in graphics extensions, should possibly be in connection contexts in X Extended GContext - output primitives - transformation attributes - rendering attributes - raster attributes 3D drawable hierarchy 3D drawable / \ X drawable \ / \ \ window pixmap structure Output command processing (figure) output output commands commands | | v v Renderer Element | Pointer | | v v Raster Structure Data Elements ............. ......... Window/Pixmap Structure A renderer Purpose: distinguish (support) immediate mode and struct traversal Output commands Traverser commands (Post Root, Set Regen Mode) | | v yes v ? call structure? ------> structure traverser <----> structures | | no v rendering pipeline | v raster data A somewhat ambiguous and loaded model, hence some discussion ... ? Send same command to a struct AND to an X drawable? No ? What is the structure traverser really doing? ? What is in the server and what is in the client? Traverser and structures are in the server. ? What about synchronization of the traverser? Due to the contentious nature of the topic, this was referred to sub-group for discussion. ? Atomicity of commands? Intend to permit parallel traversals. There are two kinds of atomicity: Traversal atomic (cannot twiddle with environment during traversal) X command atomic (indivisible queue per connection) X3D rendering pipeline (figure) Base geometry & input colours | local modelling coordinate system & input colours v Colour type conversion | local modelling coordinate system & base colours v Composite modelling transformation | world coordinate system & base colours v View orientation transformation | view reference coordinate system & base colours v Light source shading computation | view reference coordinate system & shaded colours v Depth-cueing computation | view reference coordinate system & depth-cued colours v View mapping transformation | normalized projection coordinate system & depth-cued colours v Clipping | clipped normalized projection coordinate system & clipped colours v X window coordinate mapping | X window coordinate system & clipped colours v Device coordinate mapping | physical device coordinate system & clipped colours v Device colour mapping | physical device coordinate system & physical device colours v physical device coordinates & physical device colours ? write back atomicity? Renderer State - pipeline state - current attributes - GC aliases - light tables - colour table - filters containing name sets - hit test results - traverser state - root of posted structure network - implicit traversal mode A structure resource element pointer -------> structure elements editing mode Structure networks S1 S4 /\ /\ / \ / \ v v v v S2 S3 S5 S6 \ / \ / v S7 Call structure execution Structure A _-> Structure B set text colour / polyline set HLHSR mode / set curve colour call structure B / text set curve colour <---\__ set curve style set marker glyph \-polyline 11.05 break 11.15 re-convene Overview of topics for further technical discussion (elaborated throughout meeting) - traversal semantics - client/server execution semantics - write back data to client - structure extensions (data per object) - double buffer proposal - input model - PHIGS[+] layering on top of X3D - peer interfaces - binary binding for protocol - conceptual CSS's "location" in X3D - how to GSE, GDP & escape - defaults Documents - X11 protocol - X11 xlib - X11 xtoolkit - dpANS PHIGS - PHIGS+ - X3D 2.08 - X11 Input Extension proposal Possible proposals that may need to be considered - X3D 2.08 - Something from Tektronix - Something from SGI - PHIGS+ - Postscript 3D SGI view of things (Nai-Ting Hsu) A high-quality PHIGS implementation may not be the best path. SGI's experience with hundreds of significant real-time 3D applications. "Adequate" performance is not enough Experience shows a "RISG" approach wins Minimalism is the route to real-time 3D PHIGS on X3D delivers a "terminal" graphics model to applications The terminal model does not support dedicated 3D interaction well. The 3D graphics interface is a poor place to split an application. "RPC" (Remote Procedure Call) delivers a more general interface A simple graphics interface is called for Embodies a RISG approach, to support effective dynamic applications Relies upon powerful atomic primitives Delivers a flexible lighting model Provides interaction handling on the workstation SGI is working on a proposal and would like to distribute it around the Siggraph timeframe. It is not being proposed to this group, since it is not strictly limited to X/windowing. This is merely mentioned for the information of the group. Contact SGI representatives (see attendees list) for more details and getting a copy of the proposal. ? More detail? Difference of emphasis. X3D 2.08 suggests how to partition things. ? Expect data structures to be on which side of 'wire'? Application dependent ? Expect to take GL and RPC-ify it? Not necessarily ? Is there an extension language? ? Public Domain or licensed? Not decided yet. ? Postscript 3D was listed before as possible proposal. Is anyone going to submit it for consideration? (No response) A goals discussion: Library interface inappropriate, since it conflicts with PHIGS[+], GKS/GKS-3D, CGI. No API (for now). Library interface (API) to the full power of the protocol is suggested to be necessary (e.g. for eventual testing). ? Goal to Add 3D to X or Do 3D in X window environment? (The latter implying having a local 3D application.) Several definitely in favor of the former. Protocol document not low enough; too much functional definition (heavily PHIGS[+] vs. CGI) Should this be a more general basis for a broader set of standards? Should the protocol support just PHIGS[+] and GKS/GKS-3D or should it support proprietary graphics interfaces and other graphics standards (CGI). Protocol extension versus window information access. Peer interface as implementation. Geometry & rendering (shape/sort) best done on server If goals is to support PHIGS[+], why not make the protocol map directly (1-1) to PHIGS[+] API? The protocol is a different level in the system, and it is necessary to express the protocol in a form fitting into that level of the system and into X protocol. (But: It is hard to define something below the level of PHIGS that supports PHIGS.) Minimize network traffic. Metagoal: Have a simple set of goals. Suggestion: rename X3D 2.08 -> PHIGS[+] extension for X architectural issues (RPC ... underlying across) (this then is not an X extension) David Rosenthal's attempt at shooting down API advocates. - API already addressed by ISO/ANS - Server extension mechanism not defined yet, and won't perform well enough to meet graphics goals. The server extension mechanism is not mature enough to use. - Therefore, only address protocol. Need for generic low-level (elemental) protocol, e.g., "just" shaded triangles and vectors. 12.45 broke for lunch 14.00 reconvene How to proceed? Break into the following groups 1. protocol specific to PHIGS (Gerovac) 2. protocol for atomic generic low level (non-PHIGS, not anti-PHIGS) (Verhoven) 3. peer interface for graphics (Palevich) to determine their respective goals. Broke into groups to at 14.15, to re-convene at 15.30 Reconvene at 15.50 Non-PHIGS protocol group. PHIGS is not the answer for everyone. Bruce Borden will prepare a proposal to interface at the Z-buffer level (a very low level) by August 1. Non-PHIGS goals - allow multiple extensions that don't interfere or preclude each other - have a low level 3D model - allow a decision to be made at runtime on how to partition the pipeline between the client and the server - allow for passing data by reference - provide access to various points in the pipeline Question How much 3D functionality can be added to X without violating the "no policy" goal? Not much above "true colour pixels". Peer interface group. Goal - Allow peers to bypass X11 for the highest possible performance (w.r.t. output in windows). This might be achieved by providing hooks for highest possible performance for environment where there is a "fast path" between the application and the hardware (but at the expense of portability). The X11 server still arbitrates window clip lists and screen resources and distributed input, etc. One possible model 3D clients High performance clients Pure X clients \ \ | \ | \ / / / \ \ | \ | \ | | | V V | ----|-----------------> V V V 3D server ---------|-------|-----------------> X11 server \ | | / \ V V / -------> Hardware <------------------ A possible model of a client (figure) --------------- | Application | --------------- |3D| | | ---- | xlib | |dd| | | ---- -------- | | | fast path >| \ | < X11 protocol | \ | | V? V | -------------- | | X11 server | | -------------- | | dd x calls V V --------------------- | dd | --------------------- | V hardware Concern: clip list synchronization local connection to (dd to X11 server) to get that What should be standardized? Protocol": "express interest in fast-path" "this window's clip list should be synchronized" Sample server: "lock clip lists" machinery Fundamental requirements/issues: synchronizing hardware access (implementer problem) synchronizing cliplists between X11 server and clients PHIGS protocol extension group. Goals: - PHIGS protocol extension & encoding compatible with existing X - Incorporate stable PHIGS+ functionality - Synchronize with PHIGS DIS (Oct 87 draft) - Support a performance range of X server platforms - Timely definition of protocol extension - GKS-3D will be considered later either as addition to this extension OR as a separate extension Where do we go from here? What did we learn from this? Query of folks' inclinations after seeing the goals of the efforts: (Multiple inclinations permitted) Most people are disposed toward working on PHIGS protocol. About 1/6 of the folks are interested in the non-PHIGS protocol. About 1/10 of the folks are interested in making a hybrid protocol happen. Generic (non-PHIGS) protocol (Bruce Borden, Dana Computer) Application ^ \ v database \ Visualization | + PHIGS+ protocol level Database (display list) | Traversal | Transform | Clip | * low-level generic protocol level Z-buffer <-> Draw | Frame buffer | Display Problem: Where is lighting and shading? (All over, ugh.) Assertion: Bandwidth down to beyond the clip stage has the same bandwidth (37.5 megabytes/sec), then the bandwidth explodes, and hence is it useful at that level to define the protocol. (And possibly at higher levels, too.) Low level interface (at the level of "Z-buffer <-> draw" above) Drawing (all 3D) coloured vector coloured triangle random pixel write Patterns 2D for all drawing primitives 1D stipple for vectors enable/disable z-buffer clear enable/disable colour mode map management (goal: Arbitrary previewing over the net, since REAL application dynamics would be impossible over net anyway -- see assertion above.) 17.20 adjournment for the day. Friday, 19 June 1987. 9.40 re-convene Process and logistics for further work. Umbrella X11-3D organization Report on X11 proposed future organization June 8 meeting of 10 entities MIT is going to prepare a proposal, available mid-July timeframe to create an industry consortium under the auspices of MIT as the organizer. The goal being the continuation of work on X. Some fee for joining up. Some commitment (say 3 years). Members would sit on an advisory board. MIT would be the decision making body. The consortium would have a chief architect (an MIT person) who would make the decisions. There would also be MIT staff to take care of the logistics of X maintenance/development. ? Would there need to be a sub-chief architect (also from MIT) for each major extension? Don't know - all of this is still being formulated. ? Would the fee be graduated by company size? Ditto. ? Would universities and/or government agencies be treated any different with respect to schedule? Ditto. ? What is the deadline for having this in place? Ditto. We, X3D extensions, would like to be sanctioned by this yet- to-be-formed group. The disposition of the X community seems to be that if this group is reaching consensus, then continue. Timeliness, schedule What was/is the X11 schedule? before - lots of independent, background work, X6 to X10 Apr 86 - first meeting Jul 86 - 1st public review draft Sep 86 - 1st public review closed Dec 86 - major Berkeley Un*x release with X10 toolkits (HP & DEC) Jan 87 - X users conference Feb 87 - alpha server release May 87 - alpha update Jun 87 - beta server release Sep 87 - close beta, release DEC intends to provide a sample server for X3D X11-3D proposed schedule 19 Jun 87 - workshop, public review, output X-PHIGS 2.08 22 Jul 87 - X-PHIGS 2.08 comments in 26 Jul 87 - PHIGS+ public review begins 03 Aug 87 - X3D meeting (west) 17 Aug 87 - X-PHIGS 3.0 public review 21 Sep 87 - X-PHIGS 3.0 public review ends - comments in 21 Sep 87 - PHIGS+ comment period ends 28 Sep 87 - X-PHIGS 3.05 document available 01 Oct 87 - X3D meeting (east) 05 Oct 87 - ASC X3H3 meetings (Lowell,MA) 12 Oct 87 - X-PHIGS 3.1 available protocol spec / function freeze 19 Oct 87 - ISO PHIGS editting meeting (Fort Collins, CO - tentative) 26 Oct 87 - PHIGS+ meeting (Troy,NY) 09 Nov 87 - synchronize with PHIGS draft (DIS?/ANS? text) 16 Nov 87 - X-PHIGS 4.0 draft available Sample server strategy When available? What available? Skeleton useful enough to be fleshed out? Possibly a assumes only a frame buffer? The first sample server would most likely be a full software server that would talk to a frame buffer. Possibly a subset sample server in April 1988. There will most likely not be a sample server in 1987. Process X11 process (fyi) - an architect / document editor, Bob Scheifler, spent 70% of his time - active individuals - contributors - active reviewers - less involved than contributors - daily exchange of mail with commenters - continual incremental exchange - periodic change summaries - periodic portions - occasional full releases - Bob drives people toward resolution - issues restatement when needed - mail log - geography not as important in the design process, but is important for sample server development ANS arena methodology - commenting period - meeting - discuss comments - draft & vote on issues - sometimes draft document changes - maintain issues log - publish draft document (sometimes after 1/2 cycle in committee) - (sometimes) written responses to commentors Which process is best for us? - X11 process better for the timeframe we are looking at - the architect is a pivotal individual in the X11 scheme - most folks like the electronic and incremental nature of X11 discussion mechanism - issues are a fundamental tool for progressing the effort - encourage comments in the form of issues / proposals - principal architect (or architect team) for each extension (right now, X-PHIGS+) needed - a chairman of the X graphics needed Deliverables (see the schedule) Resources Propose: initial architecture team comes from individuals who drafted 2.08, other members welcome. Architecture team dedicated (50-100%) to the effort. DEC and Sun will contribute to this team. The following organizations had representatives that felt that their organization should be on this team, but could not commit at this time: Tektronix, Data General, Apollo, HP, Prime, IBM, Bull. Organizations should notify the chairman (Herzog, see below) of their level of commitment. Electronic mail distribution: The X11 3D graphics electronic mailing distribution list is accessed through: x11...@athena.mit.edu It is your responsibility to convert the domain name to mail paths familiar to you. To get on the list, send mail to: x11-3d-requ...@athena.mit.edu The x11-3d list will be zeroed out, so if you want to be on it, send in a request. x11-3d-works...@3d.dec.com will be set up this weekend as an interim measure. Organizational local mailing lists are encouraged. Each organization should set up organizational distribution lists, and only place one mail entry in the x11...@athena.mit.edu distribution list. Copyright. It is just there as a placeholder until it can be turned over to MIT. DEC believes it is okay for organizations to duplicate the document. If any organization has any problem copyrighting the document with the copyright on it, contact DEC for more copies or explicit release for the copyright. Chair nominations Roles & responsibilities of chair: - manage the decision making process - not chief architect - resource requirement? - public liaison (trade press, ANSI, professional societies) - MIT liaison - notification of activities (inside and outside group) - manage membership - Oversees all groups within X-graphics group, not just one group (e.g. PHIGS) - accessible (email) - convene and chair X-graphics meetings Nominations: Bert Herzog, accepted and unanimously approved. email address: b...@citi.umich.edu Double-buffering proposal is 'formally' with the X11 base group but comment and discussion in X3D arena is desired. Name of the top-level committee dealing with graphics for X. Ended up agreeing on X3D, but there was a strong sentiment for something more general, X-graphics. Much thanks to DEC and MIT/Athena for sponsoring the workshop. Meeting adjourned at 15.30.