|
The Application Performance Characterization Project Committee RulesVersion 2.14a Last Updated: 3/30/2012 1. Overview 1. General Philosophy a. All rules declared in "The Graphics and Workstation Performance Group (SPEC/GWPG): Rules For Project Groups" document (known hereafter as the GWPG Project Groups Ruleset) apply, unless specifically overruled by a rule in this document. 2. General Philosophy a. Within SPEC's Graphics and Workstation Performance Group (SPEC/GWPG) there was a strong belief that it is important to benchmark graphics performance based on actual applications. Application-level benchmarks exist, but they are not standardized and they do not cover a wide range of application areas. Thus, the Application Performance Characterization (SPECapcSM) Project was created within the GWPG to create a broad-ranging set of standardized benchmarks for graphics-intensive applications. b. The SPECapc seeks to develop benchmarks for generating accurate application-level graphics performance measures in an open, accessible and well-publicized manner. c. The SPECapc wishes to contribute to the coherence of the field of application performance measurement and evaluation so that vendors will be better able to present well-defined performance measures and customers will be better able to compare and evaluate vendors products and environments. d. The SPECapc will provide formal beta benchmarks to members and final benchmark releases to the public in a timely fashion. e. Hardware and software used to run the SPECapc benchmarks must provide a suitable environment for running typical (not just benchmark) workloads for the applications in question. f. SPECapc reserves the right to adapt its benchmarks as it deems necessary to preserve its goal of fair and useful benchmarking (e.g. remove benchmark, modify benchmark code or data, etc). If a change is made to the suite, SPECapc will notify the appropriate parties (i.e. SPECapc members and users of the benchmark) and SPECapc will re-designate the benchmark by changing its name and/or version. In the case that a benchmark is removed in whole or in part, SPECapc reserves the right to republish in summary form "adapted" results for previously published systems, converted to the new metric. In the case of other changes, such a republication may necessitate re-testing and may require support from the original test sponsor. 3. Overview of Optimizations a. SPECapc is aware of the importance of optimizations in producing the best system performance. SPECapc is also aware that it is sometimes hard to draw an exact line between legitimate optimizations that happen to benefit SPECapc benchmarks and optimizations that specifically target SPECapc benchmarks. However, with the list below, SPECapc wants to increase awareness of implementers and end-users to issues of unwanted benchmark-specific optimizations that would be incompatible with SPECapc's goal of fair benchmarking. b. To ensure that results are relevant to end-users, SPECapc expects that the hardware and software implementations used for running SPECapc benchmarks adhere to a set of general rules for optimizations. 4. General Rules for Optimization a. Optimizations must generate correct images and results for the application under test, for both the benchmark case and similar cases. Correct images and results are those deemed by the majority of the SPECapc electorate, potentially with input from the associated independent software vendor (ISV) and/or end-users, to be sufficiently adherent to the intent behind the application. b. Optimizations must improve performance for a class of workloads where the class of workloads must be larger than a single SPECapc benchmark or SPECapc benchmark suite. c. For any given optimization a system should generate correct images with and without said optimization. An optimization should not reduce system stability. d. The vendor encourages the implementation for general use (not just for running a single SPECapc benchmark or SPECapc benchmark suite). e. The implementation is generally available, documented and supported by the providing vendor. f. In the case where it appears that the above guidelines have not been followed, SPECapc may investigate such a claim and request that the optimization in question (e.g. one using SPECapc benchmark-specific pattern matching) be removed and the results resubmitted. Or, SPECapc may request that the vendor correct the deficiency (e.g. make the optimization more general purpose or correct problems with image generation) before submitting results based on the optimization. g. It is expected that system vendors would endorse the general use of these optimizations by customers who seek to achieve good application performance. h. No pre-computed (e.g. driver-cached) images, geometric data, or state may be substituted within an SPECapc benchmark on the basis of detecting that said benchmark is running (e.g. pattern matching of command stream or recognition of benchmark's name). 2. Benchmarks 1. Benchmark Acceptance a. Benchmark components are defined as i. specific revision of an application, ii. run rules, scripts and associated data sets. b. New or modified benchmark components require a 2/3-majority vote to be accepted for publication. Selection of datecode versions of a specific revision of an application is by majority vote. c. A minimum 3-week review period is required for new or significantly modified benchmark components. d. At the end of the review period a vote will be called to approve the proposed changes. e. An amendment to a benchmark component during the review period must be unanimously accepted. If not, the review period shall be restarted. 2. Benchmark Code Versioning a. Benchmarks use the following version coding: M.m (e.g. SPECapcSM for Pro/ENGINEER 20.0 v1.1) M is the major release number and m is the minor release number. b. The major release number is only incremented when large amounts of code are changed and the scripting language is dramatically changed as a result -- backward compatibility is highly unlikely when moving scripts or data sets between major releases (e.g. running v2 scripts on a v3 executable would almost certainly fail). c. The minor release number is bumped if some small set of code is replaced or removed - but the standard, unchanged scripts and data sets, as a whole, must run on the new version (but perhaps with different performance). d. When there is a new major release of a benchmark, submissions using the previous release will be accepted for at least one submission cycle. When a superceded benchmark is retired, the associated run-rules will be archived in an "archived benchmark run-rules document" posted on the Previous SPECapc Benchmarks web-page. 3. Submission, Review and Publication 1. General Benchmark Run Rules a. The system under test must correctly perform all of the operations being requested by the application during the benchmark. b. No changes to any files associated with the benchmark are permitted excepted as noted in the benchmark-specific rules (section 5 of this document). c. The entire display raster must be available for use by the application being benchmarked. d. It is not permissible to override the intended behavior of the application through any means including, but not limited to, registry settings or environment variables. e. No interaction is allowed with the system under test during the benchmark, unless required by the benchmark. f. The system under test can not skip frames during the benchmark run. g. It is not permissible to change the system configuration during the running of a given benchmark. That is, one can't power off the system, make some changes, then power back on and run the rest of the benchmark. h. Results submitted must be obtained using the scripts, models, and application revisions which are specified for that submission cycle by the SPECapc. i. The color depth used must be at least 24 bits (true color), with at least 8 bits of red, 8 bits of green and 8 bits of blue, unless otherwise specified. j. The display raster resolution must be at least 1280 pixels by 1024 pixels, unless otherwise specified. k. The monitor refresh rate must be at least 75Hz. This requirement does not apply to digital flat panel displays, unless otherwise specified. l. The border width of the windows created during the benchmark shall not exceed 10 pixels, unless otherwise specified. m. The monitor used in the benchmark must support the stated resolution and refresh rate. n. The benchmark must successfully obtain all requested window sizes, with no reduction or clipping of any benchmark-related windows. Windows created by the benchmark must not be obscured on the screen by anything other than other elements created by the benchmark. o. Tests may be run with or without a desktop/window manager if the application allows this, but must be run on some native windowing system. p. It is not permissible to interact with the system under test to infuence the progress of the benchmark during execution. 2. General Submission Content Rules a. The submission upload file structures are defined in the benchmark-specific section below. 3. Submission Process Rules a. The submission file names are detailed below under the benchmark-specific rules. 4. Review Period Rules a. Reviewers will decide if the image quality and results of the submission are sufficiently correct with respect to the intent of the ISV to satisfy the intended end-users' expectations. 4. SPECapc Benchmark Specific Rules and Procedures 1. Pro/ENGINEER Wildfire 2.0 a. The benchmark must be run using build “M160” of Pro/ENGINEER Wildfire 2.0. Submissions may be made with 32-bit or 64-bit versions of M160. However, submissions made with 32-bit Pro/ENGINEER Wildfire 2.0 on Windows XP 64-bit Edition are prohibited. b. The config.pro file must be used as-is and may not be modified or overridden. c. The script files “utilities\runbench.bat” or “utilities/runbench.csh” may be modified as necessary to enable execution of the benchmark on the system being tested. If modified, the modified version must be included in the benchmark submission. d. The submission must contain the “proe_result.txt” file (as generated by the “proescore” program) as well as the corresponding “trail.txt” file generated from running the benchmark. Both of these files may be found in the "results" directory after a successful run of the benchmark. The first section of the “proe_result.txt” file must be edited to reflect the system configuration. e. There must be no license-related warnings in the “trail.txt” file. f.
The directory
structure of the submission must be as follows: g. The submission file must be named company_apc_proewildfire2_vN.zip or company_apc_proewildfire2_vN.tar.z where company is the member company or organization name in lower case and vN is the file version (e.g. “sgi_apc_proewildfire2_v0.tar.z” and “intel_apc_proewildfire2_v0.zip”.) The initial submission is v0. Resubmitted files must have the version number incremented. 2. Solidworks 2007 a. The benchmark must be run using Solidworks2007 service pack 0. b. The application window size must not be changed from its initial size. c. The submission must contain a result.txt file generated by running the benchmark. Its contents are extracted from the file apcresultsN.txt, generated by the benchmark, where N is the number of the benchmark test run. d. The submission will be derived from the best composite generated by the default 5 benchmark runs, as controlled and reported by the benchmark GUI. e. The appearance of the the application's Quick Tips / Dynamic Help box, or other pop-ups that do not dismiss themselves, will cause the benchmark run to be invalid. The benchmark FAQ has information on how to prevent this. f.
The directory structure of the submission must
be as follows: g. The submission file must be named company_apc_sw2007_vN.zip where company is the member company or organization name in lower case and vN is the file version (e.g. ibm_apc_sw2007_v0.zip.) The initial submission is v0. Resubmitted files must have the version number incremented. 3. NewTek Lightwave 3D 9.6 a. The benchmark must be run using NewTek LightWave 3D version 9.6. b. The display raster resultion must be at least 1920 pixels by 1200 pixels, unless the system has an integrated display which cannot achieve this resolution (example: a notebook), in which case the system’s maximum possible resolution must be used. c. Submissions run on Microsoft Windows will be accepted for review. Submissions run on Apple Mac OS X will not be accepted for review at this time. d. The submission must contain the files “result.txt” and “result.xls”. e.
The directory structure of the submission must
be as follows: f. The submission file must be named company_apc_lightwave96_vN.zip where company is the member company or organization name in lower case and vN is the file version (e.g. dell_apc_lightwave96_v0.zip.) The initial submission is v0. Resubmitted files must have the version number incremented. 4. Autodesk Maya 2009 a. The benchmark must be run using Autodesk Maya 2009 Service Pack 1a. b. Systems running 32-bit Microsoft Windows operating systems must be booted with the /3GB flag set. c. The display raster resolution must be at least 1920 pixels by 1200 pixels, unless the system has an integrated display which cannot achieve this resolution (example: a notebook), in which case the system’s maximum possible resolution must be used. d. At this time, submissions run on Microsoft Windows will be accepted for review. e. The submission must contain the files “result.txt” and “result.xls”. f.
The directory structure of the submission must
be as follows: g. The submission file must be named company_apc_maya2009_vN.zip where company is the member company or organization name in lower case and vN is the file version (e.g. dell_apc_lightwave96_v0.zip.) The initial submission is v0. Resubmitted files must have the version number incremented. 5. Autodesk 3ds max 2011 a. The benchmark must be run using Autodesk 3ds Max 2011 with Service Pack 1 (SP1) applied. Do not install the 3ds Max Subscription Advantage Pack, as it will interfere with the operation and results of the benchmark. b. The default 3ds Max 2011 application settings must be used. c. The benchmark may only be run using DirectX. d. For DirectX submissions, an application graphics driver or plug-in may be used, but the images captured from the benchmark must not differ from 3ds max's respective native DirectX driver's images by more than 5%. If the application driver's or plug-in’s images do not match, the submitter may apply for a waiver based on documented errors in the respective 3ds max native driver. The availability and support of an application driver or plug-in shall not affect the submission's “single supplier” or “parts built” status. e. The display resolution must be at least 1920 pixels by 1080 pixels. If the system has an integrated display which cannot achieve 1920x1080 resolution, e.g., a notebook, the system’s maximum possible resolution must be used. f. It is suggested that the 3ds Max 2011 Professional benchmark be run with at least 16GB of RAM installed. It is recommended that the Personal version of the benchmark be run with 8GB of RAM installed. g. The 3ds Max Professional benchmark is only supported on systems running Microsoft Windows Win7 64-bit operating system. h. The 3ds Max Personal version of the benchmark is unsupported, but it is recommended for Win7 32-bit and 64-bit. i. The 3ds Max Personal version requires the 3GB flag for Win7 32-bit. j. Only submissions with the 3ds Max Professional version of the benchmark run on Microsoft Windows Win7-64 operating system will be accepted for review. For submissions, the official run of the benchmark must be executed, which includes 4 iterations of all tests in the benchmark. k. The 3ds Max 2011 window must be maximized, filling the screen. The window must not be occluded by any other windows. Task-bar auto-hide must be enabled. Any windows on top of the application may interfere with the performance. l. The submission must contain the files “results1.xml” through “results4.xml” and specAPC.xlsm. m.
The directory structure of the submission must
be as follows: n. The submission file must be named company_apc_3dsmax2011_vN.zip where company is the member company or organization name in lower case and vN is the file version (e.g. dell_apc_3dsmax2011_v0.zip.) The initial submission is v0. Resubmitted files must have the version number incremented. 6. Siemens PLM NX 6 a. The benchmark must be run using build “Maintenance Release 6.0.5.3” of Siemens PLM NX 6. b. The NX 6 benchmark is only supported on systems running Microsoft Windows 7 64-bit operating system. c. The display resolution must be at least 1920 pixels by 1080 pixels. If the system has an integrated display which cannot achieve 1920x1080 resolution, e.g., a notebook, the system’s maximum possible resolution must be used. d. The batch file run_SPECapcNX6bmk.bat may only be modified to change the location of the benchmark folder. If modified, the modified version must be included in the benchmark submission. e. The NX 6 application window must be maximized and all toolbars, the resource bar, and history resource bar must be turned off. f. The NX 6 “Fixed Frame Rate” setting must be globally disabled. g. The NX 6 "Disable Translucency" setting is optional and must be documented in the Comments field of the "result.txt" file. h. The NX 6 "Disable Plane Translucency", “Backface Culling”, and “Disable Line Antialiasing” settings under Preferences>Visualization Performance>General Graphics must be unchecked. i. All other NX 6 application settings should be default. See the document, SPECapc_NX6_BenchmarkSetup, for the full details of the benchmark setup. j. If the NX 6 graphics visualization registry setting is altered, this must be documented in the Comments field of the "Result.txt" file. k. Submissions run on Microsoft Windows 7 64-bit will be accepted for review. l. The submission must contain the “ResultsSummary.htm”, “Result.txt”, “CompeteStats.csv”, “FinalScores.csv” and timer_data01-05.txt files generated from running the benchmark. These files may be found in the "Results" directory after a successful run of the benchmark. The first section of the “Result.txt” file must be edited to reflect the system configuration or edit the “config.txt” file before the benchmark is run. m.
The directory structure of the submission must
be as follows: n. The submission file must be named company-name_apc_nx6_vN.zip where company-name is the member company or organization name in lower case and vN is the file version (e.g. hp_apc_nx6_v0.zip.) The initial submission is v0. Resubmitted files must have the version number incremented. Adoption |