Linux Video Card Comparison - October 2000

2D Performance: Xmark Results

We learned a thing or two about 2D benchmarks in our last article. First, we learned that Xmark is particular about using data from v1.3 of x11perf. As we were using v1.5, the 2D benchmarks we posted were incorrect. As it did not change the outcome, we decided to just put the new results in this article rather than updating the previous. This information was relayed by an XFree86 hacker, so we feel pretty confident we've got it right this time.

Xmark is a comprehensive benchmark for X-Windows systems. The process is to run an x11perf benchmark that tests a multitude of separate tests lasting for several hours. In the end, Xmark is used to parse the data into a single score, an Xmark. This is the current standard 2D performance measurement for X-Windows.

One thing of note, the 3dfx cards both caused X to hang while running this benchmark. It is a known bug in XFree86 4.0.1 and will be resolved in XFree86 4.0.2. If you're curious, here is the explanation we received:

Just FYI, what's happening is this. We create a command buffer on the card. It's just a chunk of memory where we write small chunks of data that tell the card what to do. When that buffer fills up we have to wait for the card to execute the stuff in the buffer before we can put more stuff in it.

The problem is that x11perf isn't a usual app. It executes the exact same command over and over. It fills up the buffer with them. We then have to wait for it to drain. Normally that isn't the problem because it is a mix of commands and they take reasonable amounts of time, but when x11perf wants to execute a slow command, it takes too long for the buffer to empty and the driver thinks the board is hung.

The solution is to run the test for a shorter time period (cutting the several hour test in half, roughly). The extra parameters we used were -repeat 2 -time 2.

As in the last article, the NVIDIA cards dominated. After publishing that article, we received an e-mail from the original developer of the Matrox driver. He mentioned that at the time he wrote the driver, 2D support did not utilize any features that would require kernel support, such as AGP and DMA transfers. We have yet to receive confirmation from Matrox, but it appears as if little or no work has been done in this area since the XFree86 release. We hope that Matrox can improve their 2D performance in forthcoming driver releases. Why no AGP/DMA usage in 2D? As these features require kernel support, they must be written for each platform individually. Our guess is that the module was designed to be as fast as possible while maintaining complete portability. Adding support for AGP and DMA is an operating system specific task.