|
|
|
Benchmarks Used |
|
Today's hardware supplied to the
community is becoming faster and more
powerful than most of us would ever
imagine. Therefore to ensure that
you the reader have no unequivocal doubt
in your mind to what the optimal
performance of the hardware is; we use
some of the best known professional
benchmarks around which truly stretch
these new hardware parts to their
limits.
In order to get the most out of all
reviews we now conduct all
tests in both Microsoft Windows in 64-bit mode
only on the Professional Graphic's
Workstation.
Some benchmarks we use are designed fully to
run on 64 bit platforms and their
results will be completely different to that
of the 32 bit platform benchmark.
Therefore please
take these points into very careful
consideration when comparing results. |
|
Current
Awards |
|
|
|
|
|
Mainboards |
|
Multimedia Single Socket |
|
|
Intel®
DX58SO2 Mainboard |
EDITORS
CHOICE |
|
Intel®
Desktop Board DX79SI (X79
Chipset) |
EDITORS
CHOICE |
|
|
|
|
Workstation Single Socket |
|
|
Supermicro X9SCA Socket 1155
Mainboard |
EDITORS
CHOICE |
|
Supermicro X8SAX Socket 1366
Mainboard |
EDITORS
CHOICE |
|
Intel®
Workstation Board X58BP |
EDITORS
RECOMMENDATION |
|
|
|
|
Server Single Socket |
|
|
Intel® Server Board S1200BT |
EDITORS
RECOMMENDATION |
|
|
|
|
High-End
Workstation Dual Socket |
|
|
Supermicro
X8DA3
|
EDITORS
CHOICE |
|
|
|
|
Mainstream
Workstation Dual Socket |
|
|
Supermicro
X8DAi |
EDITORS
CHOICE |
|
|
|
|
|
|
|
High Performance
Spindle Hard Disc |
|
|
600GB Western Digital
VELOCIRAPTOR® |
EDITORS
CHOICE |
|
|
|
|
High Performance
Spindle Hard Disc |
|
|
Western Digital
RE4 2 TB SATA Hard Drive
(WD2003FYYS) |
EDITORS
CHOICE |
|
|
|
|
Green Spindle
Hard Disc |
|
|
WD 2TB™
|
EDITORS
CHOICE |
|
|
|
|
Media
Green Spindle Hard Disc |
|
|
Western Digital Caviar Green 2
TB SATA Hard Drive (WD20EARS) |
EDITORS
CHOICE |
|
|
|
|
|
|
|
Western Digitals
|
EDITORS
CHOICE |
|
|
|
|
|
|
|
Western Digitals Caviar Green
3TB Hard Drive |
EDITORS
CHOICE |
|
|
|
|
|
|
|
Western
Digital
Sentinel DX4000
Small
Office Storage Server |
EDITORS
CHOICE |
|
|
|
|
|
|
|
High
Performance
|
|
|
Intel® X25-E Extreme SATA
Solid-State Drive |
EDITORS
CHOICE |
|
|
|
|
High
Performance
|
|
|
250GB Intel® Solid-State Drive
510 Series |
EDITORS
CHOICE |
|
Crucial 256GB m4 Series
|
EDITORS
RECOMMENDATION |
|
Crucial 256GB RealSSD C300
|
EDITORS
RECOMMENDATION |
|
Entry Level
Solid State Drive |
|
|
OCZ Agility Series SATA II
2.5" SSD |
EDITORS
RECOMMENDATION |
|
|
|
|
|
|
|
Fusion-io
ioDrive
Duo |
EDITORS
CHOICE |
|
|
|
|
|
Processors |
|
Multimedia -
Extreme Edition |
|
|
Intel® Core™
i7- 990X Extreme Edition
3.46GHz Desktop CPU |
EDITORS
CHOICE |
|
2nd
Generation Intel® Core™ i7
processor 3960X Extreme Edition |
EDITORS
CHOICE |
|
|
|
|
MID Range Performance CPU |
|
|
2nd
Generation Intel® Core™ i7
Processor 2600K
(aka Sandy
Bridge) |
EDITORS
CHOICE |
|
|
|
|
Performance Workstation High-End
CPU |
|
|
X5680 3.33GHz Intel® Xeon®
Processor |
EDITORS
CHOICE |
|
|
|
|
Performance Workstation High-End
Single Socket CPU |
|
|
W3580
3.33GHz Intel® Xeon® Uni-Processor |
EDITORS
CHOICE |
|
|
|
|
Server Single Socket
CPU |
|
|
Intel® Xeon®
Processor E3 Family (1280 -
3.5GHz) |
EDITORS
CHOICE |
|
|
|
|
|
|
|
|
|
|
SPECviewperf® 11 |
What is This Thing Called
"SPECviewperf®"?
SPECviewperf® is a portable OpenGL
performance benchmark program written in
C. It was developed by IBM. Later
updates and significant contributions
were made by SGI, Digital (Compaq, HP),
3Dlabs (Creative Labs) and other
SPECopcSM project group members.
SPECviewperf provides a vast amount of
flexibility in benchmarking OpenGL
performance. Currently, the program runs
on most implementations of UNIX, Windows
XP, Windows 2000, and Linux.
The OpenGL Performance Characterization
(SPECopc) project group endorsed
SPECviewperf as its first OpenGL
benchmark. Performance numbers based on
SPECviewperf were first published in the
Q4 1994 issue of The GPC Quarterly.
SPECopc group member companies have
ported the SPECviewperf code to their
operating systems and window
environments. The SPECopc project group
maintains a single source code version
of the SPECviewperf code that is
available to the public.
Benchmarking with SPECviewperf
SPECviewperf parses command lines and
data files, sets the rendering state,
and converts data sets to a format that
can be traversed using OpenGL rendering
calls. It renders the data set for a
pre-specified amount of time or number
of frames with animation between frames.
Finally, it outputs the results.
SPECviewperf reports performance in
frames per second. Other information
about the system under test -- all the
rendering states, the time to build
display lists (if applicable), and the
data set used -- are also output in a
standardized report.
A "benchmark" using SPECviewperf is
really a single invocation of
SPECviewperf with command-line options
telling the SPECviewperf program which
data set to read in, which texture file
to use, what OpenGL primitive to use to
render the data set, which attributes to
apply and how frequently, whether or not
to use display lists, and so on. One
quickly realizes that there are infinite
numbers of SPECviewperf "benchmarks" (an
infinite number of data sets multiplied
by an almost infinite number of
command-line states).
Real-World Benchmarking
SPECopc project group members recognize
the importance of real-world benchmarks.
From the beginning, the group has sought
benchmarks representative of the OpenGL
rendering portion of independent
software vendor (ISV) applications.
Along these lines, the project group has
come up with what it calls a viewset. A
viewset is a group of individual runs of
SPECviewperf that attempt to
characterize the graphics rendering
portion of an ISV's application.
Viewsets differ from SPECapc benchmarks
in that they exercise only the graphics
functionality of the application. This
enables direct performance comparisons
of graphics hardware. Since SPECviewperf
does not require an application software
license to run, it is accessible to a
wider range of users than SPECapc
benchmarks. It is also easier to use and
runs faster than SPECapc benchmarks.
Viewsets are generally not developed by
the SPECopc project group; they come
from the ISVs themselves. Members of the
SPECopc project group often "sponsor"
the ISV. Sponsorship entails helping the
ISV in several areas, including how to
obtain the SPECviewperf code, how to
convert data sets to a SPECviewperf
format, how to use SPECviewperf, how to
create SPECviewperf tests to
characterize the application, how to
determine weights for each of the
individual SPECviewperf tests based on
application usage, and finally to help
offer the viewset to the SPECopc project
group for consideration as a standard
SPECopc viewset. Any ISV wishing to
develop a viewset should contact gpcopc-info@spec.org.
Current viewsets center on popular
CAD/CAM, visualization and digital
content creation applications, including
CATIA, EnSight, Lightwave, Maya,
Pro/ENGINEER, SolidWorks, UGS NX and
Siemens Teamcenter Visualization Mockup. |
SPECviewperf® 11 Information
The SPECgpcSM project group's
SPECviewperf 11 -- released in late June
2010 -- is totally new graphics
performance evaluation software. Among
the major changes are a new GUI, fully
updated viewsets traced from newer
versions of applications, larger models,
and advanced OpenGL functionality such
as shading and vertex buffer objects
(VBOs).
Since the SPECviewperf source and
binaries have been upgraded to support
changes, no comparisons should be made
between past results and current results
for viewsets running under SPECviewperf
11.
SPECviewperf 11 has the following
minimum requirements:
•OpenGL 1.5 plus extensions
•3GB of installed memory
•6GB available disk space
•1920x1080 screen resolution for
submissions published on the SPEC
website
Beyond the minimum requirements, the
SPECgpc group has the following
recommendations and advice:
•Run SPECviewperf 11 on a graphics card
with at least 512 MB of graphics memory
•For testing on 32-bit Windows systems,
set the "/3GB" flag with appropriately
sized page file
•SPECviewperf 11 will intentionally exit
if system performance is significantly
lower than expected for a 3D
workstation-class system
SPECviewperf 11 has been tested on the
following operating systems (Note:
Submissions for publication on SPEC’s
website must be run on 64-bit operating
systems):
•Microsoft Windows XP (32- and 64-bit)
•Microsoft Windows Vista (32- and
64-bit)
•Microsoft Windows 7 (32- and 64-bit)
•Red Hat Enterprise Linux Workstation
5.4
•SUSE Linux Enterprise Desktop 11 sp1 |
|
SPECviewperf® 11
Viewset Descriptions -
Currently, there are eight standard
SPECopc application viewsets:
|
 |
Lightwave (lightwave-01).
The lightwave-01 viewset was created
from traces of the graphics workloads
generated by the SPECapc for Lightwave
9.6 benchmark.
The models for this viewset range in
size from 2.5- to 6-million vertices,
with heavy use of vertex buffer objects
(VBOs) mixed with immediate mode. GLSL
shaders are used throughout the tests.
Applications represented by the viewset
include 3D character animation,
architectural review, and industrial
design. |
 |
CATIA Viewset (catia-03) The
catia-03 viewset was created from traces
of the graphics workload generated by
the CATIA™ V5 R19 and CATIA V6 R2009
applications from Dassault Systemes.
Three models are measured using various
modes in CATIA. Phil Harris of LionHeart
Solutions, developer of CATBench2003,
supplied SPECgpc with the models used to
measure the CATIA application. The
models are courtesy of CATBench2003 and
CATIA Community.
The models, ranging in size from 6.3- to
25-million vertices, use a variety of
common CATIA graphics modes. Both CATIA
V5 and V6 are represented using fixed
pipeline and ARB vertex and fragment
shaders. |
 |
EnSight Viewset (ensight-04) The
ensight-04 viewset represents
engineering and scientific visualization
workloads created from traces of CEI's
EnSight 8.2 application.
CEI contributed the models and suggested
workloads. Models ranging from 36- to
45-million vertices are included in the
viewset using display list paths through
OpenGL. The last model uses GLSL
shaders.
State changes as made by the application
are included throughout the rendering of
the model, including matrix, material,
light and line-stipple changes. All
state changes are derived from a trace
of the running application. |
 |
Maya Viewset (maya-03) The
maya-03 viewset was created from traces
of the graphics workload generated by
the SPECapc for Maya 2009 benchmark.
The models used in the tests range in
size from 6- to 66-million vertices, and
are tested with and without vertex and
fragment shaders.
State changes such as those executed by
the application -- including matrix,
material, light and line-stipple changes
-- are included throughout the rendering
of the models. All state changes are
derived from a trace of the running
application |
 |
Pro/ENGINEER Viewset (proe-05) The
proe-05 viewset was created from traces
of the graphics workload generated by
the Pro/ENGINEER Wildfire™ 5.0
application from PTC. Model sizes range
from 7- to 13-million vertices.
This viewset includes state changes as
made by the application throughout the
rendering of the model, including
matrix, material, light and line-stipple
changes. All state changes are derived
from a trace of the running application.
|
 |
SolidWorks Viewset (sw-03) The
sw-03 viewset was created from traces of
the graphics workload generated by the
Solidworks 2009 SP2 application from
Dassault Systemes.
Model sizes range from 2- to 20-million
vertices in a variety of commonly used
SolidWorks render modes, including
RealView, which makes use of GLSL
shaders.
State changes as made by the application
are included throughout the rendering of
the model, including matrix, material,
light and line-stipple changes. All
state changes are derived from a trace
of the running application. |
 |
Siemens Teamcenter Visualization Mockup
Viewset (tcvis-02) The tcvis-02
viewset is based on traces of the
Siemens Teamcenter Visualization Mockup
application (also known as VisMockup)
used for visual simulation. Models range
from 10- to 22-million vertices and
incorporate vertex arrays and
fixed-function lighting.
State changes such as those executed by
the application -- including matrix,
material, light and line-stipple changes
-- are included throughout the rendering
of the model. All state changes are
derived from a trace of the running
application. |
 |
Siemens NX (snx-01)
The snx-01 viewset is based on traces of
the Siemens NX 7 application. The traces
represent very large models containing
between 11- and 62-million vertices,
which are rendered in modes available in
Siemens NX 7.
State changes such as those executed by
the application -- including matrix,
material, light and line-stipple changes
-- are included throughout the rendering
of the model. All state changes are
derived from a trace of the running
application. |
Full Screen Anti-Aliasing and How it
is Tested in SPECviewperf 10 - by Allen
Bourgoyne
Below are a few brief snippets from the
full article.
The Full article may be found here.
We strongly advise that you the reader
actually take time in reading this full
and interesting article to gain better
understanding of what is actually being
achieved.
SPECviewperf 10 includes new
functionality to test performance for
full-scene anti-aliasing (FSAA), a
feature of most modern graphics cards.
This document gives a brief description
of FSAA, its benefits and limitations,
and describes how to best interpret the
results provided by SPECviewperf 10.
Interpreting SPECviewperf FSAA
Test Results
SPECviewperf tests FSAA performance by
running its standard test suite several
times, setting the FSAA feature of the
graphics card being tested to all
possible FSAA sample values. If a
graphics card supports up to 16 samples
– supporting 16, 8, 4, and 2 samples –
the test would run five times, running
tests for 16, 8, 4, 2, and no samples.
The test is run with no FSAA enabled so
that a baseline test result can be
produced. The goal of the test is to
determine what performance penalty, if
any, enabling FSAA with a given sample
rate incurs. During the individual
tests, screen shots are captured. This
allows the tester to review the effects
that FSAA is having on the rendered
image. It is important to note that as
FSAA is altering the image, there is no
way to automatically validate pixel
accuracy of the images rendered. It is
up to the tester to evaluate the
individual image captures to determine
if the FSAA-produced images for a given
sample size are visually pleasing to the
user. As mentioned earlier, a subjective
evaluation is necessary as individual
preference for the FSAA results plays a
part with respect to the aesthetic
quality of the images produced.
If the FSAA test produces a score that
is within 10 percent of the non-FSAA
score, under SPECviewperf 10 rules that
score will be considered valid for the
specific sample rate. If a SPECviewperf
test score for a particular test is
20.0, for example, and the same test
score with FSAA enabled with a sample of
8 produces 19.5, the official results
will be listed as 20.0 with FSAA up to a
sample of 8 enabled. Sample rates may
affect individual tests differently with
respect to performance, so each test
will include the best FSAA sample rate
score within the 10-percent threshold.
If no sample rate falls within the
10-percent threshold, the test score
will indicate that no FSAA sample rate
achieved the performance threshold for
this test.
In summary...
Full-scene anti-aliasing can be
implemented in many ways, with varying
results, even within a single graphics
card vendor’s product line. Quality of
images created with FSAA enabled is in
the eyes of the beholder.
With its new testing for FSAA
performance, SPECviewperf 10 relies on
the tester to judge the visual quality
of the image. FSAA performance is
measured by the highest level of
sampling achieved within 10 percent of
the non-FSAA score.
Allen Bourgoyne is the Technical
Marketing Manager for Workstation
Graphics at AMD, and vice chair of the
SPECopc project group.
|
Understanding the Impact of Windows
Vista on SPECviewperf Performance
Measurement - by Ian Willaims
Author’s note: The OpenGL
ARB recently published an article
clarifying the facts concerning OpenGL
and Vista: http://www.opengl.org/pipeline/article/vol003_9/.
The article is a good source for
technical information on how OpenGL is
implemented on Vista, and can be
considered a pre-requisite for this
article.
Windows Vista introduces many major new
features that greatly improve user
experience compared to Windows XP. Some
of these features, however, affect
performance benchmarking. This document
aims to help SPECviewperf users better
understand these features and how they
impact performance measurement.
Inside Aero and DWM
A key feature of Windows Vista is the
Aero user interface. Aero includes
features such as transparent and blended
windows, animated icons, and application
preview. Because Aero is tightly
integrated with the GPU, it is
essentially a complete 3D application in
itself, using much of the GPU’s
capabilities and horsepower. Windows
Vista’s Desktop Window Manager (DWM) is
the underlying architecture and
mechanism that enables Aero’s
capabilities.
Workstations with Windows Vista
pre-installed have the DWM and Aero
enabled by default. The figure below
from the OpenGL ARB article depicts the
OpenGL and DX architectures and how they
layer into the DWM and Aero.
As the diagram shows, in
order to create the composited desktop,
the 3D graphics content of all windows
(OpenGL or DX) passes through the DWM.
This allows the DWM to blend windows
onto other windows and the desktop, as
well as facilitate animated icons and
other features.
Fundamental differences
Windows Vista architecture is
fundamentally different than that for
Windows XP, where the content of all 3D
graphics windows is managed almost
exclusively by the ICD graphics driver
and no Desktop Window Manager exists. In
XP, a 3D window represents a hole in the
desktop as far as the operating system
is concerned. The change in the DWM
architecture between XP and Vista has
two implications when benchmarking
performance using SPECviewperf.
The first implication is that Aero, a 3D
application itself, uses GPU resources
and cycles that compete with those of an
application such as SPECviewperf. Aero’s
design and the architecture of the DWM
tries to minimize this impact as much as
possible, but it cannot mitigate the
potential for resource and cycle
conflict when comparing performance with
benchmarks running on Windows XP.
The second implication arises because
all XP benchmarks are run with what is
frequently referred to as “vsync-disabled.”
This means that the 3D content is being
updated as soon as it is drawn, rather
than waiting for a display blanking
region where the new content can be
updated without yielding a “tear”
arising from seeing one (or more) frames
at once. The vsync-disabled mode is
desirable for SPECviewperf, since the
purpose of the benchmark is to test
graphics performance, and without vsync
disabled the maximum performance would
be the refresh rate of the display.
In Windows Vista, vsync is used with all
applications, since otherwise the
desktop display would tear and that is
unacceptable in terms of user experience
and quality. In situations where a
window’s content is being generated
significantly faster than the refresh
rate of the display, a tear-free update
of the desktop can be achieved in one of
two ways.
The first is to limit the window content
update to that of the monitor refresh.
This forces vsync to stay on all the
time, ensuring that the drawing rate
will not exceed the monitor refresh
rate. The second method is to display
only the last frame created prior to the
blanking region and drop all other
pending frames. This approach has the
advantage that it doesn’t gate the
application drawing; clearly, however,
not all generated frames are displayed.
Windows Vista DWM implements the second
of these two methods.
Because of architectural differences,
simply turning vsync off on Windows
Vista does not have the same effect or
implication as it does on XP. The only
way to ensure that an application
rendering is not gated by the display
refresh rate is to disable the DWM,
which will also turn off the Aero
interface. So when comparing XP and
Vista performance on benchmarks that
render faster than the monitor refresh
rate, it is necessary to turn off the
DWM to ensure an apples-to-apples
comparison.
Representative
benchmarking on Vista
Does this mean benchmarks on Windows
Vista should always run with the DWM
turned off? Absolutely not.
As mentioned earlier, a typical
workstation with Windows Vista
pre-installed is configured to have the
DWM and Aero enabled by default so that
all the new features and quality
adjustments are available. As a result,
adopting a policy of always turning the
DWM and Aero off for benchmarking is not
representative of how typical users
would run applications on Windows Vista,
and is counter to the aims of
SPECviewperf.
Since the impact of the DWM and Aero is
felt only when windows updates are
faster than the display refresh rate, if
the window updates are significantly
slower than the display refresh rate,
the impact of the DWM and Aero is
minimal. Even when the window update
rate is faster than the display refresh
rate, the DWM doesn’t stop the GPU from
creating the rendering content of the
frames; it only drops multiple pending
frames from being displayed. The GPU
workload has already been executed; it
is only the final display of the pixels
that doesn’t occur.
One of the goals of SPECviewperf is to
try to ensure that the workload is
significantly lower than the display
refresh rate, and viewsets are regularly
refreshed to ensure this. It’s not
possible to ensure that this will be the
case at all times, however, since
graphics and GPU development is very
rapid and sometimes individual viewset
subtests will perform faster than the
refresh rate. This is why it’s important
to understand the impact of Vista’s
architecture, and not be tempted into
making invalid comparisons between Vista
and XP benchmarking results.
In summary...
Vista delivers to Windows users a
radical change in features and quality,
which is good for the workstation
industry in general. Inherent in the new
features is an architectural re-design
that has two main implications when
benchmarking on Vista compared with
Windows XP:
1. The impact of the Aero
interface running concurrently with a
benchmarked application; and
2. The impact of the
architectural design of the Desktop
Window Manager in situations when an
application window updates
faster than the display refresh rate.
In order to provide true
apples-to-apples performance comparison
between a specific system configuration
running under Windows XP and the same
configuration running under Windows
Vista, both the DWM and Aero should be
disabled. Unfortunately, this does not
represent the default nor desired user
experience of professional workstation
users running Windows Vista applications
– most users will want the DWM and Aero
turned on. Benchmarking in this case is
perfectly valid, but these results
should not be compared to those
generated while running Windows XP, even
if testing is done with the same
hardware configuration.
Ian
Williams is Senior Applied Engineer at
NVIDIA and chair of the SPECopc project
group, developer of SPECviewperf |
Efficient rendering of geometric data
using OpenGL VBOs in SPECviewperf
Display lists are created by a
program and issued to the OpenGL client.
Ultimately, however, they are processed
by the GPU from a copy stored by the
OpenGL server. This creates a doubling
of data when compared with immediate
mode. It also raises another issue: The
size of the OpenGL server copy of the
display list is not visible to the
OpenGL program. This can cause issues
when memory space is constrained.
As an alternative to display lists,
OpenGL also implements vertex arrays.
These allow vertex and attribute data to
be grouped and treated as a block, which
promotes some of the data transfer
efficiencies afforded by display lists.
Vertex arrays also allow data such as
geometry and color to be interleaved,
which can be convenient when creating
and referencing. Unfortunately, vertex
arrays prohibit assuming that any
individual piece of data will not
change. As a result, when drawing an
object using vertex arrays, the data in
the array must be validated each time it
is referenced. This adds overhead into
data transfer. Vertex arrays do not
suffer, however, from the limitation of
storing two copies of all data.
VBOs are intended to enhance the
capabilities of OpenGL by providing many
of the benefits of immediate mode,
display lists and vertex arrays, while
avoiding some of the limitations. They
allow data to be grouped and stored
efficiently like vertex arrays to
promote efficient data transfer. They
also provide a mechanism for programs to
give hints about data usage patterns so
that OpenGL implementations can make
decisions about the form in which data
should be stored and its location. VBOs
give applications the flexibility to be
able to modify data without causing
overhead in transfer due to validation.
When combined with programmability, VBOs
extend OpenGL’s capabilities into new
areas, such as modifying vertex data
with previously rendered pixel data, and
render to vertex array.
Detailed description of VBOs
The idea behind VBOs is to provide
regions of memory (buffers) accessible
through identifiers. A buffer is made
active through binding, following the
same pattern as other OpenGL entities
such as display lists or textures.
VBOs provide control over the mappings
and unmappings of buffer objects and
define the usage type of the buffers.
This allows graphics drivers to optimize
internal memory management and choose
the best type of memory – such as
cached/uncached system memory or
graphics memory – in which to store the
buffers.
The binding operation converts each
pointer in the client-state function
into offsets relative to the current
bound buffer. As a result, the bind
operation turns a client-state function
into a server-state function. The scope
of data used by client-state functions
is only accessible by the OpenGL client
itself and other OpenGL clients are not
able to access that client’s data.
Because the VBO mechanism changes
client-state functions into server-state
functions, it is now possible to share
VBO data among various clients. As a
result, OpenGL clients are able to bind
common buffers in the same way as
textures or display lists.
The following is an outline of the key
OpenGL calls associated with VBO usage:
-
glBindBuffer: This allows
client-state functions to use
binding buffers instead of working
in absolute memory on the client
side. Binding the buffer #0 switches
off VBO and reverts to the usual
client-state mode with absolute
pointers.
-
glBufferData, glBufferSubData, and
glGetBufferSubData: These functions
control the size of the buffer data,
provide usage hints, and allow
copying to a buffer.
-
glMapBuffer and glUnmapBuffer: These
functions lock and unlock buffers,
allowing data to be loaded into them
or relinquishing control to the
server. A temporary pointer is
returned as an entry to the
beginning of the buffer, which also
maps the buffer into client memory.
OpenGL is responsible for how this
mapping into the client’s absolute
memory occurs. Because of this,
mapping must be done for a short
operation, and the pointer is not
persistent and should be stored for
further use.
VBOs are intended to work with the
following OpenGL target objects:
-
Array buffers (ARRAY_BUFFER): These
buffers contain vertex attributes,
such as vertex coordinates, texture
coordinate data, per vertex-color
data, and normals. They can be
interleaved (using the stride
parameter) or sequential, with one
array after another (write 1,000
vertices, then 1,000 normals, and so
on). glVertexPointer and
glNormalPointer each point to the
appropriate offsets.
-
Element array buffers (ELEMENT_ARRAY_BUFFER):
This type of buffer is used mainly
for the element pointer in
glDraw[Range]Elements(). It contains
only indices of elements.
-
These two targets should be set up
so that the element arrays are
available at the same time as array
buffers in glDraw[Range]Elements().
The targets enable users to switch
among various element buffers while
keeping the same vertex array
buffer. This can be used to
implement LOD and other effects by
changing the elements table while
working on the same database of
vertices.
Further detailed information can be
found here |
|
|
|
SPECapc for 3ds Max™ 2011 |
|
 |
 |
 |
|
SPECapc for 3ds Max™ 2011 is performance evaluation software for systems running Autodesk 3ds Max 2011. It is available as a Professional Version and a Personal Version.
The Professional Version of SPECapc for 3ds Max 2011, available for $495 on this website, contains 58 tests for comprehensive measurement of modeling, interactive graphics, CPU and GPU performance. It includes a 32-million-polygon city scene that is modeled, rendered and displayed in real time, testing the limits of high-end workstations with powerful CPU/GPU combinations.
Licensees of the Professional Version of SPECapc for 3ds Max 2011 can publish benchmark results publicly and submit them for review and possible publication on the SPEC website.
The Personal Version of SPECapc for 3ds Max 2011 is available for $20 on this website. It is an easy-to-use benchmark that generates a single number from a subset of tests in the Professional Version. The Personal Version is designed for those seeking more information about 3ds Max 2011 performance, but who don’t have the need for a comprehensive test suite using large models and do not wish to publish test results.
New features in SPECapc for 3ds Max 2011 include:
- Updated tests based on new functionality in 3ds Max 2011.
- An improved user interface that makes it easier to configure and run tests.
- Increased level of testing for shading and rendering in the Professional Version, including use of the Autodesk Quicksilver engine for accelerated CPU and GPU rendering.
- Automated benchmark results compilation in the Professional Version.
A single score is reported for the Personal Version. Results for the Professional Version are derived by taking the total number of seconds to run each test and nomalizing it based
on a reference machine, in this case a Dell Precision 690 workstation with 2.0-GHz Intel Xeon 5130 processor, 4 x 4GB FB-DIMM DDR2 SDRAM (ECC) memory, NVIDIA Quadra FX 570 graphics card, and 80GB Seagate 7200RPM hard drive. The normalization process
ensures a scoring system where a bigger score is better. Composite
scores for the Professional Version are reported for CPU, GPU and large-model (city scene) performance.
Recommended memory is 16GB for the Professional Version and 8GB for the Personal Version. The Professional Version is supported only on systems running the Microsoft Windows Win7 64-bit operating system. The Personal Version is unsupported, but it is recommended for Win7 32-bit and 64-bit.
More information and downloads
For more information, read the
SPECapc for 3ds Max 2011 FAQs
document or see the
description page on the SPEC
website. To download either version of
the benchmark, visit
http://www.spec.org/benchmarks.html#gpc |
|
 |
 |
|
SPECapc for SolidWorks 2007™ |
|
 |
 |
SPECapc
for SolidWorks 2007™ is designed to
represent a day in the life of a typical
SolidWorks 2007 user. The benchmark was
developed by SolidWorks. It is written
in Visual Basic and C, and runs on
Windows XP 32- and 64-bit platforms. The
benchmark uses different-sized CAD/CAM
solid models, the largest of which is an
engine model with 3.13 million vertices.
Eight tests are included within the
benchmark: I/O-intensive operations,
CPU-intensive operations, and six
different graphics tests. A single
number is derived from a weighted
geometric mean of the normalized score
for all eight tests. Scores are also
reported for each of the eight
individual tests and for the geometric
mean of the six graphics tests. The
reference system for computing the
normalized ratio is a 2.4GHz Intel Xeon,
Intel 860 chipset running Windows XP SP2
with 2GB of PC800 ECC RDRAM, an NVIDIA
QuadroFX 1000 graphics card, and a 40GB
ATA/100 hard drive.
A fully licensed, released version of
SolidWorks 2007 (Service Pack 0) is
required. |
|
MAXON Cinebench 11.5 |
|
 |
|
What is MAXON CINEBENCH?
CINEBENCH is a real-world cross platform
test suite that evaluates your
computer's performance capabilities.
CINEBENCH is based on MAXON's
award-winning animation software CINEMA
4D, which is used extensively by studios
and production houses worldwide for 3D
content creation. MAXON software has
been used in blockbuster movies such as
Spider-Man, Star Wars, The Chronicles of
Narnia and many more. CINEBENCH is
the perfect tool to compare CPU and
graphics performance across various
systems and platforms (Windows and Mac
OS X). And best of all: It's completely
free.
How Does MAXON CINEBENCH Work?
The
test procedure consists of two main
components - the graphics card
performance test and the CPU performance
test.
Main Processor Performance (CPU)
The test scenario uses all of your
system's processing power to render a
photorealistic 3D scene (from the viral
"No
Keyframes"
animation by AixSponza). This scene
makes use of various different
algorithms to stress all available
processor cores. In fact, CINEBENCH
can measure systems with up to 64
processor threads. The test scene
contains approximately 2,000 objects
containing more than 300,000 total
polygons and uses sharp and blurred
reflections, area lights and shadows,
procedural shaders, antialiasing, and
much more. The result is given in points
(pts). The higher the number, the faster
your processor. You
can find more specific technical
information on this on
the tech-page of
CINEBENCH.
Graphics Card Performance (OpenGL)
This procedure uses a complex 3D scene
depicting a car chase (by
renderbaron)
which measures the performance of your
graphics card in OpenGL mode. The
performance depends on various factors,
such as the GPU processor on your
hardware, but also on the drivers used.
The graphics card has to display a huge
amount of geometry (nearly 1 million
polygons) and textures, as well as a
variety of effects, such as
environments, bump maps, transparency,
lighting and more to evaluate the
performance across different disciplines
and give a good average overview of the
capabilities of your graphics hardware.
The result given is measured in frames
per second (fps). The higher the number,
the faster your graphics card. You
can find more specific technical
information on this on
the tech-page of
CINEBENCH |
|
|
|
|
|
SiSoftware Sandra (the System
Analyser, Diagnostic and Reporting
Assistant) is an information & diagnostic utility. It should provide most of the
information (including undocumented) you need to know about your hardware, software and
other devices whether hardware or software.
It works along the lines of other
Windows utilities, however it tries to
go beyond them and show you more of
what's really going on. Giving the user
the ability to draw comparisons at both
a high and low-level. You can get
information about the CPU, chipset,
video adapter, ports, printers, sound
card, memory, network, Windows
internals, AGP, PCI, PCIe, ODBC
Connections, USB2, 1394/Firewire, etc.
Using the latest version
listed
below are just some of the Benchmark
Modules that we use.
-
CPU
Arithmetic Benchmark (MP/MT support)
-
CPU
Multi-Media Benchmark (including MMX,
MMX Enh, 3DNow!, 3DNow! Enh, SSE(2))
(MP/MT support)
-
File
System (Removable, Hard Disks,
Network, RamDrives) Benchmark
-
Memory
Bandwidth Benchmark (MP/MT support)
-
Cache &
Memory Bandwidth Benchmark (MP/MT
support)
|
|
 |
PCMark 7 Tests
PCMark 7 includes a range of tests that
give different views of your system’s
performance. In the Advanced Edition you
can choose which tests to run. The
common use and hardware component tests
are unavailable in the Basic Edition.
Overall system performance is measured
by the PCMark test. This is the only
test that returns an official PCMark
score. The Lightweight test measures the
system capabilities of entry-level
systems and mobility platforms unable to
run the PCMark test, but it does not
generate a PCMark score.
Common use performance is measured by
the scenario tests – Entertainment,
Creativity and Production – each of
which results in a scenario score
Hardware component performance is
measured by the hardware tests –
Computation and Storage – each of which
results in a hardware score.
The PCMark test is a collection of
workloads that measure system
performance during typical desktop
usage. This is the most important test
since it returns the official PCMark
score for your system.
Lightweight test. The Lightweight
test contains a collection of workloads
to measure the performance of systems
unable to run the PCMark test. On
entry-level desktops, tablets and
notebooks, only one application tends to
be in active use at a time and it is
rare to run computationally heavy
applications. The Lightweight test is
ideal for benchmarking systems using the
Windows 7 Starter operating system and
is also compatible with Windows Vista.
At the end of the test your system is
given a Lightweight test score.
Entertainment test. The
Entertainment test is a collection of
workloads that measure system
performance in entertainment scenarios.
Individual workloads include recording,
viewing, streaming and transcoding TV
shows and movies, importing, organizing
and browsing new music and several
gaming related tasks. If the target
system is not capable of running DirectX
10 workloads then those tests are
skipped. At the end of the test your
system is given an Entertainment test
score.
Creativity test. The Creativity
test contains a collection of workloads
to measure the system performance in
typical creativity scenarios. Individual
workloads include viewing, editing,
transcoding and storing photos and
videos. At the end of the test your
system is given a Creativity test score.
Productivity test. The
Productivity test is a collection of
workloads that measure system
performance in typical productivity
scenarios. Individual workloads include
loading web pages and using home office
applications. At the end of the test
your system is given a Productivity test
score.
Computation test. The Computation
test contains a collection of workloads
that isolate the computation performance
of the system. At the end of the test
your system is given a Computation test
score.
Storage test. The Storage test is
a collection of workloads that isolate
the performance of the PC’s storage
system. You can choose to test other
storage devices in addition to the
system drive. At the end of the test
your system is given a Storage test
score. |
|
PCMark 7 includes 7 PC tests for Windows
7, combining more than 25 individual
workloads covering storage, computation,
image and video manipulation, web
browsing and gaming. Specifically
designed to cover the full range of PC
hardware from netbooks and tablets to
notebooks and desktops, PCMark 7 offers
complete PC performance testing for
Windows 7 for home and business use. |
|
|
|
|
