Summary of Discussion Topics

• ICD / SI Status
• Invariance
• Extensions
• BGL
• OPC
• IP
• More Extensions
• Specifying Display List / Immediate Mode Invariance
• More Extensions
• GLX Protocol / Connectathon
• Java Bindings
• Blue Book
• Conformance
• Next Meeting
• Post-Meeting Extension Discussion

Thursday, March 18

ICD / SI Status

Steve Wright: ICD to Microsoft in April, beta program for IHVs to be setup. 1.1 had extended beta - try for a more formal program this time, with regular drops from MS.

Important W2K changes for multimon.

1.1 had installed base - 1.2 features not widely available. Need volunteers to work with MS for proof of concept.

Dave Story: In the past, SGI put out sample / reference implementation. Now shifting towards shipping optimized code. Will produce 2 products - SI and DDK - which are optimized in the baseline.

Non-Windows platform release will depend on feedback to SGI. Release on Windows depends on feedback to / requirements from MS.

Poll: 13 people using 1.1 ICD on Windows. 9 working on 1.2 implementations. Somewhat disjoint groups: 5/9 working on 1.2 for Windows.

SGI has established email lists for support, bug reports, and discussion of the ICD. Jon will send information out to the arb-interest list.

Dale Kirkland: When will 1.2 ICD wrappers be in NT 5?

Steve Wright: Not able to get into beta 3. Change of management on NT team - very conservative. Looking at a service pack, traditionally in second service pack after release. W2K ship + ca. 5 months.

Dale: When does W2K ship?

Steve Wright: Heh.

Jim Bushnell: For Win 9X?

Steve Wright: Service pack in same timeframe as NT.

Michael Gold: How about multimon support?

Steve Wright: Quite a bit different than 1.1 kit. Incorporated feedback from IHVs on different multimon models. No change for Win98 - multimon 3D acceleration not supported for forseeable future. It would require revising GDI code.

Michael: Would MS object to shipping a separate library?

Steve Wright: Yes, if it's in system directory.

Bimal: It won't be supported in SP1?

Steve Wright: No. Heads-up: anyone trying to put DLLs into system directory will run afoul of a new feature that detects backrevved system DLLs and replaces them from install CD or Internet.

Might be an opportunity for this sort of thing in "Win99" release, but test people object to even small risks. GDI mods are not small.

Bruce D'Amora: When are conformance tests rolling out?

Jon: Incrementally - coverage next week followed by individual features.

Bruce: Multitexture?

Jon/Michael: being worked on by Nvidia - hopefully next week as well.

Steve Wright: Multimon is definitely in W2K.

Dave Story: Documentation for multimon?

Steve Wright: In Beta 3.

Jack Middleton: When is the SI available?

Jon: What we have now is the new 1.1 code base + GLX protocol. 1.2 features are being folded in from SGI internal soft tree.

Invariance

Kurt Akeley: I've been reviewing papers for ACM conferences. Lots of papers doing interesting, unexpected things with the OpenGL state machine. The first examples were from stencil, but there's a lot more to it now. This is really pleasing to me and the other OpenGL designers - we expected people to use OpenGL as an "instruction set" from the initial design. A tight specification helps this happen. Orthogonality (as much as possible) helps - e.g. texturing applied to all geometry and primitives. OpenGL is different in not making assumptions about what makes sense to use with what else.

Appendix A covers invariance. Unlike most of spec, it attempts to justify requirements. One justification: multipass operations. Especially hard to manage variance in low-level coding. Invariance spec was added relatively quickly near end of spec process. If written too tightly, nobody will implement it. Goal was to be flexible enough to allow many implementations, tight enough to be useful.

We haven't discussed revising invariance requirements as we revised the spec. Didn't put invariance in the extension template (Jon will do this for the future).

Concern: explosion of programming techniques that require invariance. Example: XOR for erasure requirements same fragments generated.

Summary: should raise out awareness about invariance. Important, whether we look at it or not. Example: texture state not mentioned - but this is really important to multitexturing. Question: Should a subgroup go off and think about this? Can we add some features after the fact (probably in the "strongly suggested" category)?

Experience has been that if you do the work first and write the spec afterwards, you'll regret it. Likely if we look at it, we'll come up with things we wished were different. Wanted to raise the issue and get people thinking about it.

Jon: Will this affect conformance?

Kurt: Maybe. Tone of meeting has shifted over the years - now we often want more conformance, not less.

Dale: Here's an example with textured and non-textured rasterization. We had a problem with order of operations generated by IA32 compiler - 80 bit precision generated slightly different results depending on operation order. Id reported this. There are applications depending on this! If we don't generate a test for it, people won't do it. Would like to propose this as a "conform" (not mustpass) test. Willing to help spec this.

Mahesh Dandapani: (didn't catch the question)

Dale: We had to force rounding modes.

Chris Frazier: Unfortunate that conformance is bound up in a license. At some point it became apparent that any code controlled by SGI that generated a "pass" or "fail" would serve the function of controlling the licensing process. Yet, conformance gets confused with driver quality, invariance, and other more important issues.

Ref page 601 in the red book - when can app programmers reasonably expect invariance? Ideally, every implementation team will have one champion of invariance - most HW implementors think invariance and "meeting customer expectations" is too high of a bar to reach. Meeting the letter of the spec is more appealing to implementors.

Worth considering other types of apps - will OpenGL run on a printer? A Pilot? Is it worthwhile to have layers of invariance for e.g. settop boxes, vs. higher levels for more capable platforms?

Jim: Originally we'd talked about raising the bar. We got busy implementing, dropped this concept. Still a lot of low-end parts that don't do simple things like all the blend modes.

Chris Frazier: There are areas not precisely specified, such as dithering and antialiasing. As this propagates forward, somewhere it becomes stated that you don't have to implement feature X. Have heard "you don't have to do this" when reality is you do, but e.g. some coverage values could be lax. Would like to see clarification of the difference between not doing something, and optimizing it.

Steve Wright: We're interested in pushing up the quality bar in WHQL testing. Today we just run conformance tests and screensavers. Haven't invested very heavily in increasing our own level of testing. Changes could become a barrier to entry, unless there's some way to ramp in the requirement over time.

Jim: We had talked about "Gold", "Silver", and "Platinum" conformance levels. Needs to be evolutionary.

Steve Wright: MS could push requirements into e.g. PC99 specification. It's more convenient to let the ARB drive this. Tests will get more intense due to Fahrenheit Scene Graph - we'll have a whole layer of system s/w sitting on OpenGL. Will phase in testing.

Jim: How do we get going on this? Can we expect SGI to do this?

Jon: How does this actually happen, given time requirements on everyone? Will anyone commit resources?

Jim: I think it needs to be done, and will spend my company time on it.

Chris Frazier: For quality tests, would be possible to ignore some of the odd cases (e.g. RGB 1/0/0 frame buffer) that conformance allows. Hardware engineers don't even understand what ogtsts do, but they encode powerful knowledge.

Jon: Are there issues/concerns with publically available test suites?

Nate: Would encourage the ARB to participate in administering the tests.

Steve Wright: Anyone can download WHQL tests. Binaries are available from the website, including conformance tests.

Chris Frazier: Concerned about a recent issue in which someone's implementation was questioned. Divisive issue. Perhaps have a quiet period to analyze tests / introduce them "softly" would help avoid backlash?

Jim: Agreeing on original conformance tests took a year. We'd probably repeat this with new tests.

Chris Frazier: Will be awkward to have a small number of tests created by one company, which someone fails. Would like to moderate exposure to the community based not on when some finishes writing the test, but in a somewhat sensitive fashion. Maybe release a body of 5-10 tests at first, and not have a binary pass/fail result?

Dale: Could OpenGL 1.3 represent a tightening of the spec? Everything wouldn't grandfather.

Chris Frazier: ARB extensions offer an opportunity for more stringent testing - multitexture test is an example.

Bimal: Have a problem with mandating quality tests since they may not agree with our market segment. For example, in my previous life, we introduced low-end hardware with no texturing which required software path. Didn't care to address the quality aspects of texturing.

Steve Wright: Tried segmenting by market in PC 9x specs. Challenging - today you wouldn't think of not having e.g. texturing.

Bimal: Might have a problem imposing quality tests on areas that someone didn't design their hardware to address. Also, how do you measure quality?

Dave Story: SGI will continue to provide conformance tests.

Bimal: Personally in favor of more quality tests, but might have issues with test group not realizing the quality aspects of the tests and perceive that the product is failing more tests.

Dale: Would rather leave quality issues for consumers to evaluate.

Bruce (I'm not sure at which point this was mentioned - Jon): Neither the programming guide or the reference manual leads the user to believe that there should be state/buffer invariance between display lists or immediate mode.

Extensions

David Blythe: Partly a discussion about process; we're having trouble getting agreement on some extensions. Let's try to use the meeting to do high-bandwidth discussion of 5-6 extensions, too.

New texture environment functionality - needed by multitexture. Mahesh, Michael, Tom Frisinger, David Blythe have all tried to get traction. Not trying to exactly match every vendor's hardware - impossible. Trying to break into a stratified set of levels that matches some hardware, but mostly is orthogonal and matches OpenGL functionality. We think we have enough agreement.

Michael: ATI and NVIDIA have been working on EXT_texenv_op. Very little feedback - only online feedback was from ISVs! Part of the problem is that everyone is building something different. Criticism: too hard, too easy. Looking at layered approach. Interesting aspect of original EXT_texture_env proposal was that it introduced a new environment.

Proposal: GL_TEXTURE_ENV1 (Blythe proposal) was fairly basic. Maybe make ENV2 with two operands, finer operations? ENV3 like texenv_op? ENV4 a general (a op b) op (c op d)? Are this many levels needed, or could we use a "2 1/2 operand" level with implied alpha?

Separately, not having an additive enivonment with multitexture is a real deficiency. Thinking about EXT_texture_env_add - like SGIX proposal, but without scale and bias terms.

Polled for interest: 7 people.

Blythe: will try and close on this within the next week. Just a point extension to have ADD in the base texture environment.

SGI's experience is that scale and bias are both useful. But we need to match developer's / designer's cycles.

Michael: people need to be a little more open, just to share comments.

Blythe: trying to renew faith that we're doing the best thing for OpenGL, not for particular IHVs. ISVs really do find good, orthogonal base functionality important. Don't want to check cap bits for every vendor. Want base to cover 80-90% of hardware capabilities.

People interested in texenv extensions should talk to Michael and Tom - either express interest or disinterest. Silence = consent. If you want to affect how this comes out, information needed in the next few weeks.

Nate Tuck: A few implementations support multitexture with 2 textures, a couple of operations - but we don't know where this is going.

Blythe: Right. That's why we start simply and build up in layered manner.

Michael: Advantage of doing this as a separate environment is keeping it independent of what people might do with e.g. fragment lighting later on.

Tom: No problem with ADD extension, but it sets a bad precedent. Michael and I are both getting pressure for e.g. MODULATE_2X as a new environment. This can bloat up OpenGL rapidly.

Michael: Should there be a scale or not? If it's easy to get agreement, this could be included.

Blythe: proposed guidelines for extensions:

• IHVs need to notify Jon to update registry and spec
• Should support old vendor-specific enumerants and extension string when promoting.
• Poll original vendor for agreement prior to promoting (Chris Frazier) to check e.g. IP issues
• Need guidelines for vendor-specific EXT headers (Jon)
• Host on opengl.org? (Michael) (Jon: SGI involvement not needed - can send directly to webmaster 'at' opengl.org)
• Ship out template <GL/glarbext.h> for ARB and EXTs.
• Include guidelines for vendor -> EXT promotion.
• Include template item for IP status (from Chris Frazier's later IP discussion).
• Point people to Steve Wright for WGL extensions (note that no base WGL specification exists).
• Should include full specifications in email, rather than pointing to a website (Chris Frazier).
• Try to clarify what "writing an extension" means - provide detail.
• Jon will commit to updating guidelines and updating opengl.org extension specs soon.

Bruce: There are problem with ISV specific extensions, e.g. KTX_buffer_region.

Michael: IHVs should ask other IHVs whether they're supporting ISV extensions. IHVs should also be responsible for educating ISVs on registry, etc.

Dale: Kinetix is rumored to be shipping more ISV extensions that are ill specified, such as vertex array extensions.

Poll: about 7 people implementing KTX_buffer_region. No people implementing new Kinetix extensions. When talking to IHVs, Kinetix seems to claim that everyone else is implementing them.

KTX_buffer_region is actually not a GL extension, but a Windows (WGL?) extension.

Blythe: Suggest that anyone working with an ISV should take it upon themselves to follow the guidelines.

Chris Frazier: Lawyers suggest it's a good idea to have defined procedures.

Jon: Encourage ISVs to get on opengl-arb-interest list.

Jim: Can't get every case - ISVs will insist on their own extensions in some cases. Do the best we can.

Kurt: If forced to implement ISV extension, also ship it as a vendor extension.

David Yu: Spec should be written - can be kept proprietary to ISV and implementing IHVs, but it should at least exist. It's in the ISV's own interest to have a spec!

Bill Armstrong: Need to make it easy for ISVs.

BGL

Rob Glidden, head of the BGL effort, gave a presentation. The BGL requirements document and presentation (in HTML and PowerPoint) are available. Discussion followed:

Kurt (discussing the proposed surfacing API): Most implementations today aren't OpenGL-centric; not a frightening concept.

James Bowman: Feedback on using OpenGL itself?

Rob Glidden: Assumption as to applications going on settops. Gets fat fast - VRML browser is e.g. 3 MB. Java - 1-2 MB. Etc. People aren't sure what goes in limited flash memory - allocating another MB for yet another new requirement (GL) generates pushback. W3C is getting pushback to componentize HTML itself. Chipmakers having a hard time pushing 1-2 MB more for GL.

If you can get GL library down to e.g. 1/4 MB, that's in the noise level - 1 MB makes people ask questions.

Fred Fischer: What about data footprint?

Rob Glidden: Just talking about code, which is the harder issue. Runtime footprint is another problem.

Jim: TCI is working on a WinCE based device using 12-16 MB total. Have reluctantly stepped up to 24 MB due to bloat - fighting over 100K. No VM, no mass storage.

Rob Glidden: Two views about having a single subset of OpenGL. One: define different profiles (subsets). Second: assume OpenGL, throw out things we can make a case for throwing out, have one profile. Will they converge? Don't know - depends on time to market. Display lists may be the most contentious feature.

Mahesh: How do you measure memory usage?

Rob Glidden: Flash, RAM, assume specified CPU performance. People are suggesting 2-4 MB code for full OpenGL on a conventional architecture.

Bill Clifford: What do you want from the ARB?

Jim: OpenGL 1.2 is too much - but the detailed specification is an important part. Questions: can BGL use OpenGL? How does this work? Expect this to crop up with other devices.

From a profiling standpoint, look at tiered approach with the top tier being the full specification.

Blythe: OpenGL was not designed as e.g. MPEG-4 generator - dropping out features may remove ability to render MPEG-4.

Rob Glidden: Two schools of content: where you don't know receiver, and you do (e.g. a Playstation 2 channel). In general, trend is towards a higher level standard, in which case OpenGL is the obvious choice - all MPEG-4 and VRML extensions are OpenGL based, also HTML and MPEG extensions being examined now. So content-level standards are all very comfortable with idea of OpenGL. Tension against hardware people (cheap boxes with known capabilities), video people (concerned about bandwidth), Java people, etc.

Pressure to add high-level "styles" (e.g. use bump mapping or not), NURBS, vectors - assumed to be scalable, and lower bandwidth.

Blythe: If ARB said "don't subset", what would that mean? Binary yes/no decision on using OpenGL?

Rob Glidden: Probably not. We'd find a subset ourselves and move forward. In terms of data, it's useful if accompanied with a rationale or explanation to pass on to BGL customers. Motivation is what the customer needs.

Blythe: Does BGL group have a good handle on arguments for not subsetting? Series of subtle reasons, not obvious.

Rob Glidden: Clear consensus not to subset based on a clear application need, but if there's a clear architectural line, several companies are interested in that.

Blythe: I'm testing to see how we could declare victory now.

Rob Glidden: Lower price of flash memory. Looking for data, ideas on how to resolve the situation.

Blythe: Without going into specifics on memory constraints, hard to know what to recommend.

OPC Discussion

Dale: A real problem is emerging in OPC that could put it out of business if not solved: what's valid to optimize in a display list? (Dale handed out a document outlining the problem).

Kurt: Dlists are opaque. Can't write a test to determine contents. We intended for a lot of optimizations to happen - the only ones that have happened are those that affected benchmarks! I consider it a complete failure from that standpoint.

Could you remove redundant glColor commands? Sure. Coincident polygons? No - breaks invariance. Spec is clear up front that you can do whatever you want as long as nobody can find out. Conformance can't detect this. The state vector is what counts.

Dale: Real example: can you remove the center point from two collinear line segments?

Michael: OPC problem is a bad dataset, not optimization. If it meets the spirit, that's what counts.

Rob Wheeler: One vendor claimed image "looked better" when doing this.

Chris Frazier/Kurt: Literal interpretation of spec is that results should be invariant with respect to dlist or immediate mode. No state will tell you if a list is being executed or not.

Fred: Expect that this invariance would not hold true for many implementations.

Chris Frazier: How many people present would know this about their own implementations?

Blythe: We thought carefully about this. Never would have occurred to me to drop a vertex.

Fred: Unclear if apps rely on this.

Chris Frazier: Lots of cases where OpenGL recommends/allows inferior rendering techniques for practical purposes (e.g. mipmap vs. anisotropy).

Repetitive discussion of these points continued for some time...

Fred: How many people have verified invariance of dlist and immediate mode?

Poll: HP, Intel, SGI, Intergraph, NVIDIA (would consider differences a bug, but hasn't verified it - they don't do anything that could possibly result in a difference).

Michael: There are "honest" and "dishonest" variances. Honest: compiler generated differences. Dishonest: driver developer generated differences.

Kurt: Conformance does try and detect this, and it does matter - that's why the tests are there.

Bill Armstrong: A portion, probably most of the ARB, believes that the spec mandates dlist/immediate mode invariance.

Chris Frazier: Does anyone believe the spec is unclear on this?

Dale: No. Not mentioned in Appendix A. The spec intended for display lists and immediate mode to be invariant.

Fred: I think it's unclear.

Chris Frazier: Invariance is specified as based on state. There is no state defining whether you're in dlist mode or not. Seems very clear.

Kurt: Dale could write a proposed addition to Appendix A (corollary).

Steve Wright: Could also propose a conformance test. We'd probably be happy to include such a test.

IP

Chris Frazier: Would like to see general policies to separate API issues from IP issues. Not phrased as suggestions (Chris is not a lawyer), but as talking points. (Chris handed out copies of a presentation - Jon added a title page to the online version to make sure the author is properly attributed).

Jon: SGI lawyers need to evaluate this before we can respond.

Steve Wright: Thinks that Microsoft lawyers would have them put a firewall around anything that's encumbered. MS won't be voting for or supporting any more ARB extensions until the legal situation is clear.

Bimal: Would simplest thing to do be to modify extensions template to make sure it has something to say about IP? Two types of licensees, MS and SGI. Could we walk this through several legal departments to get a statement of some sort?

Bruce, Bimal, Steve Wright, Jon: all will check with their respective lawyers. Try to determine what statement will make lawyers comfortable with dealing with extensions.

More Extensions

S3
Kent Lin of S3 passed out a formal statement regarding S3TC licensing - a copy from Kent's later email to Jon can be found here. For details, contact Rick Bergman at S3, (408)-588-8044.

Sun

SUN_constant_data allows the application to give the GL a hint that the texture data can be used without the GL making an internal copy of the data. This is useful for very large textures.

Jon has some nits: the extension string probably should be GL_SUNX_constant_data, not GL_SUN_constant_data. Also (a more general issue affecting other specs): extension specifications should be written against a specific version of the specification - last year we agreed that specs would be written against OpenGL 1.2 once it was finalized. And they should be written as changes to specific text, rather than as language inserted somewhere in a chapter.

Several people expressed concerns about the semantics of FinishTextureSUNX() followed by texturing some primitive. Blythe thinks that anything which breaks the GL abstraction barrier is dangerous. SGI experience is that SubTexImage* calls suffice.

SUN_global_alpha defines a new global alpha attribute that can be used to specify an alpha factor that is independent from the alpha component of the color value. This is useful for cases where many vertices share the same alpha value because the application does not have to send an alpha component for each vertex.

SUN_triangle_list allows multiple triangle strips or fans to be specified within a single glBegin / glEnd pair, by including a replacement code.

SUN_vertex allows an application to specify vertex data such as color and normal along with the vertex in one single GL command. This can minimize the overhead in making GL commands for each set of vertex data. Sparc has different issues WRT stack usage etc. than other CPUs so this may be less helpful elsewhere.

Blythe: Everyone is still struggling to cope with specifying vertices. How many care about this issue?

Poll: basically all "professional" vendors

Intel
INTEL_parallel_arrays is aimed at ``SIMD'' architectures like Pentium III. It allows passing coordinates in separate arrays instead of the current vertex array model with xyzw contiguous. Saves swizzling data prior to geometry. About 15% geometry path improvement compared to normal vertex arrays, for a multipass batched (into cache size) implementation. Slightly better if only transforming.

Bimal: One app vendor is going to a dynamic model, generating all data on the fly - no problem for them to generate data in this format.

Igor: Id is not geometry-bound, so not affected by this.

Suggestion made for a mixed block-stride (blocks of 4 xyzw) which was not received with wild enthusiasm - suggested this is more suitable for app-level geometry processing.

Rendition
Mahesh briefly reviewed EXT_texture_compression.

Bimal: Static/dynamic aspect should be moved out.

Kent: Questions use of internal format to control both size and format. Mahesh said that Kurt suggested (at the last meeting) a separate hint for quality. Kent discussed ability to trade off compression quality and decompression speed.

Mahesh: this extension doesn't support host compressed formats.

Kent: Agrees these can be separated. Concerned about enumerant explosion. Lots of them will never be used.

Friday, March 19

Specifying Display List / Immediate Mode Invariance

Dale proposed a new clause for addition to Appendix B:

21. For any GL and framebuffer state, and for any group of GL commands and arguments, the resulting GL and framebuffer state is identical whether the GL commands and arguments are executed normally or from a display list.

Fred: Interesting this comes up when the implementation standard is that differences do exist. Spec and conformance tests accomodate other types of differences in e.g. rasterization or mipmap selection. Before voting, would be interesting for people to talk to their own hardware and driver teams to see what issues come up. What 3Dlabs did or didn't do isn't the only type of possible display list optimization, e.g. lists might use floating point in less than IEEE resolution resulting in different fragment generation.

Dale: This isn't a change to the spec; it's a corollary (clarification) of what the spec already says. OPC is under the impression that invariance doesn't exist between lists and immediate mode, although the spec clearly says otherwise.

Michael: Challenge the notion that such differences are standard, and such differences where they do exist are unintentional, whereas decimating geometry is intentional.

Fred: May be true that such differences are unintentional, but they do exist and come up. Applications aren't looking for such differences. A statement that dlist/immediate mode is a major mode change allowing variance should be part of the spec.

Michael: My objection is that this tempts people to over-optimize for benchmarks.

Steve Wright: Reasonable chance of closing on a clarification, but a change to the spec requires more effort - new agenda item, working group, etc. Such optimizations are best handled in a scene graph API that has control over what's going on, not in GL lists where you don't know.

Chris Frazier: CAD apps already do this in their own code base. What would e.g. PTC think of how this affects their "quality" control?

Steve Wright: Sometimes apps are stupid, but these days mostly that's been fixed.

Bill Armstrong: PTC does over-tessellate on purpose. There's a control to tweak, but a lot of apps don't. They'll zoom in on a dataset and not want to recreate lists - overtessellation helps handle this.

If people can't understand the dlist/immediate mode list equivalence, needs to be clearly stated.

Fred: Can you elaborate on why this is important?

Michael: The kind of differences Kurt described yesterday are the same up to floating point differences. Not so with optimizations. Driver writer is reinterpreting the intent of the model author.

Fred: You're mixing up issues. What about geometry optimizations that generate the same fragments?

Chris Frazier: Explicitly allowed by spec - in terms of the GL and framebuffer state, no difference.

Some discussion and disagreement over how widely display lists are used.

VOTE called on adding clause 21: passes 9:1, 3Dlabs opposed. Jon will revise the OpenGL 1.2.1 specification.

Straw poll called on interest in modifying the spec re Fred's suggestion. 2 in favor, 2 abstain, most opposed.

Some discussion of an extension to allow such optimizations. Chris Frazier suggests COMPILE_AND_DECIMATE mode :-) Dale pointed out that scene graph optimizations would fight against driver optimizations. Steve Wright suggests adding Fahrenheit SG discussion to the next ARB meeting.

More Extensions (cont.)

ADD Texture Environment Mode

Should be EXT_texture_env_add, not EXT_texture_add_env. Typo, Michael will fix.

Michael has received feedback from 2 vendors who objected to adding constant color into the computation. So what's being proposed is adding color components, modulating alpha components, except in the case of INTENSITY textures where Af + It are added.

This is supposed to just cover what's perceived as a deficiency in OpenGL 1.2 or ARB_multitexture, not to address the pending problem of how to expose advance texture blending functionality.

Chris Frazier: Suggests modifying so Av = Af or Av = At throughout, to combine with a new extension to separate alpha / RGB modes.

Michael: Current approach allows selecting either of fragment or texture color by setting other alpha component to 1. Separate alpha / RGB is more important when combined with advanced blending modes, and would rather address this there.

Chris Frazier: Feedback from Brian Hook is that they don't do complex alpha operations - tend to pick one or the other. Apparently multitexture RGB operations are much more important than alpha.

Michael: Loathe to speak for Id, but I believe Brian is happy with this extension. This will serve needs of a majority of developers, the rest will need a new extension in any case. Don't want to aggrandize this further.

Chris Frazier: Just quibbling about INTENSITY function.

Michael: Goal is to get rapid adoption. Will drop constant color multiply, change extension string to env_add. Will move to drive more complex texenv_op extension to a close very soon - conference call / local meeting next week? (Michael got a list of interested parties, others not present at the meeting should contact him ASAP).

Raycer: We have a sense of where we want to be in a few years - full shading languages.

GLX Protocol / Connectathon

GLX 1.3 protocol encoding document is complete. Jon will call for ARB vote in about a week.

Compaq, IBM, SGI, Sun have come across some interoperability problems recently. Not just problems on one side, sometimes each side is partly responsible. All are are interested in a connectathon. IBM could host, if it wasn't associated with an ARB meeting. Take offline for discussion of details - do we want to bring workstations next time?

Jon discussed the recent GLX open source release by SGI. Main motivation is to lend coherence to the rapidly increasing number of OpenGL driver projects for Linux and XFree86. Not just open source projects, rapidly increasing number of IHVs are interested.

Java Bindings

Arcana is discontinuing Magician.

Sun has worked out a prototype codebase, and Jack discussed open issues in 3 areas:

• Performance (Magician claimed ca. 90% of C code; Sun experience is that it's up to 10x slower in immediate mode Java. Needs to boost performance to have adoption.
• Need to work through window system integration. Can't do what e.g. Java[23]D have done - they always use latest JDK rev. GL bindings need to run on JDK 1.1.
• Event handlers. Magician has a lot of code to enable GLUT-like capabilities - events, context switching, thread management. Sun's goals are that the bindings should provide an interface to the capabilities of OpenGL, not much else. Looking at removing a lot of those capabilities. Is there something within the Java platform that would require taking a different approach from OpenGL?

Status: prototype can do some basic things, benchmark programs.

Concerned that not much effort is being put into JNI, which is where the performance loss is happening. Possibly buffering calls between Begin/End and turning that into a single C call. If you know something about your JNI, may be able to do something more efficient. A naive implementation using native interfaces won't get close to C bindings. Depends a lot on the accelerator - geometry processing on host reduces performance differential to perhaps 5x.

Composable pipelines hurt performance - leave as an extension.

Problems with heavyweight components - don't mix well with newer lightweight components, but can only get hardware acceleration through older components. Some workarounds and limitations. Looking for a longterm, general solution. Magician was basically implementing pbuffers - offscreen rendering copied to a lightweight window.

Will try to resolve lightweight / heavyweight components to work together correctly. Ultimate goal is a Swing component that can be rendered into with acceleration. A fair amount of work is going into this, but solution not expected soon. Arcana wanted a Swing-type component in the spec, Sun feels that's not a longterm solution.

David Yu: What's the best way to make progress towards a formal spec?

Jack: Can't get someone free now - mandated to work through performance issues first. Could we get an external volunteer? [apparently not] Seems that this is important to OpenGL, but companies don't want to commit resources to work on this right now.

Nate: Harder to commit resources when it's not clear what needs to be done - still defining the problem. How do other companies contribute to what Sun's doing?

Jack: Sun will put out status reports.

Nate: People looking for the effort to jell within Sun first.

Blue Book

Chris Frazier: Dave Shreiner is working on this. If it's to get out by SIGGRAPH, a gating issue is whether sufficient ARB review can be had within the next few weeks. Who are the people who should review this? The entire ARB? Or possibly the ARB's name could be taken off the book.

Bimal: Should send out to the entire ARB and let interested parties review it.

Chris Frazier: Needs to ship to publisher by May 1st. ARB review may be a chokepoint. Dave Shreiner can probably handle all other issues. Will ask Dave to give an update on timing, form of review documents, etc.

Steve Wright: Haven't heard a word about using WGL pages. Dave Story should talk with Steve ASAP.

Conformance

Remaining minor issues will be discussed as code drops from SGI go out. At the last meeting, there were some questions about how Windows IHVs could use this code. Steve Wright says that IHVs have access to conformance source too.

As Michael Gold mentioned earlier, draft of multitexture conformance test is coming soon, too.

Next Meeting

ATI will host the next ARB meeting, June 15-16 1999 in Boston, Massachusetts. Tom will send out more information shortly.

End Of Official ARB Meeting

Post-Meeting Extension Discussion

The ARB meeting ended early. Interested parties remained to discuss EXT_texenv_op in the afternoon. David Yu proposed a new functionality layering scheme using only the existing APIs with new enumerants. This was well received and will probably be adopted quickly by NVIDIA and ATI. Michael will provide details to the opengl-arb-interest mailing list.

Thanks to 3Dfx for hosting this meeting!