This document contains an explanation of fields in
SPECapcSM/SPECgpcSM Benchmark
Results. Not all benchmarks will include all fields.
Last updated on February 5, 2001 by Bill Licea-Kane.
Benchmark
Version (at top of page)
The version of the SPECapcSM 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's benchmark
for Pro/ENGINEER™ Rev. 20.
Graphics
Hardware Configuration
Graphics
Accelerator
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".
Total
graphics memory [MB]
The physical memory of the graphics accelerator, or, in
unified memory architecture graphics accelerators, the
physical memory statically allocated to the graphics
accelerator. Includes frame buffer memory (color/overlay/underlay/depth/etc),
texture memory (if any), and display list memory (if
any).
Color Depth
[bits]
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.
Overlay
/ Underlay Buffer [bits]
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".
Depth
Buffer Depth [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".
Stencil
Buffer Depth [bits]
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.
Accumulation
Buffer Depth [bits]
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.
Auxiliary
Buffer Depth [bits]
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.
Other
Buffer Depth [bits]
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.
Display
List Memory [MB / VM]
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.
Texture
Memory [MB / VM]
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.
Display
Manuf / Model
This field should indicate the display manufacturer and
model number. Examples might be "HP A4575A".
Display
Resolution [pixels x pixels]
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.
Display
Size/Type [inches / -]
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.
Display
Refresh Rate [Hz]
The display refresh or update rate in Hertz. Typical values
would be "60 Hz", "72 Hz", "75 Hz". Other values are
possible.
Swap
on Vert Retrace
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.
System
Hardware Configuration
CPU Type
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".
Number
of CPUs
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.
Floating
Point
This field should indicate the manufacturer, type of floating
point accelerator chip(s), the frequency of the floating
point accelerator chip(s) used in the system under test.
This field may also indicate that the floating point
accelerator is integrated with the CPU. Typical value
is "integrated." Other values are possible.
Primary
Cache [KB]
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.
Secondary
Cache [KB or MB]
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".
Tertiary
Cache [KB or MB]
This field should indicate the size in kilobytesor 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".
Memory [MB]
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.
Page Size [KB or
MB]
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".
Disk Size [GB]
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".
Disk
Manuf / Model
The original equipment manufacturer (OEM) of the disk
drive and their model number. For example, "Seagate ST34572WS."
Disk RPM [rpm]
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.
Disk
Interface
The interface used to connect the disk to the system.
Examples would include "IDE", "SCSI", "SCSI-II", and "Ultra
SCSI". Other values are possible.
Disk
Controller [optional field]
The manufacturer and model number of the disk controller
card used in the system under test. This is an optional
field.
Software
Configuration
OS
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
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.
API
Vendor / Version
The graphics application programming interface (API) in
use by the benchmark and the supplying vendor.
API
Extensions
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.
Graphics
Driver
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.
Application
Version
Version number of the application under test. Examples
currently include "20" for the Pro/ENGINEER benchmark
or "98Plus" for the SolidWorks benchmark .
Application
Build
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.
Window
Width [pixels]
The width of the main application window, including borders.
Window
Height [pixels]
The height of the main application window, including borders.
Comments
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".
Submittal
Date
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".
Last Updated
The date the submission was last updated. This field is
updated whenever content of the submission is updated,
typically due to a price change. Earlier pages will be
maintained in the result archive. 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".
Status
The status of the page, either "Current" for active results
or "Archived" for pages maintained in the result archive.
Test Date
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".
Submitted
By
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.
Availability
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.
Price [List | Street]
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.
|
