ati 9600pro -why only 56 total agp memory

redstar

Distinguished
Aug 31, 2001
263
0
18,790
ati radeon 9600 pro 128 meg 3.6 cat / hyperion 4 in 1 (ver 4.29)
512 ddr 2700 spec system memory
1.3 ghz amd thunderbird a CPU
MSI 3680 (k7t266 pro -r)

before, when i had 4 in 1 drivers not correctly installed..i was showing 0 agp memory (and so man installed the 4 in 1's).

Now both nvidia's agp memory (card independent) and 3d mark 2001 SE show i have 53-56 total agp memory.

3dmark..shows that i do have 128 meg texture memory ..

what am i missing..why only 56 meg total agp memory??

----------

i thought my system crash problems were over when the 4 in 1's properlly installed...and a day of testing yield no lockups.

but now, the lockups are back..more frequent and span over more games.

first time the system has locked up while running 3d mark 2001.

-------
installing old geforce 2 removes problem
as does turning of agp read/write (for a 25% perfomance hit)
 
ok i found out what agp memory is (and its not onboard video memory but system memory)

so my system only uses an additional 56 meg --or does this value automatically fluctuate??
Only thing i know for sure..is if you have 0 meg...then u need to update gart driver (hyperion 4 in 1 for via chipsets)

-------------
"Allocate Memory This extension allows one to allocate either video memory (that which is resident on the card) or AGP memory (system memory that is easily accessed by the bus/card). Video memory, though fast, is a precious resource on any system, and should be used sparingly, and only for static geometry. AGP memory is typically much more plentiful (often many megabytes of memory can be allocated), and it may offer similar if not identical performance to video memory (depending upon the AGP bus speed). To allocate AGP memory or video memory, one must supply the wglAllocateMemoryNV call with the appropriate arguments: Memory Allocated ReadFrequency WriteFrequency Priority AGP Memory [0, .25) [0, .25) (.25, .75] Video Memory [0, .25) [0, .25) (.75, 1] All arguments outside these ranges will yield poor results. For best results, only allocate memory once. If multiple buffers are needed, sum the sizes and allocate one large buffer, then partition it after the allocation. Switching between multiple (separately allocated) buffers is expensive and unnecessary. There is no proxy mechanism to determine the maximize size buffer that can be allocated. If an allocation request cannot be satisfied, wglAllocateMemoryNV will return NULL. ∗Fences are only required in a memory-limited situation, and can be ignored if all arrays for a frame will fit into the buffer allocated.
--------------------------------------------------------------------------------
Page 3
Allocate Fences [optional]Fences are allocated using the same semantics as those of texture objects. A typical allocation is as follows: GLuint fence; glGenFencesNV(1, &fence);Enable Memory Call glVertexArrayRangeNV on the entire allocated memory buffer. Calling it upon a subset of the memory buffer will result in an invalid range, and will not work. Once the range has been defined, enable the extension by calling: glEnableClientState(GL_VERTEX_ARRAY_RANGE_NV); Define Vertex Arrays At this point, one must define the vertex array pointers, just like normal. Use one of the glInterleavedArrays formats, or use glVertexPointer, glNormalPointer, etc. Performance between these two methods will be similar, if not identical. The following restrictions apply to all defined arrays: • strides for defined arrays must be less than 256 • strides must be multiples of 4 • pointers must be 4-byte aligned • must be enabled • must exist entirely within enabled buffer
--------------------------------------------------------------------------------
Page 4
Furthermore, each defined array must fall into one of the following formats: Array Size Type Stride Pointer Alignment Color 3 GL_FLOAT Color 4 GL_FLOAT Color 3 GL_UNSIGNED_BYTE ≠ 0 Color 4 GL_UNSIGNED_BYTE Normal - GL_FLOAT Normal - GL_SHORT Multiple of 8, ≠ 0 8-byte TexCoord 1 GL_SHORT ≠ 0 TexCoord 2 GL_SHORT TexCoord 3 GL_SHORT Multiple of 8, ≠ 0 8-byte TexCoord 4 GL_SHORT 8-byte TexCoord 1,2,3,4 GL_FLOAT Vertex 2 GL_SHORT Vertex 3 GL_SHORT Multiple of 8, ≠ 0 8-byte Vertex 4 GL_SHORT 8-byte Vertex 2,3,4 GL_FLOAT VertexWeight 1 GL_FLOAT The Color formats apply to both glColorPointer and glSecondaryColorPointerEXT. Note that glEdgeFlagPointer, glFogCoordPointerEXT and glIndexPointer are not supported under this extension, and their use will disable it. Finish Fence(s) [optional]In the memory-limited condition, it will be necessary to recycle AGP buffer space. Ideally, we only want to make sure that the GPU has finished up to some point in the OpenGL command stream before the CPU begins filling that memory. The GL_NV_fence extension provides just this sort of fine-grained synchronization. Before reusing buffer space, the fence that was set following its last use must be finished: glFinishFenceNV(fence);
--------------------------------------------------------------------------------
Page 5
Copy Data into Arrays When writing to video memory, only systems that support Fast Writes will get good write performance. When using AGP memory, it is absolutely essential that data be written to the buffer sequentially to maximize memory bandwidth. This is because AGP memory is uncached, and writing sequentially will take full advantage of the write combiners. Additional performance can be obtained by creating two or more partitions within the buffer, then alternately writing between them. This allows the CPU to fill one partition while the other is simultaneously drained by the GPU. If using a single partition (or a small number), ensure that any previous rendering calls are finished with the partition before refilling it. This can be accomplished by using GL_NV_fence as described in this paper. The synchronization provided by the GL_NV_fence extension is significantly finer-grained than that of the glFlushVertexArrayRangeNV() function, and should be preferred. Draw Indexed Primitives For drawing primitives, it’s best, though not essential, to use indexed formats (i.e. glDrawElements, glDrawRangeElements) over non-indexed ones (i.e. glDrawArrays), and to avoid glArrayElement altogether (and do not mix glArrayElement with immediate mode calls – this will certainly yield poor results). Indexed elements not only have the advantage of minimizing bandwidth (only a single index needs to be transferred, not all of a vertex’s data), but the driver can also quickly and easily detect shared vertices. Upon encountering a vertex the first time, it will need to be transformed and potentially lighted. The second time it’s encountered, the index may show up in the vertex cache as being already processed. GeForce products have a vertex cache of 16 entries, although it’s effectively only 10 entries due to pipelining. Cache usage can be maximized by spatially sorting geometry. Long strips are fairly efficient even without the vertex cache, so great pains need not be taken to insure good performance. However, when triangle/quad lists are processed, it is definitely best to render adjacent primitives at the same time, if possible. GeForce products require indices to not exceed 65535. If more indices are necessary, break the object into smaller parts. Set Fence(s) [optional]As soon as a buffer will no longer be referenced by subsequent rendering calls, set a fence. When memory must be reclaimed, these fences can be finished in the order they were set. The following command is used to set a fence: glSetFenceNV(fence, GL_ALL_COMPLETED_NV);
--------------------------------------------------------------------------------
Page 6
Important Caveats for NV_vertex_array_rangeWhen using vertex array range, avoid two-sided lighting, clip planes, logic op or bordered textures, because (depending on the specific hardware) these may disable the extension. The vertex arrays will still reside in uncached memory, yielding much lower performance than had they resided in regular system memory. General avoidance of these modes is advised, since they all trigger some amount of software acceleration. Because the memory allocated by the vertex array range extension is uncached, reading from the buffer will be very, very slow. If an application needs to read the vertex array data (e.g. for collision detection, deformation or animation), it should maintain a second copy of the data in cached system memory. Once the modification is completed, the data should be copied to the vertex array range buffer in large, contiguous blocks. Failure to do this will result in extremely poor performance. Finally, it’s best to tightly pack one’s data in the vertex array range buffer. In other words, don’t include application-specific data - only the vertices, normals, colors, texture coordinates and/or weights that are needed by OpenGL. This not only optimizes memory usage, but also minimizes cache misses when the data is fetched by the GPU. "