VAR Memory Benchmark

Last updated November 23, 2001


What it is
VARMemBench is a simple memory benchmark program designed to benchmark AGP and video memory write speeds. This program requires the NVIDIA GL_NV_vertex_array_range extension, which it uses to allocate AGP and video memory. It will only work with video cards that include this extension. Right now, that means it will only work with GeForce series video cards.

If I had time, I'd like to write a DirectX version of this program, as it would work with more video cards. This version of the program uses the NVIDIA OpenGL extension because it is based on benchmark code I've written while working on SMP MiniGL Layer optimization research.

The video memory benchmark capability is useful for seeing how well CPU to AGP writes work on your chipset/video card combination. These writes are not very optimized on some chipsets. If you have AGP Fast Writes enabled, this program provides an easy way to see how well they really work on your system. If you don't have AGP Fast Writes enabled, then it will benchmark PCI mode CPU to AGP transfers when running the video memory benchmark.

Release notes
This benchmark program requires the GL_NV_vertex_array_range extension. Right now, that means it will only work with NVIDIA GeForce series video cards.

The vertex array range extension had some bugs in early driver versions. Running this benchmark on a system with buggy video drivers could cause crashes. I don't know exactly what bugs are present in what drivers versions, but it might not be a good idea to run this benchmark program if you're still running a 5.xx or maybe even a 6.xx video driver version.

The vertex array range extension doesn't provide a way to specifically request AGP or video memory. This benchmark program uses values that work correctly with current video drivers to get these memory types. It is possible that future drivers could return different memory types without this benchmark program knowing about it and displaying an error message. If it returns some results that don't seem right, then it's possible that something like this may have happened.

Download
This package just includes a single executable. No readme.txt is included. This program is a simple command line benchmark program. Just run it from the command line with no commands for usage instructions.

VARMemBench v0.90: VARMemBench090.zip (22 KB).

Benchmarks from my system
Here are the benchmark numbers from my system.
Abit VP6, 2 P3 800EB, PC133, Geforce2 GTS
System memory set speed210 MB/s
AGP memory set speed873 MB/s
PCI mode video memory set speed (no AGP Fast Writes)69 MB/s
The video memory set speed is quite low. It can improved a lot with WPCREdit tweaks, but I still can't get it close to what a BX chipset can do.

Bug when writing to AGP memory from the second CPU on some systems?
If you see any odd looking numbers that are higher than they should be for the AGP memory benchmark on a dual processor system, try running the AGP benchmark again with the -cpu switch to force it to only run on one CPU. Run it on CPU 0 and then on CPU 1 and see if the results are different. On my system, if I run it on CPU 0, I get reasonable numbers. If I run it on CPU 1, I get numbers that are way too high. It turns out that constant writes to AGP memory from CPU 1 will cause the clock on my system to lose ticks. When the benchmark program goes to calculate the transfer rate, the system reports a shorter elapsed time interval than it should because of these lost ticks. This leads to an incorrectly calculated way too high transfer rate.

If you see this happening on your system, send me an email with the details to smpdev@mindspring.com. I'd like to see how widespread this problem might be. I'm running a beta YT BIOS on my VP6, but if this is a BIOS related issue, I have a feeling it isn't specific to this BIOS version. Also, if you see the incorrect numbers, try running the benchmark on the CPU that causes trouble while watching the seconds display on the clock. It should stop ticking (or tick very slowly) and not catch up to the right time when the benchmark finishes. The clock should tick just fine when running the benchmark on the other CPU.

Contact
For this first week or two after this release, I'm interested in receiving benchmark results from various system configurations. I'd like to know the numbers for evaluating optimization strategies for future software I may work on and I'd also like to know them to make sure this benchmark program is working correctly. If you'd like, send in a small benchmark report. If you find any bugs or have any questions or comments about this program, send an email to smpdev@mindspring.com.


Copyright 2001 Chris Dohnal