The version of the APC benchmark used to generate these results. Consists of a major and minor number. A difference in major number between results indicates those results are not comparable. An example benchmark version would be "1.1" for the SPECapc Pro/E 20 benchmark.
The manufacturer and model number of the graphics accelerator in use during the benchmark. Any additional information needed to uniquely specify the graphics accelerator configuration should be included here or in the Comments section. As an example, if there are multiple memory configurations for the accelerator, the configuration benchmarked must be uniquely specified with a phrase like "Blammo Graphics Acellomaster 8MB".
The number of bits per pixel in the Frame Buffer Memory that directly determine the pixel color during the benchmark. Common values are "8 bits", "12 bits", "15 bits", "16 bits", "24 bits" and "32 bits". Other values are possible. In case that the Frame Buffer is configured and used by the benchmark in a double-buffered mode, the Color Depth should indicate this. For example, "24 + 24 Bits" would indicate two buffers, each with 24 color bits per pixel.
The number of bits per pixel, used during the benchmark, in the Frame Buffer Memory that are dedicated to the display of information that provides overlays or underlays to the image displayed by the Image Buffer(s). Common values for either parameter are 0 bits, 4 bits and 12 bits. Other values are possible. The field should be formatted as such: "O/U bits" where O is the number of Overlay bits per pixel and U is the number of Underlay bits. For example "8/0 bits".
The number of bits per pixel used during the benchmark to store depth or "Z" values for that pixel. Commonly referred to as "Z-buffer depth". Common values are "16 bits", "24-bits", and "32-bits". Other values are possible. The depth information is typically encoded in a linear fashion using these bits, however it possible to encode the depth in alternate ways. If this encoding has a bearing on the benchmark results and is selectable, it must be specified. An example might be "16 bits logarithmic".
The number of bits per pixel configured during the benchmark for stencil operations. Not all benchmarks will use stencil buffer, but its configuration may have an affect on performance. Common values for this parameter are "0 bits", "4 bits" and "8 bits". Other values are possible.
The number of bits per pixel configured during the benchmark for accumulation operations. Not all benchmarks will use the Accumulation Buffer, but its configuration may have an affect on performance. Common values for this parameter are "32 bits" or "64 bits". Other values are possible. It is possible that this memory is located in virtual memory in which case "VM" should be appended. For example, "64 bits (VM)".
The accumulation buffer can be used for such things as compositing antialiased images or blending images.
The number of bits per pixel configured during the benchmark for auxiliary operations. Not all benchmarks will use the Auxiliary Buffer, but its configuration may have an affect on performance. One common value for this parameter is "36 bits". Other values are possible.
The number of bits per pixel configured during the benchmark run for operations other than described above. Not all benchmarks will use additional buffers, but its configuration may have an affect on performance. Common values for this parameter are "0 bits", "4 bits" and "8 bits". Other values are possible.
This field indicates the amount of memory in megabytes that is dedicated for display list purposes at the time of the benchmark run. On some systems this memory exists on a graphics adapter and may be configurable. Typical values in this case might be "16 MB" or "32 MB". Other values are possible.
In other cases the display list memory resides in the system as virtual memory and may have a size limited only by the limits of the virtual memory subsystem. In this case "VM" should be indicated.
This field indicates the amount of memory in megabytes that is dedicated for texture mapping purposes at the time of the benchmark run. On some systems this memory exists on a graphics adapter and may be configurable. Typical values in this case might be "16 MB" or "32 MB". Other values are possible.
In other cases the display list memory resides in the system as virtual memory and may have a size limited only by the limits of the virtual memory subsystem. In this case "VM" should be indicated.
This field should indicate the display manufacturer and model number. Examples might be "HP A4575A".
This field indicates the horizontal and vertical display resolution, in pixels, during the benchmark run. Typical values are "800 x 600", "1024 x 768", "1280 x 1024", "1152 x 900", "1600 x 1200". Other values are possible. Many of the benchmarks require a specific or minimum display resolution.
This first part field indicates the nominal size of the display, typically measured diagonally in inches. Common values are "15"", "17"", "19"" and "21"". Other values are possible.
The type of display indicates the underlying technology used to display the images. Examples for this portion of the field would be "CRT" for cathode ray tube or "FP" for Flat Panel. Other values are possible.
The display refresh or update rate in Hertz. Typical values would be "60 Hz", "72 Hz", "75 Hz". Other values are possible.
Indicates if graphics buffer swaps are synchronized with the vertical retrace period of the display or not. "Yes" indicates that a graphics buffer swap is only initiated during the vertical retrace period of the display, and "No" indicates the buffer swap can happen at any time.
This field should indicate the manufacturer, type of processor chip(s), and frequency of the processor chip(s) used in the system under test. Submittors must be careful to observe all trademark restrictions in this field. Example values currently include "Intel Pentium III Xeon 550Mhz" or "HP PA-8500 367Mhz".
This field should indicate the number of processor chips physically installed in the system during the benchmark. If the actual number of CPUs enabled during the benchmark differs from this number, this should be described in the Comments section.
This field should indicate the size in kilobytes of the first level of cache memory, sometimes refered to as "Level 1 Cache". An example value for this field would be "16 KB". Other values are possible. Note that some manufacturers specify this first level of cache as "Level 0 Cache".
If there are separate caches for instructions and data this should be indicated. Example values are "16KB/16KB I/D", "32KB/32KB" or "512KB/1024KB". Other values are possible.
This field should indicate the size in kilobytes or megabytes of the second level of cache memory, commonly refered to as "Level 2 Cache" or "L2 Cache". Common values are "128 KB", "512 KB", "1 MB", "2 MB" and "4 MB". Other values are possible. Note that some manufacturers specify this second level of cache as "Level 1 Cache".
If there are separate caches for instruction and data use this should be indicated. Example values are "128 KB / 128 KB I/D".
This field should indicate the size in kilobytes or megabytes of the third level of cache memory. An example might be "1MB". Other values are possible. Note that some manufacturers specify this third level of cache as "Level 2 Cache".
If there are separate caches for instruction and data use this should be indicated. Example values might be "1 MB / 1 MB I/D".
The amount of host memory dedicated to program and data storage configured in the system during the benchmark run. Example values might be "128 MB", "256 MB", "512 MB" and "1024 MB". Other values are possible.
Note that some architectures allow tradeoffs to be made between program/data memory and graphics-related memory. For these systems the value indicated in this field should reflect the memory actually dedicated to program and data storage, which may be less than the total physical memory in the system.
The size in kilobytes or megabytes of the page size in use by the operating system during the benchmark. Typical values include "4 KB", "8 KB", "16 KB". Other values are possible.
Some operating systems support real time page sizing. In this case the value should be "variable".
The size in gigabytes of the configured disk(s) used during the benchmark. Values specified by disk drive maufacturers are acceptable, and are typically rounded to the closest tenth of a gigabyte. Example values are "4.3 GB", "9 GB". In the case where multiple disks were configured during the benchmark run, this should be indicated. For example, "4.3 GB / 9 GB".
The original equipment manufacturer (OEM) of the disk drive and their model number. For example, "Seagate ST34572WS"
The rotational speed of the disk platter(s) in revolutions per minute (rpm). Typical values would include "7200 rpm", and "10,000 rpm". Other values are possible.
The interface used to connect the disk to the system. Examples would include "IDE", "SCSI", "SCSI-II", and "Ultra SCSI". Other values are possible.
The manufacturer and model number of the disk controller card used in the system under test. This is an optional field.
Operating system name and version. The version should be specifed in enough detail to include any service packs, modifications, or patches that would affect performance. Examples might include "HP-UX 10.20" or "Microsoft Windows NT 4.0 SP4"
Window system in use during the benchmark. Example values would be "X Windows" or "Microsoft Windows". Submittors should be careful to observe any trademark restrictions.
The graphics application programming interface (API) in use by the benchmark and the supplying vendor.
A complete list of the graphics API-related extensions in place during the benchmark. Examples include "GL_EXT_polygon_offset" and "GL_EXT_rescale_normal". There are many other legitimate values, including vendor-specific values.
A complete description of the graphics driver used during the benchmark, including any version numbers. This description should be detailed enough to allow a third party to request the correct driver for independent verification of the performance results.
Version number of the application under test. Examples currently include "20" for the Pro/ENGINEER benchmark or "98Plus" for the Solidworks benchmark .
The "Build" or "datecode" of the application used in the benchmark. Many applications have multiple builds for a given version of the application. This field further specifies the exact application revision used for the benchmark.
This field is to be used to capture any additional information about the system under test to allow the benchmark results to be reproduced. Examples would be (a) non-default control panel options, hints, environment or registry variables and their values, (b) graphics card bus type such as PCI or AGP-4X, (c) changes in environment such as "all benchmark tests wer run at the specified screen resolution except test 3 which was run at 1600 x 1200".
The original month and year of this submission. Not to be updated when re-submitted with other submissions at a later date. The month should be the traditional 3 letter abbreviations ("Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec") and the year should include all four digits. Typical values would be "Apr 1999" or "Sep 2000".
The month and year these benchmark results were taken. The month should be the traditional 3 letter abbreviations ("Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec") and the year should include all four digits. Typical values would be "Apr 1999" or "Sep 2000".
The name of the company submitting the results. Typically this is the vendor of the system hardware or graphics hardware, but other submittors are allowed.
The month and year the complete system submitted is generally available to the public. The month should be the traditional 3 letter abbreviations ("Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec") and the year should include all four digits. Typical values would be "Apr 1999" or "Sep 2000". Note that "Now" is not an acceptable value - the earliest date of availability should be used.
The price of the system as tested. The value must be appended with "(List)" or "(Street)" to indicate the type of pricing. Examples would be "$7334 (Street)" or "$13,995 (List)". Prices are usually in US Dollars, although alternate currencies are allowed if clearly indicated. Submissions with alternate currencies will be sorted separately in results summary sheets that are sorted by price or any key involving price.