_mat_

Looks like the same bug that all locked AMD APUs have. The multi is set correctly but the processor chooses to ignore it. Might be a hard bug to catch.

As promised in the announcement of GPUPI 2.1 I have deactivated the manual submission, so from now on it's possible to submit data files.

Be sure to have the screenshot option checked in the submission dialog. You can edit the scores manually any time you want. It will be recalculated afterwards.

That should do it, thanks. I will put it into GPUPI 2.1.1.

OpenCL registers multiple cpus as a single device. Nothing much that can be done about that. Be sure to skip the CPU detection when submitting multi socket scores ... or edit the submission afterwards.

Turrican's choice! Btw, 32B is where the real fun begins with this setup!

Seems to be a problem with the HWBOT sumbission API. I sent a mail out the staff, I am sure we can fix this.

What's the exact displayed name in the device selection tree? With this information I can fix it. Thanks for your report.

Intel's OpenCL driver never supported XP, only Vista and above. And the latest versions will only work on Windows 7/8. There are a few Catalyst drivers for XP that should work. Take a look here (left side, will need a user account). There are also a few old AMD APP SDK versions with XP support, search the web for it. I would suggest to run Windows 7, plugin and AMD card and install the latest Catalyst with OpenCL 2.0 support. It should give you the best scores. Seems like NVIDIA is the only vendor that has their latest drivers XP ready, even though it's inoffical and can not be found on nvidia.com/geforce.com.

Which GeForce driver version did you use? Invalid runs without unstable overclocking are a sign of old buggy drivers.

It will be possible after May the 3rd when manual submission of scores will be disabled.

I am very happy to hear that. Keep pushing it!

Looks very close to my implementation. Thanks mate!

Seems to be a driver bug, maybe the CPU is not supported by the new Intel drivers. You can try older versions like 14.x, but I recommend to benchmark with AMD's OpenCL 2.0 drivers anyway to get the best score. Thanks for noting the CPU detection problem. HWBOT lists this CPU as QX9775, but the hardware device name is X9775 inside the drivers. This incompatibilities happen all the time. I will include a manual override for those CPUs with GPUPI 2.2.

What's the version of the Intel OpenCL driver? Btw, you should try the AMD driver included in the latest catalyst. It should be faster.

Congrats! The bench is not so bad, is it?

Very nice score! 18 cores and 64 bit FTW!

Please describe your problem exactly. We are more than happy to help!

Smart. Well, that all went pretty fast now because of you guys suddenly submitting scores with the new version. That certainly was a big surprise ... in a good way of course, because you just overclocked the launch date! Btw, I've updated HWBOT's internal benchmark version to 2.1 too, so from now on only submissions with 2.1 will be accepted. Automatic submissions with GPUPI 2.0 will fail, but you can still submit the scores manually. As for the new data file saving and uploading: It will start working after the 3rd of May, when manual submission of scores is disabled (as it's said in the annoucement). HWBOT implements it only that way, but it won't matter in a few days anyway.

How did you guys get the download links for GPUPI 2.1? Guessed it? It's officially not released right now, because we are currently discussing the problems with the new 64 bit version and ongoing competitions.

Both parameters adjust the workload to the GPU architecture.

As I am still waiting for HWBOT staff to test the new timing methods, I took the time to implement the promised legacy version of the benchmark. I currently have it running on Windows XP including OpenCL and CUDA support for GeForce 200 series cards. Now I started experimenting with getting rid of the double precision restriction. I already coded some quadruple floating point algorithms, but it's not looking good. 1M is working, but everything higher needs much more precision as I expected. I am still trying to wrap my head around some float128 bit shifting code, that could possibly work. Too early to tell yet. What would be possible is to outsource the double precision math to the CPU. It's not really a big part of the calculation, but it would alter everything that we got today. And it would be much slower for systems with double precision support.

I guess mixing cards is currently on a trial run by the HWBOT staff. It's intriguing but there may be social concerns. Performance and cheating wise it should not be a problem. My suggestion for a rule is, that the fastest card decides the submission category. Therefor it doesn't matter what the other cards are, the result will always be slower or at least equal than with the same cards. The fastest card can easily be determined by the statistics below the result. The automatic submission exactly does that for you. What I don't understand right now is the negative energy focused on the bench by some guys here. If you want it to fail, it's going to happen because it's not about having the bench to be unbreakable by cheaters (and haters), it's about embracing it and working things out. GPUPI adds a lot of new possibilities to the table, we can use/enjoy them, abandon others. But it only works if we do it together.

No benchmark is really safe from cheating currently. You are welcome to add your constructive thought here to this discussion. You're right with the rest ... keep it to yourself.

The fastest one counts. Try to find a loop hole, then we can talk about discontinuance of points.