Action Items / Conclusions from the Meeting
- GLX_ARB_render_texture spec should be done and voteable soon.
- Will continue defining proposed feature set for next summer's OpenGL
revision on the mailing list.
- Status report on OpenGL "embedded subset" activity from
the Khronos SIG.
- Discussion of alternate voting schemes. Agreed that future formal
email votes will be secret ballot until the vote is closed.
- Formed working group to develop an extension for memory buffers
that are repurposable within the graphics pipeline, starting with
the "über buffers" white paper and earlier 3Dlabs
work in this area.
- Reviewed high-level shading language specification. Nearly
complete, vote to be called within the next few weeks.
- Bylaws working group continues working on membership level, IP
disclosure, etc. revisions. First amendment to the bylaws
successfully voted in.
- Vertex array object working group near completion, vote should be
called in early January.
- OpenGL extensions to bind to the shading language need some refinement
including choice of object model. Expected to be completed by end
of January.
- Restarting low-level vertex program working group to add support
for new hardware features like conditionals and branching.
Summary of Discussion Topics
Tuesday, December 10
Introductions
GL2 group meeting weekly. Latest draft of shading language spec has
very few issues remaining. More work remains on the GL2 extensions
themselves; hope to get some of that done at this meeting.
VAO group has been meeting weekly for 2 months driving
ARB_buffer_object proposal. Will continue with conference
calls after the meeting, working on other extensions.
Conformance tests held up. Previous volunteer to lead the working
group no longer available, and some licensing issues still being
worked by SGI so contributed tests are redistributable to licensees.
Hope to pick up the working group soon; Alt.software has volunteered
to lead it.
Bylaws group developed Amendment #1 to let us make changes in IP
disclosure portions of the Bylaws. The Amendment was voted in
unanimously by the Permanent Members. Now looking at Apple and
Microsoft IP policy proposals; will choose one and move forward.
Membership level proposal also on the table.
March ARB meeting details to be determined - potential volunteers
should contact Jon ASAP.
GLX_ARB_render_texture
Nick forwarded some comments on the updated draft spec from Paula
Womack, the original spec author:
- Seemingly redundant render-to-texture state in Pbuffer and
FBConfig.
- Need to decide which visual types map to texture formats
(suggest no LA). Suggest single-channel visuals map to L or I,
three-channel to RGB or RGBA.
- When buffer is bound to a texture, must be preserved even if
preserved attribute is false.
- Needs GLX protocol defined.
Interested parties (probably Jon, Paul, Brian Paul, Bill Licea-Kane)
will finish this up by email - probably doesn't merit a full WG
since we are just replicating a proven WGL extension.
NVIDIA has a WGL_render_depth_texture extension which
layers on WGL_render_texture. IBM is probably interested in
a GLX version of this. NVIDIA also has a
NV_render_texture_rectangle extension which is simple and
may be of interest.
Pat Brown has a bunch of issues NVIDIA ran into implementing the
WGL_render_texture extension which he'd like to bring up,
too. May setup a full working group to discuss all this.
Next OpenGL Revision
Matt has a list of 5-10 existing extensions (some ARB, some not)
he'd like to see put into a new core. No technical or policy reasons
not to put a high level language in OpenGL. However, we can expect
some IP issues.
Dale would like to see synchronization features added to the core.
Matt would like ARB_vertex_program and
ARB_fragment_program included in the new core. Also the
ARB_buffer_object spec, if it's in time - lots of demand
from ISVs.
NV_float_buffer also suggested. ATI thinks floating point
is essential, but needs to be more generic - here's what floats do,
here's how the spec changes - rather than exposing one architecture.
So they would remove some restrictions in the NV spec. NVIDIA is OK
with adding support for all texture targets but would resist adding
blending support - for example, it's not clear how to implement
glLogicOp on floating point values. They also have some
hesitation to define an extension which is not implementable on any
current hardware.
NVIDIA has a "quasi-shipping" (in NV30 emulation)
extension to expose FP pixel formats, though they cannot be used to
render to displayed windows.
Apple's feedback is that their customers don't need more than 10
bits/pixel integer components today. Floating-point buffers are
undisplayable on current hardware.
Current spec has [0,1] clamps in several places, and implicit
assumption of clamped ranges elsewhere. These need to be relaxed for
FP pipelines. Current NV spec does this only for fragment programs,
but it could be done for the fixed-function pipeline as well.
We should develop guidelines on what features people want in FP
buffers, to guide this. ATI also has FP pixel format and texture
extensions and is willing to compare that to NV extensions as a
starting point.
NVIDIA would like to make some common operations, like render to
texture, into pure GL functionality rather than something requiring
multiple contexts and visuals. They suggest migrating WGL
functionality into the core spec. ATI noted the über buffers
proposal encompasses much of this.
Other extensions Matt suggests for the updated core:
- EXT_stencil_two_side
- EXT_shadow_funcs
- NV_point_sprite
- NV_fence, or other synchronization primitives
- Occlusion queries
- NV_texture_rectangle (note: Apple has an
EXT_texture_rectangle spec which is very similar, but
not in the registry yet)
- NV_half_float
- "Point cull" extension - is this something ATI wrote
when examining NV_point_sprite? It appears nobody is
shipping this today.
- Radial fog
- Maybe a few more minor extensions?
We will continue discussion on a new core revision in the main
participants' mailing list.
Khronos "OpenGL ES" Update
Neil summarized
progress on the embedded subset being developed within Khronos.
Voting Strategies
WGs sometimes find themselves making essentially arbitrary (e.g. no
clear technical winner, lots of divisiveness) decisions by vote. How
can this best be done? Lots of information on voting strategies on
the web now. Allen got into this when we were struggling with some
ARB_vertex_program decisions. There are at least half a
dozen variant voting schemes which have better mathematical
properties, such as acceptance voting (yea or nay on each
alternative), Condorcet (ranking), and Borda counts (ranking with
weighting, sum up weights).
Considerable variation in what big standards bodies do. Highest
level voting policies tend to be tightly specified and complex.
Loosely, they tend to be majority-rule based. Different weights
given to votes based on class of membership. Multi-round voting is
common; failure of unanimous votes leads to revote on reduced
options.
Recent example from GL2 group: object handle/ID votes. We had
previously constructed a spectrum of 6 possible solutions as
examples; a simple Yea/Nay vote on that many options would probably
have failed. Acceptance voting fell down on specifying what a cutoff
level of acceptability might be. Borda voting came up several times
as a possibility, and was tried.
ACTION: formal votes going forward will be secret ballot until the
vote is closed. We may want to reduce the duration of email voting
periods in revising the Bylaws, and more tightly specify voting
rules and other working group operating principles.
Super Buffers
Rob Mace distributed a white paper on "über buffers"
They differ from current objects (like texture objects); instead of
being "buckets" which contents are placed into, über
buffers are their content.
Buffer properties are specified at creation time, including
potential uses.
Considerable discussion followed, and lots of concerns and requests
for clarification were raised. A straw poll was strongly in favor of
creating a working group to explore this area. Rob will lead the new
WG, which he and Kurt agreed to call "super buffers", and
develop ideas from his white paper, related ideas from 3Dlabs
proposals via Randi and Barthold, etc. into an ARB extension
proposal.
Shading Language
Bill reviewed final open issues in the shading language
specification.
Long discussion about bitwise integer operations and being able to
store integers in textures, for ISVs who want to pack multiple data
channels into a single texture component. Also need some way to get
unprocessed integer data into texture memory; this is not easy today
though NV_texture_rectangle has a potentially useful
concept of turning off processing when loading float texture data.
Could revive EXT_index_texture to support this.
Revisited issue 23, ability to read from the framebuffer. After
considerable discussion, including the performance costs of this in
deeply pipelined architectures and desirability of overturning WG
decisions in the full ARB, we revoted and decided this would
not be supported by a large margin.
7-8 new issues discovered during review. Bill will add to the spec.
We will resume discussions tomorrow afternoon.
Wednesday, December 11th
Bylaws Revisions
Amendment #1 has been approved by the Permanent Members; we are now
collecting their signatures. This change enables further bylaws
revisions in areas such as membership levels, IP disclosure
policies, working group creation, etc. The working group will
continue developing changes in these area.
Vertex Array Objects
Matt summarized the features and purpose of the
ARB_buffer_object extension. Dale observed that the spec
allows all GL commands to be issued while a buffer is mapped, but
has undefined behavior when rendering from a mapped buffer. Matt
noted this is not an inconsistency, though it imposes the
performance cost of checking whether or not the buffer being drawn
from is mapped.
Lots of discussion of buffer map behavior in various circumstances
that might change mappings, such as uninterruptable power save
events on portables.
Discussion of new intptrARB and sizeiptrARB types.
Need suffix attached in the spec, and more informative definitions.
Discussion of indirect protocol issues - server must be able to
interpret client data and translate as needed at draw time. We
should continue using use "basic machine units"
terminology for sizes and offsets.
Straw poll on whether this spec was the right general direction for
us to pursue; almost everyone in favor, modulo remaining concerns
expressed during the discussion.
Working group will resume telecons and plan to have the final spec
and an implementation done in early January for an email vote.
OpenGL Extensions for the Shading Language
The shading language specification is closer to completion
than the GL2 extensions, though neither is quite finished. We
may choose to vote on the language first and the extensions
later, though there are some drawbacks of that.
Bill summarized the Borda-count vote held to determine the object
management strategy. Approach (3) - a single classic ID namespace
managed through a single API - narrowly won over (4), the handle
proposal. This affects the GL2_shader_objects extension
proposal.
Lengthy discussion of GL2 program management vs. low level program
management - can some of the low level mechanism be reused?
How to move forward?
- Matt will send out, by next Tuesday's telecon, an example
building on the existing program API, but exactly equivalent to
the GL2 examples, as a proof of concept.
- Close remaining open (and newly opened) issues on the shading
language spec at next week's call.
- GL2_vertex_shader and GL2_fragment_shader
extensions are less controversial than is
GL2_shader_objects. Still, someone needs to scope the
differences between these and the existing low-level APIs.
- Bill wants to call the shading language vote before the end of
December. The GL2 specs should be complete by the end of
January. Need to have everything approved by March to get them
into a core spec revision by SIGGRAPH.
Low-level Program Revisions
Pat Brown has offered to head a new working group to review the
low-level instructions sets for advanced features such as looping,
branching, and subroutines. This will be harder since there's more
variability in different IHV's feature sets than there was for the
original low-level instructions - how do you express restrictions?
Pat suggests looking at NV_vertex_program2 for an example
of new capabilities. He asked for input and requests for the areas
that the group should look at. ATI is interested and recognizes the
differences in capabilities in current-generation hardware.
As a conceptual bound on this exercise, Jon suggested looking at the
high-level shading language, determine its requirements if it
were to be compiled into the low-level language (which isn't how
we expect implementations to work), and understand the gap in
capabilities. But the low-level instruction sets are tracking
restrictions of current hardware while the high-level language is
more forward-looking.
This could be a lot of work; another strategy is to narrow down
NV_vertex_program2 to the common subset of supportable
operations. This seems considerably easier.
Pat will convene a new working group and start looking at the
instruction set compatibility issue; the group will decide how to
proceed.
Thanks to NVIDIA for hosting this meeting!
