|
This document contains an explanation of fields in SPECapcSM/SPECopcSM
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.
|
