| Name |
| |
| NV_vertex_array_range |
| |
| Name Strings |
| |
| GL_NV_vertex_array_range |
| |
| Contact |
| |
| Mark J. Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright NVIDIA Corporation, 1999, 2000, 2001. |
| |
| IP Status |
| |
| NVIDIA Proprietary. |
| |
| Status |
| |
| Shipping (version 1.1) |
| |
| Existing functionality is augmented by NV_vertex_array_range2. |
| |
| Version |
| |
| NVIDIA Date: September 17, 2001 (version 1.1) |
| |
| Number |
| |
| 190 |
| |
| Dependencies |
| |
| None |
| |
| Overview |
| |
| The goal of this extension is to permit extremely high vertex |
| processing rates via OpenGL vertex arrays even when the CPU lacks |
| the necessary data movement bandwidth to keep up with the rate |
| at which the vertex engine can consume vertices. CPUs can keep |
| up if they can just pass vertex indices to the hardware and |
| let the hardware "pull" the actual vertex data via Direct Memory |
| Access (DMA). Unfortunately, the current OpenGL 1.1 vertex array |
| functionality has semantic constraints that make such an approach |
| hard. Hence, the vertex array range extension. |
| |
| This extension provides a mechanism for deferring the pulling of |
| vertex array elements to facilitate DMAed pulling of vertices for |
| fast, efficient vertex array transfers. The OpenGL client need only |
| pass vertex indices to the hardware which can DMA the actual index's |
| vertex data directly out of the client address space. |
| |
| The OpenGL 1.1 vertex array functionality specifies a fairly strict |
| coherency model for when OpenGL extracts vertex data from a vertex |
| array and when the application can update the in memory |
| vertex array data. The OpenGL 1.1 specification says "Changes |
| made to array data between the execution of Begin and the |
| corresponding execution of End may affect calls to ArrayElement |
| that are made within the same Begin/End period in non-sequential |
| ways. That is, a call to ArrayElement that precedes a change to |
| array data may access the changed data, and a call that follows |
| a change to array data may access the original data." |
| |
| This means that by the time End returns (and DrawArrays and |
| DrawElements return since they have implicit Ends), the actual vertex |
| array data must be transferred to OpenGL. This strict coherency model |
| prevents us from simply passing vertex element indices to the hardware |
| and having the hardware "pull" the vertex data out (which is often |
| long after the End for the primitive has returned to the application). |
| |
| Relaxing this coherency model and bounding the range from which |
| vertex array data can be pulled is key to making OpenGL vertex |
| array transfers faster and more efficient. |
| |
| The first task of the vertex array range extension is to relax |
| the coherency model so that hardware can indeed "pull" vertex |
| data from the OpenGL client's address space long after the application |
| has completed sending the geometry primitives requiring the vertex |
| data. |
| |
| The second problem with the OpenGL 1.1 vertex array functionality is |
| the lack of any guidance from the API about what region of memory |
| vertices can be pulled from. There is no size limit for OpenGL 1.1 |
| vertex arrays. Any vertex index that points to valid data in all |
| enabled arrays is fair game. This makes it hard for a vertex DMA |
| engine to pull vertices since they can be potentially pulled from |
| anywhere in the OpenGL client address space. |
| |
| The vertex array range extension specifies a range of the OpenGL |
| client's address space where vertices can be pulled. Vertex indices |
| that access any array elements outside the vertex array range |
| are specified to be undefined. This permits hardware to DMA from |
| finite regions of OpenGL client address space, making DMA engine |
| implementation tractable. |
| |
| The extension is specified such that an (error free) OpenGL client |
| using the vertex array range functionality could no-op its vertex |
| array range commands and operate equivalently to using (if slower |
| than) the vertex array range functionality. |
| |
| Because different memory types (local graphics memory, AGP memory) |
| have different DMA bandwidths and caching behavior, this extension |
| includes a window system dependent memory allocator to allocate |
| cleanly the most appropriate memory for constructing a vertex array |
| range. The memory allocator provided allows the application to |
| tradeoff the desired CPU read frequency, CPU write frequency, and |
| memory priority while still leaving it up to OpenGL implementation |
| the exact memory type to be allocated. |
| |
| Issues |
| |
| How does this extension interact with the compiled_vertex_array |
| extension? |
| |
| I think they should be independent and not interfere with |
| each other. In practice, if you use NV_vertex_array_range, |
| you can surpass the performance of compiled_vertex_array |
| |
| Should some explanation be added about what happens when an OpenGL |
| application updates its address space in regions overlapping with |
| the currently configured vertex array range? |
| |
| RESOLUTION: I think the right thing is to say that you get |
| non-sequential results. In practice, you'll be using an old |
| context DMA pointing to the old pages. |
| |
| If the application change's its address space within the |
| vertex array range, the application should call |
| glVertexArrayRangeNV again. That will re-make a new vertex |
| array range context DMA for the application's current address |
| space. |
| |
| If we are falling back to software transformation, do we still need to |
| abide by leaving "undefined" vertices outside the vertex array range? |
| For example, pointers that are not 32-bit aligned would likely cause |
| a fall back. |
| |
| RESOLUTION: No. The fact that vertex is "undefined" means we |
| can do anything we want (as long as we send a vertex and do not |
| crash) so it is perfectly fine for the software puller to |
| grab vertex information not available to the hardware puller. |
| |
| Should we give a programmer a sense of how big a vertex array |
| range they can specify? |
| |
| RESOLUTION: No. Just document it if there are limitations. |
| Probably very hardware and operating system dependent. |
| |
| Is it clear enough that language about ArrayElement |
| also applies to DrawArrays and DrawElements? |
| |
| Maybe not, but OpenGL 1.1 spec is clear that DrawArrays and |
| DrawElements are defined in terms of ArrayElement. |
| |
| Should glFlush be the same as glVertexArrayRangeFlush? |
| |
| RESOLUTION: No. A glFlush is cheaper than a glVertexArrayRangeFlush |
| though a glVertexArrayRangeFlushNV should do a flush. |
| |
| If any the data for any enabled array for a given array element index |
| falls outside of the vertex array range, what happens? |
| |
| RESOLUTION: An undefined vertex is generated. |
| |
| What error is generated in this case? |
| |
| I don't know yet. We should make sure the hardware really does |
| let us know when vertices are undefined. |
| |
| Note that this is a little weird for OpenGL since most errors |
| in OpenGL result in the command being ignored. Not in this |
| case though. |
| |
| Should this extension support an interface for allocating video |
| and AGP memory? |
| |
| RESOLUTION: YES. It seems like we should be able to leave |
| the task of memory allocation to DirectDraw, but DirectDraw's |
| asynchronous unmapping behavior and having to hold locks to |
| update DirectDraw surfaces makes that mechanism to cumbersome. |
| |
| Plus the API is a lot easier if we do it ourselves. |
| |
| How do we decide what type of memory to allocate for the application? |
| |
| RESOLUTION: Usage hints. The application rates the read |
| frequency (how often will they read the memory), the write |
| frequency (how often will they write the memory), and the |
| priority (how important is this memory relative to other |
| uses for the memory such as texturing) on a scale of 1.0 |
| to 0.0. Using these hints and the size of the memory requsted, |
| the OpenGL implementation decides where to allocate the memory. |
| |
| We try to not directly expose particular types of memory |
| (AGP, local memory, cached/uncached, etc) so future memory |
| types can be supported by merely updating the OpenGL |
| implementation. |
| |
| Should the memory allocator functionality be available be a part |
| of the GL or window system dependent (GLX or WGL) APIs? |
| |
| RESOLUTION: The window system dependent API. |
| |
| The memory allocator should be considered a window system/ |
| operating system dependent operation. This also permits |
| memory to be allocated when no OpenGL rendering contexts |
| exist yet. |
| |
| New Procedures and Functions |
| |
| void VertexArrayRangeNV(sizei length, void *pointer) |
| void FlushVertexArrayRangeNV(void) |
| |
| New Tokens |
| |
| Accepted by the <cap> parameter of EnableClientState, |
| DisableClientState, and IsEnabled: |
| |
| VERTEX_ARRAY_RANGE_NV 0x851D |
| |
| Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, |
| GetFloatv, and GetDoublev: |
| |
| VERTEX_ARRAY_RANGE_LENGTH_NV 0x851E |
| VERTEX_ARRAY_RANGE_VALID_NV 0x851F |
| MAX_VERTEX_ARRAY_RANGE_ELEMENT_NV 0x8520 |
| |
| Accepted by the <pname> parameter of GetPointerv: |
| |
| VERTEX_ARRAY_RANGE_POINTER_NV 0x8521 |
| |
| Additions to Chapter 2 of the OpenGL 1.1 Specification (OpenGL Operation) |
| |
| After the discussion of vertex arrays (Section 2.8) add a |
| description of the vertex array range: |
| |
| "The command |
| |
| void VertexArrayRangeNV(sizei length, void *pointer) |
| |
| specifies the current vertex array range. When the vertex array |
| range is enabled and valid, vertex array vertex transfers from within |
| the vertex array range are potentially faster. The vertex array |
| range is a contiguous region of (virtual) address space for placing |
| vertex arrays. The "pointer" parameter is a pointer to the base of |
| the vertex array range. The "length" pointer is the length of the |
| vertex array range in basic machine units (typically unsigned bytes). |
| |
| The vertex array range address space region extends from "pointer" |
| to "pointer + length - 1" inclusive. When specified and enabled, |
| vertex array vertex transfers from within the vertex array range |
| are potentially faster. |
| |
| There is some system burden associated with establishing a vertex |
| array range (typically, the memory range must be locked down). |
| If either the vertex array range pointer or size is set to zero, |
| the previously established vertex array range is released (typically, |
| unlocking the memory). |
| |
| The vertex array range may not be established for operating system |
| dependent reasons, and therefore, not valid. Reasons that a vertex |
| array range cannot be established include spanning different memory |
| types, the memory could not be locked down, alignment restrictions |
| are not met, etc. |
| |
| The vertex array range is enabled or disabled by calling |
| EnableClientState or DisableClientState with the symbolic |
| constant VERTEX_ARRAY_RANGE_NV. |
| |
| The vertex array range is either valid or invalid and this state can |
| be determined by querying VERTEX_ARRAY_RANGE_VALID_NV. The vertex |
| array range is valid when the following conditions are met: |
| |
| o VERTEX_ARRAY_RANGE_NV is enabled. |
| |
| o VERTEX_ARRAY is enabled. |
| |
| o VertexArrayRangeNV has been called with a non-null pointer and |
| non-zero size. |
| |
| o The vertex array range has been established. |
| |
| o An implementation-dependent validity check based on the |
| pointer alignment, size, and underlying memory type of the |
| vertex array range region of memory. |
| |
| o An implementation-dependent validity check based on |
| the current vertex array state including the strides, sizes, |
| types, and pointer alignments (but not pointer value) for |
| currently enabled vertex arrays. |
| |
| o Other implementation-dependent validaity checks based on |
| other OpenGL rendering state. |
| |
| Otherwise, the vertex array range is not valid. If the vertex array |
| range is not valid, vertex array transfers will not be faster. |
| |
| When the vertex array range is valid, ArrayElement commands may |
| generate undefined vertices if and only if any indexed elements of |
| the enabled arrays are not within the vertex array range or if the |
| index is negative or greater or equal to the implementation-dependent |
| value of MAX_VERTEX_ARRAY_RANGE_ELEMENT_NV. If an undefined vertex |
| is generated, an INVALID_OPERATION error may or may not be generated. |
| |
| The vertex array cohenecy model specifies when vertex data must be |
| be extracted from the vertex array memory. When the vertex array |
| range is not valid, (quoting the specification) `Changes made to |
| array data between the execution of Begin and the corresponding |
| execution of End may effect calls to ArrayElement that are made |
| within the same Begin/End period in non-sequential ways. That is, |
| a call to ArrayElement that precedes a change to array data may |
| access the changed data, and a call that follows a change to array |
| data may access the original data.' |
| |
| When the vertex array range is valid, the vertex array coherency |
| model is relaxed so that changes made to array data until the next |
| "vertex array range flush" may affects calls to ArrayElement in |
| non-sequential ways. That is a call to ArrayElement that precedes |
| a change to array data (without an intervening "vertex array range |
| flush") may access the changed data, and a call that follows a change |
| (without an intervening "vertex array range flush") to array data |
| may access original data. |
| |
| A 'vertex array range flush' occurs when one of the following |
| operations occur: |
| |
| o Finish returns. |
| |
| o FlushVertexArrayRangeNV returns. |
| |
| o VertexArrayRangeNV returns. |
| |
| o DisableClientState of VERTEX_ARRAY_RANGE_NV returns. |
| |
| o EnableClientState of VERTEX_ARRAY_RANGE_NV returns. |
| |
| o Another OpenGL context is made current. |
| |
| The client state required to implement the vertex array range |
| consists of an enable bit, a memory pointer, an integer size, |
| and a valid bit. |
| |
| If the memory mapping of pages within the vertex array range changes, |
| using the vertex array range may or may not result in undefined data |
| being fetched from the vertex arrays when the vertex array range is |
| enabled and valid. To ensure that the vertex array range reflects |
| the address space's current state, the application is responsible |
| for calling VertexArrayRange again after any memory mapping changes |
| within the vertex array range."llo |
| |
| Additions to Chapter 5 of the OpenGL 1.1 Specification (Special Functions) |
| |
| Add to the end of Section 5.4 "Display Lists" |
| |
| "VertexArrayRangeNV and FlushVertexArrayRangeNV are not complied |
| into display lists but are executed immediately. |
| |
| If a display list is compiled while VERTEX_ARRAY_RANGE_NV is |
| enabled, the commands ArrayElement, DrawArrays, DrawElements, |
| and DrawRangeElements are accumulated into a display list as |
| if VERTEX_ARRAY_RANGE_NV is disabled." |
| |
| Additions to the WGL interface: |
| |
| "When establishing a vertex array range, certain types of memory |
| may be more efficient than other types of memory. The commands |
| |
| void *wglAllocateMemoryNV(sizei size, |
| float readFrequency, |
| float writeFrequency, |
| float priority) |
| void wglFreeMemoryNV(void *pointer) |
| |
| allocate and free memory that may be more suitable for establishing |
| an efficient vertex array range than memory allocated by other means. |
| The wglAllocateMemoryNV command allocates <size> bytes of contiguous |
| memory. |
| |
| The <readFrequency>, <writeFrequency>, and <priority> parameters are |
| usage hints that the OpenGL implementation can use to determine the |
| best type of memory to allocate. These parameters range from 0.0 |
| to 1.0. A <readFrequency> of 1.0 indicates that the application |
| intends to frequently read the allocated memory; a <readFrequency> |
| of 0.0 indicates that the application will rarely or never read the |
| memory. A <writeFrequency> of 1.0 indicates that the application |
| intends to frequently write the allocated memory; a <writeFrequency> |
| of 0.0 indicates that the application will rarely write the memory. |
| A <priority> parameter of 1.0 indicates that memory type should be |
| the most efficient available memory, even at the expense of (for |
| example) available texture memory; a <priority> of 0.0 indicates that |
| the vertex array range does not require an efficient memory type |
| (for example, so that more efficient memory is available for other |
| purposes such as texture memory). |
| |
| The OpenGL implementation is free to use the <size>, <readFrequency>, |
| <writeFrequency>, and <priority> parameters to determine what memory |
| type should be allocated. The memory types available and how the |
| memory type is determined is implementation dependent (and the |
| implementation is free to ignore any or all of the above parameters). |
| |
| Possible memory types that could be allocated are uncached memory, |
| write-combined memory, graphics hardware memory, etc. The intent |
| of the wglAllocateMemoryNV command is to permit the allocation of |
| memory for efficient vertex array range usage. However, there is |
| no requirement that memory allocated by wglAllocateMemoryNV must be |
| used to allocate memory for vertex array ranges. |
| |
| If the memory cannot be allocated, a NULL pointer is returned (and |
| no OpenGL error is generated). An implementation that does not |
| support this extension's memory allocation interface is free to |
| never allocate memory (always return NULL). |
| |
| The wglFreeMemoryNV command frees memory allocated with |
| wglAllocateMemoryNV. The <pointer> should be a pointer returned by |
| wglAllocateMemoryNV and not previously freed. If a pointer is passed |
| to wglFreeMemoryNV that was not allocated via wglAllocateMemoryNV |
| or was previously freed (without being reallocated), the free is |
| ignored with no error reported. |
| |
| The memory allocated by wglAllocateMemoryNV should be available to |
| all other threads in the address space where the memory is allocated |
| (the memory is not private to a single thread). Any thread in the |
| address space (not simply the thread that allocated the memory) |
| may use wglFreeMemoryNV to free memory allocated by itself or any |
| other thread. |
| |
| Because wglAllocateMemoryNV and wglFreeMemoryNV are not OpenGL |
| rendering commands, these commands do not require a current context. |
| They operate normally even if called within a Begin/End or while |
| compiling a display list." |
| |
| Additions to the GLX Specification |
| |
| Same language as the "Additions to the WGL Specification" section |
| except all references to wglAllocateMemoryNV and wglFreeMemoryNV |
| should be replaced with glXAllocateMemoryNV and glXFreeMemoryNV |
| respectively. |
| |
| Additional language: |
| |
| "OpenGL implementations using GLX indirect rendering should fail |
| to set up the vertex array range (failing to set the vertex array |
| valid bit so the vertex array range functionality is not usable). |
| Additionally, glXAllocateMemoryNV always fails to allocate memory |
| (returns NULL) when used with an indirect rendering context." |
| |
| GLX Protocol |
| |
| None |
| |
| Errors |
| |
| INVALID_OPERATION is generated if VertexArrayRange or |
| FlushVertexArrayRange is called between the execution of Begin |
| and the corresponding execution of End. |
| |
| INVALID_OPERATION may be generated if an undefined vertex is |
| generated. |
| |
| New State |
| |
| Initial |
| Get Value Get Command Type Value Attrib |
| --------- ----------- ---- ------- ------------ |
| VERTEX_ARRAY_RANGE_NV IsEnabled B False vertex-array |
| VERTEX_ARRAY_RANGE_POINTER_NV GetPointerv Z+ 0 vertex-array |
| VERTEX_ARRAY_RANGE_LENGTH_NV GetIntegerv Z+ 0 vertex-array |
| VERTEX_ARRAY_RANGE_VALID_NV GetBooleanv B False vertex-array |
| |
| New Implementation Dependent State |
| |
| Get Value Get Command Type Minimum Value |
| --------- ----------- ----- ------------- |
| MAX_VERTEX_ARRAY_RANGE_ELEMENT_NV GetIntegerv Z+ 65535 |
| |
| NV10 Implementation Details |
| |
| This section describes implementation-defined limits for NV10: |
| |
| The value of MAX_VERTEX_ARRAY_RANGE_ELEMENT_NV is 65535. |
| |
| This section describes bugs in the NV10 vertex array range. These |
| bugs will be fixed in a future hardware release: |
| |
| If VERTEX_ARRAY is enabled with a format of GL_SHORT and the |
| vertex array range is valid, a vertex array vertex with an X, |
| Y, Z, or W coordinate of -32768 is wrongly interpreted as zero. |
| Example: the X,Y coordinate (-32768,-32768) is incorrectly read |
| as (0,0) from the vertex array. |
| |
| If TEXTURE_COORD_ARRAY is enabled with a format of GL_SHORT |
| and the vertex array range is valid, a vertex array texture |
| coord with an S, T, R, or Q coordinate of -32768 is wrongly |
| interpreted as zero. Example: the S,T coordinate (-32768,-32768) |
| is incorrectly read as (0,0) from the texture coord array. |
| |
| This section describes the implementation-dependent validity |
| checks for NV10. |
| |
| o For the NV10 implementation-dependent validity check for the |
| vertex array range region of memory to be true, all of the |
| following must be true: |
| |
| 1. The <pointer> must be 32-byte aligned. |
| |
| 2. The underlying memory types must all be the same (all |
| standard system memory -OR- all AGP memory -OR- all video |
| memory). |
| |
| o For the NV10 implementation-dependent validity check for the |
| vertex array state to be true, all of the following must be |
| true: |
| |
| 1. ( VERTEX_ARRAY must be enabled -AND- |
| The vertex array stride must be less than 256 -AND- |
| ( ( The vertex array type must be FLOAT -AND- |
| The vertex array stride must be a multiple of 4 bytes -AND- |
| The vertex array pointer must be 4-byte aligned -AND- |
| The vertex array size must be 2, 3, or 4 ) -OR- |
| ( The vertex array type must be SHORT -AND- |
| The vertex array stride must be a multiple of 4 bytes -AND- |
| The vertex array pointer must be 4-byte aligned. -AND- |
| The vertex array size must be 2 ) -OR- |
| ( The vertex array type must be SHORT -AND- |
| The vertex array stride must be a multiple of 8 bytes -AND- |
| The vertex array pointer must be 8-byte aligned. -AND- |
| The vertex array size must be 3 or 4 ) ) ) |
| |
| 2. ( NORMAL_ARRAY must be disabled. ) -OR - |
| ( NORMAL_ARRAY must be enabled -AND- |
| The normal array size must be 3 -AND- |
| The normal array stride must be less than 256 -AND- |
| ( ( The normal array type must be FLOAT -AND- |
| The normal array stride must be a multiple of 4 bytes -AND- |
| The normal array pointer must be 4-byte aligned. ) -OR- |
| ( The normal array type must be SHORT -AND- |
| The normal array stride must be a multiple of 8 bytes -AND- |
| The normal array pointer must be 8-byte aligned. ) ) ) |
| |
| 3. ( COLOR_ARRAY must be disabled. ) -OR - |
| ( COLOR_ARRAY must be enabled -AND- |
| The color array type must be FLOAT or UNSIGNED_BYTE -AND- |
| The color array stride must be a multiple of 4 bytes -AND- |
| The color array stride must be less than 256 -AND- |
| The color array pointer must be 4-byte aligned -AND- |
| The color array size must be 3 or 4 ) |
| |
| 4. ( SECONDARY_COLOR_ARRAY must be disabled. ) -OR - |
| ( SECONDARY_COLOR_ARRAY must be enabled -AND- |
| The secondary color array type must be FLOAT or UNSIGNED_BYTE -AND- |
| The secondary color array stride must be a multiple of 4 bytes -AND- |
| The secondary color array stride must be less than 256 -AND- |
| The secondary color array pointer must be 4-byte aligned -AND- |
| The secondary color array size must be 3 or 4 ) |
| |
| 5. For texture units zero and one: |
| |
| ( TEXTURE_COORD_ARRAY must be disabled. ) -OR - |
| ( TEXTURE_COORD_ARRAY must be enabled -AND- |
| The texture coord array stride must be less than 256 -AND- |
| ( ( The texture coord array type must be FLOAT -AND- |
| The texture coord array pointer must be 4-byte aligned. ) |
| The texture coord array stride must be a multiple of 4 bytes -AND- |
| The texture coord array size must be 1, 2, 3, or 4 ) -OR- |
| ( The texture coord array type must be SHORT -AND- |
| The texture coord array pointer must be 4-byte aligned. ) |
| The texture coord array stride must be a multiple of 4 bytes -AND- |
| The texture coord array size must be 1 ) -OR- |
| ( The texture coord array type must be SHORT -AND- |
| The texture coord array pointer must be 4-byte aligned. ) |
| The texture coord array stride must be a multiple of 4 bytes -AND- |
| The texture coord array size must be 2 ) -OR- |
| ( The texture coord array type must be SHORT -AND- |
| The texture coord array pointer must be 8-byte aligned. ) |
| The texture coord array stride must be a multiple of 8 bytes -AND- |
| The texture coord array size must be 3 ) -OR- |
| ( The texture coord array type must be SHORT -AND- |
| The texture coord array pointer must be 8-byte aligned. ) |
| The texture coord array stride must be a multiple of 8 bytes -AND- |
| The texture coord array size must be 4 ) ) ) |
| |
| 6. ( EDGE_FLAG_ARRAY must be disabled. ) |
| |
| 7. ( VERTEX_WEIGHT_ARRAY_NV must be disabled. ) -OR - |
| ( VERTEX_WEIGHT_ARRAY_NV must be enabled. -AND - |
| The vertex weight array type must be FLOAT -AND- |
| The vertex weight array size must be 1 -AND- |
| The vertex weight array stride must be a multiple of 4 bytes -AND- |
| The vertex weight array stride must be less than 256 -AND- |
| The vertex weight array pointer must be 4-byte aligned ) |
| |
| 8. ( FOG_COORDINATE_ARRAY must be disabled. ) -OR - |
| ( FOG_COORDINATE_ARRAY must be enabled -AND- |
| The chip in use must be an NV11 or NV15, not NV10 -AND- |
| The fog coordinate array type must be FLOAT -AND- |
| The fog coordinate array size must be 1 -AND- |
| The fog coordinate array stride must be a multiple of 4 bytes -AND- |
| The fog coordinate array stride must be less than 256 -AND- |
| The fog coordinate array pointer must be 4-byte aligned ) |
| |
| o For the NV10 the implementation-dependent validity check based on |
| other OpenGL rendering state is FALSE if any of the following are true: |
| |
| 1. ( COLOR_LOGIC_OP is enabled -AND- |
| The logic op is not COPY ), except in the case of Quadro2 |
| (Quadro2 Pro, Quadro2 MXR) products. |
| |
| 2. ( LIGHT_MODEL_TWO_SIDE is true. ) |
| |
| 3. Either texture unit is enabled and active with a texture |
| with a non-zero border. |
| |
| 4. VERTEX_PROGRAM_NV is enabled. |
| |
| 5. Several other obscure unspecified reasons. |
| |
| NV20 Implementation Details |
| |
| This section describes implementation-defined limits for NV20: |
| |
| The value of MAX_VERTEX_ARRAY_RANGE_ELEMENT_NV is 1048575. |
| |
| This section describes the implementation-dependent validity |
| checks for NV20. |
| |
| o For the NV20 implementation-dependent validity check for the |
| vertex array range region of memory to be true, all of the |
| following must be true: |
| |
| 1. The <pointer> must be 32-byte aligned. |
| |
| 2. The underlying memory types must all be the same (all |
| standard system memory -OR- all AGP memory -OR- all video |
| memory). |
| |
| o To determine whether the NV20 implementation-dependent validity |
| check for the vertex array state is true, the following algorithm |
| is used: |
| |
| The currently enabled arrays and their pointers, strides, and |
| types are first determined using the value of VERTEX_PROGRAM_NV. |
| If VERTEX_PROGRAM_NV is disabled, the standard GL vertex arrays |
| are used. If VERTEX_PROGRAM_NV is enabled, the vertex attribute |
| arrays take precedence over the standard vertex arrays. The |
| following table, taken from the NV_vertex_program specification, |
| shows the aliasing between the standard and attribute arrays: |
| |
| Vertex |
| Attribute Conventional Conventional |
| Register Per-vertex Conventional Component |
| Number Parameter Per-vertex Parameter Command Mapping |
| --------- --------------- ----------------------------------- ------------ |
| 0 vertex position Vertex x,y,z,w |
| 1 vertex weights VertexWeightEXT w,0,0,1 |
| 2 normal Normal x,y,z,1 |
| 3 primary color Color r,g,b,a |
| 4 secondary color SecondaryColorEXT r,g,b,1 |
| 5 fog coordinate FogCoordEXT fc,0,0,1 |
| 6 - - - |
| 7 - - - |
| 8 texture coord 0 MultiTexCoord(GL_TEXTURE0_ARB, ...) s,t,r,q |
| 9 texture coord 1 MultiTexCoord(GL_TEXTURE1_ARB, ...) s,t,r,q |
| 10 texture coord 2 MultiTexCoord(GL_TEXTURE2_ARB, ...) s,t,r,q |
| 11 texture coord 3 MultiTexCoord(GL_TEXTURE3_ARB, ...) s,t,r,q |
| 12 texture coord 4 MultiTexCoord(GL_TEXTURE4_ARB, ...) s,t,r,q |
| 13 texture coord 5 MultiTexCoord(GL_TEXTURE5_ARB, ...) s,t,r,q |
| 14 texture coord 6 MultiTexCoord(GL_TEXTURE6_ARB, ...) s,t,r,q |
| 15 texture coord 7 MultiTexCoord(GL_TEXTURE7_ARB, ...) s,t,r,q |
| |
| For the validity check to be TRUE, the following must all be |
| true: |
| |
| 1. Vertex attribute 0's array must be enabled. |
| 2. EDGE_FLAG_ARRAY must be disabled. |
| 3. For all enabled arrays, all of the following must be true: |
| - the stride must be less than 256 |
| - the type must be FLOAT, SHORT, or UNSIGNED_BYTE |
| |
| o For the NV20 the implementation-dependent validity check based on |
| other OpenGL rendering state is FALSE only for a few obscure and |
| unspecified reasons. |
| |
| Revision History |
| |
| January 10, 2001 - Added NV20 implementation details. Made several |
| corrections to the NV10 implementation details. Specifically, noted |
| that on the NV11 and NV15 architectures, the fog coordinate array may |
| be used, and updated the section on other state that may cause the |
| vertex array range to be invalid. Only drivers built after this date |
| will support fog coordinate arrays on NV11 and NV15. Also fixed a |
| few typos in the spec. |
| |
| September 17, 2001 - Modified NV20 implementation details to remove |
| all the pointer and stride restrictions, none of which are actually |
| required. Only drivers built after this date will support arbitrary |
| pointer offsets and strides. Also removed NV10 rules on non-zero |
| strides, which cannot be used in OpenGL anyhow, and fixed a few other |
| typos. |
