Summary of Discussion Topics

• ARB Extensions
  • ARB_texture_lod_bias
  • ARB_texture_env_combine
  • ARB_texture_env_dot3
  • ARB_texture_env_multi_fetch
  • Summary of Combiner Discussion
• Embedded Graphics APIs
• ARB Extensions, cont.
  • ARB_render_texture
  • ARB_matrix_palette
  • ARB_object_manager
• Developer Conference
• Khronos Update
• ARB Extensions, cont.
  • ARB_texture_lod_bias (cont.)
  • ATI_vertex_transform
  • ARB_texture_lod_bias (cont.)
• Next Meeting

December 5, 2000

Introductions

Imagination Technologies and NEC are attending their first ARB meeting as new Participants.

ARB Extensions

ARB_texture_lod_bias

Revised per previous discussion, to allow biasing in two places.

Bimal: we're specifying a texture fetch parameter via the texture environment. Would favor a new entry point for this type of parameter.

Michael and Bimal will revise and bring back tomorrow for voting.

ARB_texture_env_combine

Bimal has updated spec and broken into 3 parts.

ATI and Intel are engaged in litigation and, because texture_env_combine is being considered for ARB status, ATI must claim some IP WRT these extensions. Still determining which of the three extensions are affected.

Bimal: original proposal removed ARG2 restriction, allowed choosing any texture as input to other texture units, etc. Not every vendor was willing / able to support all of this functionality. Breaking extension into base + additional features makes it more widely implementable.

Base spec is ARB_texture_env_combine - mostly the same as EXT version. Adds SUBTRACT operation and removes restriction on ARG2; otherwise identical.

ARB_texture_env_dot3

This layers on ARB_texture_env_combine. Backwards compatibility concerns, so it will use new enums for DOT3_RGB{A}_ARB vs. the existing EXT extension.

Clamping concerns are handled in base texture_env_combine spec.

ARB_texture_env_multi_fetch

This also layers on ARB_texture_env_combine. It allows routing textures associated with any lookup unit to any blend unit.

NVIDIA has problems with disabling texture units referencing invalid/disabling textures; their current implementation has implementation-dependent behavior, which eases validation of the texture pipeline. After considerable discussion, straw poll showed most people in favor of retaining validation.

3Dfx has problems with the arbitrariness of routing - would like only upstream textures to be used in downstream units. Straw poll showed most people in favor of retaining full crossbar switching.

Will rename to ARB_texture_env_crossbar.

Summary of Combiner Discussion

Straw poll showed all in favor of ARB_texture_env_combine and ARB_texture_env_dot3. 3dfx and possibly NVIDIA object to ARB_texture_env_crossbar; Microsoft abstains but would probably vote in favor; E&S abstains.

Jon will check with Michael Duncheon on how we can potentially approve specs known to be encumbered by IP. E.g. ATI does not want to prevent people from using texture_env_combine.

Embedded Graphics APIs

ARB_render_texture

Dale asks why 3D textures are supported - hard to implement because the texture depth is unknown when the buffer is created. Paula points out this isn't true - depth is specified as part of the attribute list when creating the pbuffer.

Pat notes that texture and pbuffer organization may not be the same. Bimal responds that you would only expose this functionality if appropriate for the architecture, and the API doesn't prevent an opaque fast copy at bind time. Pat also objects to allocating a huge 3D texture if a fast copy (e.g. duplicate memory consumption) is involved.

Bimal suggests adding additional flags to the PFD/FBConfig identifying whether it can (should?) be used for rendering to each of 1D, 2D, and 3D textures.

Dale wanted to know why the ibuffer argument to ReleaseTexImageARB is required, when the GL already knows what buffer is bound. Paula wanted to allow implementations to support pbuffers with multiple bound color buffers.

Pat asked what happens to the state of the texture after the pbuffer is unbound. Paula says it should be as if there's a null texture bound, but that the spec needs to describe this, and she'll take care of it.

Need to add ERROR_INVALID_DATA error for CreatePbufferARB when specifying 3D texture depth, as well as width and height. Likewise when specifying an invalid mipmap level, or specifying a depth offset invalid for the current mipmap level.

Depth offset and mipmap level are interdependent, so how should they be changed to avoid potentially generating errors? A: silently clamp offset if necessary.

WGL has no way to create e.g. an INTENSITY-only pbuffer if an INTENSITY texture is desired. Will take out WGL_COLOR_BITS and ability to do INTENSITY/LUMINANCE textures until some way of exposing such pbuffers via WGL is available.

Pat asks that description of cube map binding be cleaned up.

Considerable discussion about semantics of calling TexImage/CopyTexImage on a texture bound to a pbuffer.

Bimal wants pbuffer memory to not be released when deleting the texture via GL. E.g. there would be a reference count kept on the memory, once for the buffer itself and once for the GL texture.

Straw poll on 3 options: as currently speced (implicit release); generate INVALID_OPERATION GL error; behave exactly as if a texture generated only by TexImage calls. Option 1 polled a clear majority, no recount allowed or needed. Thereupon followed more argument about the options and a conclusion to punt the decision back to the working group.

Bimal suggests that specifying LARGEST pbuffer in this case be defined to retain the aspect ratio of the requested pbuffer by reducing by a factor of 2 in each dimension until it fits.

Bimal also wants to drop MIPMAP_TEXTURE_ARB attribute from BindTexImageARB, since it's redundant with CreatePbufferARB.

Bruce likes the usage section. Asks whether issue 6 could be dealt with by forcing a MakeCurrent; it's unusual to be rendering but having nothing happening. Paula notes that the null clip can happen already.

ARB_matrix_palette

Jeff suggests that the implementation be allowed to use LoadMatrix or not for MatrixIndexARB (currently, the Issues list says no, MODELVIEW matrices are unused when MATRIX_PALETTE is enabled).

Pat wants to change CurrentPaletteMatrixARB -> PaletteMatrixARB. Other issues: may not be covering all cases in section 2.10; need to specify one matrix stack/MODELVIEW matrix in 2.10.2 (ARB_vertex_blend spec should already do this); should be labelled as written against the 1.2 spec.

Intel and NVIDIA think that this isn't of broad enough interest to be an ARB extension. 3dfx disagrees. ATI thinks it might be a good candidate for approval by the ARB in the future. Some discussion about the extension process followed - in cases like this, we want to give a better read to group leaders as to whether it's worth pursuing this in the ARB, or getting the functionality out more quickly as an EXT.

VOTE: 7Y/5A/0N, PASSES.
(Note: ARB voting rules are a supermajority of non-abstaining votes, so this does in fact pass)

ARB_object_manager

Allen Akin is unfortunately not present. He's getting more involved in Khronos to accomodate their needs.

Developer Conference

Derek Tarvin at SGI is taking over organizing this. Please contact him (dtarvin@sgi.com) if you want to help.

Khronos Update

Bill Clifford provided an update on the Khronos SIG's progress. They are targeting a final spec in Q2 CY 2001, and want to announce at NAB, in late April. The GL component of Khronos is mostly picking up existing GL extensions and adopting them - synchronization control, video data formats, etc.

December 6, 200

ARB Extensions, cont.

ARB_texture_lod_bias (cont.)

Bimal is concerned about the bias being in the environment, because it might result in different biases being applied to the same texture fetch unit, causing multiple fetches. Nick disagrees, stating that the bias is applied in the fetch unit.

Currently, TexParam parameters apply to the "lookup unit", while TexEnv parameters apply to the "blend unit". Maybe there should be a new call, rather than putting the state in the environment? But it's naturally a part of the fetch operation.

Creating a new entry point depends on having a way to distinguish fetch and blend units. Bimal had a draft proposal for this which has received no comment so far. Will keep discussing on the texenv-combine working group. Should it be part of the ARB_texture_env_crossbar extension? Probably not, since e.g. 3dfx might want the fetch/blend distinction too, but without the full crossbar extension.

Bimal's concern is ISV confusion by using TexEnv to set fetch parameters; however, using a different TexEnv target addresses this somewhat.

Straw poll showed about 2:1 in favor of the current TexEnv approach over a new entry point. Will try and vote after lunch.

ATI_vertex_transform

(Note: minutes on this topic are fragmentary - lots of points were raised that I was unable to capture properly. Additions / corrections are particularly appreciated here)

ATI has incorporated most comments from last working group meeting. Additional feedback from 3dfx is being looked at.

Primary changes: RasterPos is not affected; some naming changes, still being discussed.

Jon notes we should change uint* to void* in SetTransformStateATI and SetVariant{Pointer}ATI calls.

Jeff thinks that parameter to GenDataATI should be dropped, Pat and Bimal find it confusing - NORMALIZED has several possible meanings - and would like a different name, or to fold this into the parameter by doubling the number of enums.

Other 3dfx issues: Kelvin Thompson's comments from 11/27 on the working group.

Should add min and max program size queries.

Jon Paul raised issue of output to eye space, instead of clip space. Matrox has considered not having separate swizzle/write mask instructions, supplying indices instead. Asked whether it's desirable to make existing GL state available to vertex programs, instead of requiring them to use new invariant data inputs - ATI notes that this makes it easy to do incremental changes, e.g. replacing only the lighting model with user code.

Some discussion about desirability of software fallbacks. Feeling seems to be that implementations should not have to do software fallbacks, but should have to support minimum program sizes which are reasonably expressive. Need runtime queries to determine whether a program and data fit, rather than / in addition to implementation dependent limits.

ARB_texture_lod_bias (cont.)

Revised proposal circulated.

VOTE: 6Y/2A/4N, FAILS.

E&S, 3Dlabs, Microsoft all would vote yes if a new entry point is added (e.g. TexFilterParamARB) to specify the bias.

Next Meeting