GPUPI 2.1

Only two weeks ago GPUPI 2.0 has been officially announced at HWBOT and already got more than 1000 submissions since then. So we gathered all the feedback and put it into the newest version: GPUPI 2.1 reintroduces the 64 bit executable because it's so much faster with Intel's new OpenCL drivers 15.1. It's strongly advised to use it for your CPU submissions! We also worked hard on a new time measurement to avoid cheating with the famous RTC bug of Windows 8. It's now officially cheat proof on Windows 8 and 10 (see screenshots below). In addition to several bugfixes there is also a brand new Legacy version that works on Windows XP and GeForce 200 graphics cards by making use of the CUDA toolkit 6.0. Yes, we certainly want to see some old hardware benched too! Please make sure to update to the newest version of GPUPI before submitting your next result!

Downloads: GPUPI 2.1.2 (1.06 MB, CRC-32: CB9069F2) | GPUPI 2.1.2 - Legacy Version (Windows XP, GeForce 200 series, 590 KB, CRC-32: 1497D087)

Changelog

• 64 bit version to allow 64 bit hardware and drivers to use their full potential (GPUPI_x64.exe).
• New time measurement using QPC if available and RTC as fallback for Windows 7/XP.
• HWBOT submissions can now be saved as data file to disk and submitted later.
• HWBOT submission supports skipping of CPU/GPU (for detection errors) and allows erroneous submissions to be updated manually when needed. Therefor the pure manual submission of scores will be disabled again, because it's the most secure way.
• Legacy version compiled with Visual Studio 2012 (Update 4) and CUDA toolkit 6.0. It has CUDA and OpenCL support for Windows XP and allows GeForce 200 series cards (CUDA capability 1.3) to run the benchmark. The Legacy version is slower than the default executables and should only be used if necessary!
• Detects ~50 AMD graphics cards now (about 30 more than 2.0) including R9 300 family.
• Automatic window resizing after a benchmark run to avoid cutting off statistics or the result. It's only done if necessary and helps especially multi GPU results.
• Adds a watermark to invalid results to easily distinguish them from successful runs.
• Ctrl+A now selects all text in output window.
• Added support for UNICODE file paths for logging and configuration.
• Hardware detection fixed for Xeon CPUs, AMD HD 7770/7750/7730 and Core 2 Duos/Quads.
• Reduced the executable file sizes by removing unnecessary source code and several dependencies

Tests for the new time measurement

We especially took care of the timing bugs in Windows 8 and 10 but also in Windows 7 in certain cases. GPUPI 2.0 and 1.x used the famous QueryPerformanceCounter to measure the runs. Sadly, we realized that this is a very unreliable timer depending on the system settings and the BIOS configuration. Even the installation of certain drivers can change the way how QPC measures time and whether it's in direct relation to the system bus (BClock) or not. If you are interested in the details, we recommend the excellent article "Windows 8 RTC Bug analyzed and fixed" by HWBOT's Christian Ney and CPU-Z's Frank Delattre.

Windows 8/10

To test Windows 8 and 10 properly we deactivated the High Precision Event Timer (HPET). This can either be done in BIOS (if available) or in the system's command line with full administrator permissions:

Code: SHELL

bcdedit /set useplatformclock no

Afterwards we reboot the system to enable our changes and reboot with a BClock of 103 MHz set in BIOS. The QPC timer is now directly linked to the system bus via DMI. Running GPUPI 2.1 now will still give you a perfectly valid result of 35,7 seconds. But if you lower the BClock, the timing frequency will be lowered too and time in Windows goes slower than it acutally is. With 97 MHz (only 6 MHz less) the same run of GPUPI 2.0 will result in 33.7 seconds. That's 2 seconds less than before. This can also happen in the opposite way with overclocking the system bus and slower results.


As you can see, GPUPI 2.1 will not let you run a test without an active HPET timer. This is necessary because only the high precision timer with the frequency of 14.3 MHz can be trusted. The system timer itself (also called RTC, short for real time clock) is flawed in Windows 8 and higher and will also lead to skewed results when changing the system bus frequency. So the HPET timer has to be activated in BIOS and enabled in Windows. Have a look at our FAQ on how to do this.

Windows 7

With Windows 7 we provide two different timing methods. The more precise HPET timer and a fallback to RTC. We highly recommend to enable the HPET timer anyway to get the best results. Enabling it can be tricky though. Be sure to try first with bcdedit like our FAQ describes in detail:

Code: SHELL

bcdedit /set useplatformclock yes

If it's still not working you might need to install the latest updates. If you are running a 32 bit version of Windows you should have this hotfix installed as well.




Our benchmarks indicate that even Windows 7 can produce invalid results in certain situations. This won't happen with GPUPI 2.1 any more because it automatically falls back to RTC timing which is perfectly fine. With an enabled HPET timer both versions of the benchmark produce valid results.

Windows XP

GPUPI 2.0 did not work on Windows XP due to some problematic dependencies. The "Legacy Version" of GPUPI 2.1 reintroduces Windows XP support for OpenCL that was previously available in GPU 1.x. In addition it's possible to benchmark with CUDA now too by using the older CUDA toolkit version 6.0. We tested the timing issues on both GPUPI versions that worked for Windows XP. GPUPI 1.4.1 uses QPC that relies on the system's reliable ACPI timer at about 3.5 MHz. GPUPI 2.1 will automatically fall back to RTC because it's the safest and most reliable way on XP, where QPC itself is known to have bugs especially with multicore processors depending on the update level of the OS.



We did not find a way to cheat the timer on Windows XP (SP3). All available versions of GPUPI worked fine in our testing, although GPUPI 2.1 "Legacy Version" uses the safest timing method.

» Beitrag diskutieren (0 Kommentare)