MESAX_array_element_base

Name

Name Strings

Contributors

Contact

IP Status

Status

Version

Number

Dependencies

Overview

Issues

  1. Is MESAX_array_element_base the right name for this extension? The name choice and the choice of enum and function names was based on the EXT_compiled_vertex_array extension.
    • YES. Nobody seems to have a better name, and nobody seems to object to the current name.
  2. Should !ArrayElementBaseMESAX calls be compiled into display lists?
    • YES. The functionality does not seem very useful, but it is consistent with the rest of the API.
  3. Should there be a separate element base for each vertex array target? It may be useful to use a different set of position and normal data for each mesh, but keep the same texture coordinate data, for example.
    • NO. Having a per-array base isn't really any different than resetting the pointer for the array. The two main optimizations possible with this extension are having a single API call and being able to use a hardware base-index "register". Having a per-array base defeats both.
  4. Should this extension really be MESAX?
    • YES. This is experimental functionality. The resolution of issue #3 in particular may change the API radically. Not only that, ISVs may find this extension to not be useful, and it will just go away.
  5. What happens when base+i overflows the range of the datatype supplied to DrawElements or DrawRangeElements?

    • UNRESOLVED. The current thinking is that it won't matter due to the way the extension is defined. It is defined as a modification

      to the behavior of ArrayElement. The type passed to ArrayElement is a signed int. Some words may need to be added to the fifth paragraph on page 25 stating that if (base+i) overflows a signed int, the behavior is undefined.

  6. What happens if base+i is outside the [start, end] range passed to DrawRangeElements?

    • RESOLVED. No special wording is needed. The 1.5 spec is very clear, on page 27, that it is the values in the supplied array that are contrained to [start, end]. Since it specifically states that it is the values in the indices array, the base value is never taken into consideration for the range clamping.
  7. Should negative base values be allowed?
    • NO. While this is somewhat arbitrary, it's not known how hardware with a base-index register would handle a negative value. It also seems like a negative base value would

      "encourage" cases where (i+base) < 0. If this extension is every promoted to a higher status, this issue may be revisited.

New Procedures and Functions

New Tokens

Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation)

Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)

Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment Operations)

Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions)

Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State Requests)

Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)

Additions to the AGL/GLX/WGL Specifications

GLX Protocol

Interactions with EXT_draw_range_elements

Errors

New State

Get Value

Get Command

Type

Initial Value

Description

Section

Attribute

ARRAY_ELEMENT_BASE_MESAX

GetIntegerv

Z+

0

Base array element index

2.8

vertex-array

New Implementation Dependent State

Revision History