_mat_

Seems like the RX 470 has very limited shared memory. Try to lower the reduction size.

Nice work, thank you!

Thank you for your kinds words and thanks for the testing. Good to hear that it works for P4s. I like the idea of the unified result file naming and will put it in the next minor release! I am also testing some old graphics cards currently and will add some improvements as well, if possible.

Use GPUPI 3.2 and try other HWiNFO settings in the Settings dialog before the run. Try "Safe Mode" first and disable it if necessary. If the error happens already when you start GPUPI, please post a screenshot. The Legacy version will be slower on new hardware as it can't use that many features due to OpenCL 1.1 compatibility. But on old hardware that shouldn't matter, just use the newest OS and drivers possible for the device.

Actually card #1 and #3 are the problem, card #2 was the most efficient. You have to look at the percentage of batches calculated, #2 did 32% of the whole calculation in about the same time as #1 did only 21%. On the software part, there was only a minor upgrade of the CUDA toolkit between 3.0 and 3.1, so there shouldn't be much difference. I think this is a good case for hardware efficiency through better stability. Well done, H2o! Try GPUPI 3.2 as well, it should have a little less overhead, because it doesn't use a physical log file on a disk anymore. That could scrape off another ms maybe.

I leave that here for anybody that wants to try something hot off the compiler: https://clockers.at/p3880354 Big announcement soon!

Thanks guys, I will look into it!

Crazy good! 1 Minute barrier finally broken, awesome!

The solution for the GTX 980 Ti and similiar problems is easy: Just install the newest GeForce drivers. Old ones are not compatible with the new CUDA toolkit. You will very soon have an extensive debug log on your side to aid you with internal problems of device detection. It will come with GPUPI 3.2. As for old Radeon cards: That depends heavily on your driver situation. If you have an OpenCL 1.2 and higher driver installed on your system, you can use the normal GPUPI version. Otherwise it will give you an error like "cl... function not found in OpenCL.dll". If you have old OpenCL 1.1 drivers, you will need the Legacy version.

No, the GTX 980 Ti is not legacy. It only uses the reduction type "Legacy", that's why it is written in the same line as the reduction size. If your device is capable of "Warp Shuffle" for reductions, the type will state this. Just to clarify: There is no distinct seperation between legacy hardware and modern hardware. GPUPI takes what it gets and uses it to perform the best with it. The Legacy version exists because it is compiled with CUDA 6.5, which is the last CUDA toolkit to support the GTX 200 series cards (Compute Capability 1.3). The normal version is compiled with the latest CUDA toolkit (currently 9.1) which supports Compute Capability 3.0 onwards. So the legacy version has to be used for all GeForce cards between GTX 200 and GTX 500 series. All other cards should use the normal version. As for the GTX 980 Ti not being listed with GPUPI 3, I will look into it.

That's the current change log for GPUPI 3.1.1: Mixed multi GPU calculation CUDA 9.1 support with improved performance for newer graphics cards that support Warp Shuffle Supports Titan V, which is not working with GPUPI 2.3.4. Supports Xeon Phi accelerator cards Hardware detection of clock frequencies and more, that will conveniently be submitted to HWBOT Improved timer detection (EVGA SR-2 fixed, HPET not necessary and approved platforms like Skylake and above) Command line mode via GPUPI-CLI.exe Improved Legacy version for old hardware Encrypted result transaction to HWBOT via https Many many bugfixes and smaller improvements like better device name detection for AMD, HWBOT submission fixes, result file validation fixes, ... So there is much more to it than the EVGA SR-2 timer fix. GPUPI 3 is faster, more convenient for competitive benchmarking and the Legacy version should be more compatible as well. Plus it's more time consuming to maintain two versions of a product. Not only for me but for the moderators as well. So the target is to concentrate on GPUPI 3 and make it better in every aspect. If there are drawbacks for you, just let me know, because there shouldn't be.

It looks like an issue with HWiNFO. I will add a button to disable hardware detection to circumvent problems like this. Things like that happen with low level hardware detection and although I anticipated that, I didn't want to add the possibility for deactivation until a real problem arises. I have a lot of love for old hardware, but it takes some time to trim a new version down to make it working again. I am currently working on GPUPI on a daily basis, that's why there has not been an official annoucement of GPUPI 3. But it's coming and and will be much better than it's predecessors. Until then please grab the hottest GPUPI versions here: GPUPI 3.1.1 | GPUPI 3.1.1 - Legacy Version The new Legacy Version works with Windows XP, supports 32 bit OS and is compatible with old OpenCL 1.1 devices. It was successfully tested with GTX 280, which is the oldest NVIDIA graphics card that supports double precision. Please be aware that you will always need to install the newest OpenCL drivers possible for these old devices. Back then CUDA and OpenCL was horribly bugged and our testing showed that there are situations where you won't be able to produce a valid result due to precision problems in old runtime libraries. The next step will be a native OpenMP API path so you will not need to install OpenCL drivers to benchmark CPUs with GPUPI. It's coming along quite nicely and will support AVX as well. My latest implementation shows that it's also faster than the OpenCL CPU path. On top of that it supports every CPU out there.

The file you need to download is listed as: AMD-SDK-InstallManager-v1.4.87 (1).exe When the installer starts, select "Custom" and check only the "OpenCL Runtime libraries". Follow through with the install. Regarding multiple OpenCL drivers you don't need to worry. The install right next to each other, each runtime will add one ore more OpenCL platforms that you will be able to select in the benchmarks/programs that uses them. But not CineBench, that's OpenGL.

If your CPU is not shown, there is no OpenCL driver installed, that's compatible with your Ryzen. The Catalyst driver for an AMD graphics card would normally install the OpenCL driver for CPU and GPU, but you'll need to plug-in an AMD gpu temporarily to install it. The alternative is the AMD APP SDK, as you already mentioned. It IS available for Windows 10 and installs without a problem for me. Only check the driver, uncheck the rest of SDK: https://developer.amd.com/amd-accelerated-parallel-processing-app-sdk/

That's good to hear. Thank you for your testing!

If the device is not shown, it is a driver issue. The enumeration of devices is a pretty basic thing an relies on what the OpenCL driver returns. Just to be sure: Have you tried Luxmark or other OpenCL applications? Do you have the same problems there?

If you want to test as well, feel free to download GPUPI 3.1 right here: https://www.overclockers.at/downloads/GPUPI%203.1.zip

Thanks to skulstation I could work on a system with the SR-2 today to have a look at the timing issues. I could not reproduce problems with the RTC timer via remote access myself and I am pretty sure that this has nothing to do with already known bclock skewing that impacts the TSC timers. This is something completely different and it skews the RTC on Windows 7 and possibly every other Windows version as well. That means that every benchmark that uses RTC - Aquamark for example - will be impacted by this problem as well, not just GPUPI. As a countermeasure I have implemented a safeguard for GPUPI 3.1 that prohibits the usage of the RTC timer on the SR-2. So you will need to enable the High Precision Event Timer on those systems otherwise GPUPI 3.1 will not let you run the benchmark. skulstation is currently testing the new version as we speak and will report any problems or findings. Let's see if that fixes the issue. If no further problems arise I will release GPUPI 3.1 officially and disable benchmark submission for version 2.3.x and 3.0. As for the other benchmarks like Aquamark, that should be looked at as well. I can compile a list of benchmarks that use the RTC timer, so we can work on that. But let's fix GPUPI first to be sure that the RTC timer is the issue. Afterwards it should be discussed what is going to happen with the current SR-2 runs. If nobody can reproduce a 46 seconds run for GPUPI for CPU 1B with two hexacore Xeons with GPUPI 3.1, I am recommending to delete these scores.

Your HD 4850 should work fine with GPUPI 3.0.1. It supports OpenCL 1.0 and double precision, so it's good to go. If you encounter any problems, please let me know here. Just be aware that GPUPI 3.0 currently works only on 64 bit operating systems and Windows 7 upwards. It should work fine on Vista though, but it's untested yet. For Windows XP support use the Legacy version of GPUPI 2.3.4 (Download it here: https://www.overclockers.at/news/gpupi-international-support-thread). If you need 32 bit support, let me know as well. I can easily build one, although I prefer to phase out 32 bit support if possible. GPUPI 3.0 and all its minor versions are currently allowed for submission. Regarding the results you have posted: Please report them so the moderators can have a look.

That would be very much appreciated! Thank you in advance and please contact me any time on matthias at hwbot.org.

New version with a few bugfixes: GPUPI 3.0.1 Bugfix for the initialization of older opencl devices like HD 7xxx series or Intel Core 2 Duo Update for the integrated HWiNFO library Improved formatting of errors Download

Whatever happens here is impossible to see by just examing the screenshots. The performance is not the issue here, but the timer might be. Those scores were done with the RTC timer, which is currently approved by HWBOT for older Windows versions. It might get skewed due to improper handling on the SR-2 or on every dual-socket board for 1366. As always: If a run takes 4 minutes in real time and is submitted as a sub 1 minute result, it should be reported by the overclocker instead of being submitted. Btw, if this is really a timer issue then I would recommend to remove all dual xeons scores from the bot. Other benchmarks could share the same problems, I can help to point out which ones. But it's too early to say yet, so let's not jump to any conclusions. If anyone could give me remote access to a setup with sr-2, I would very much appreciate it. Any good offers on a cheap sr-2 are welcome as well.

For anybody that's wondering about the version of GPUPI, have a look here: http://forum.hwbot.org/showpost.php?p=501970&postcount=480

If anyone is up for testing a hot of the press GPUPI version, you can download it here: GPUPI 3.0 Supports calculations with mixed APIs like AMD Radeon on OpenCL and NVIDIA on CUDA. Detection of clock frequencies with integrated HWiNFO library. Full support for CUDA 9.1 including various performance improvements! Early support for OpenCL 2.0, currently no changes in performance. CUDA + Titan V is now a full win. Try it and get your gold cup! BIG thx to Joe "the slacker" Steponz for letting me into his rig. Submission to hwbot.org is now encrypted via https. Screenshots are now mandatory to help with the moderation of scores. Improved device detection for AMD Radeon cards by a lot Bugfix for result file validation No HPET timer necessary for approved platforms. That is currently: Skylake, Kaby Lake, Kaby Lake X and Skylake X Memory Reduction greatly optimized for CUDA (uses Warp Shuffling, if available) Added a new Reduction Size: 1024 New settings checkbox: "Run Confirmation" - you can now deliberately enable or disable the message box before each run. Brand new command line mode via GPUPI-CLI.exe Examples: => GPUPI-CLI.exe -h ... Help => GPUPI-CLI.exe -l ... List all available devices => GPUPI-CLI.exe -d 1B -g -a CUDA -b 20M -r 512 ... 1B on all CUDA graphics cards => GPUPI-CLI.exe -d 1B -g -a OpenCL -b 20M -r 512 ... 1B on all OpenCL graphics cards => GPUPI-CLI.exe -d 100M -c -b 10M -r 128 ... 100M on all CPUs and APIs available in the system (can take a while) After some testing it will be officially announced. Early feedback is appreciated though.

Thank you, very much appreciated!