_mat_

Not really, but welcome to the endless battle. And your application can still be hooked on every API call, starting with DeviceIoControl to feed you whatever as values you need to rely on. It's not a single feature to do things right, it's a strategy that begins with the first line of code and never ends. I helped you for the sake of the countless hours of work from this community that went into Geekbench records. I think my duty here is done.

Probably not in the HWBOT database, but it's listed correct on the screenshot.

Just ignore the 2nd bullet point with the benchmark/platform matrix IF you are using BenchMate, Windows 7 or Intel Skylake+. If you are using Intel before Skylake on Windows 8/10 without BenchMate, you need to check the matrix. Only certain benchmarks are valid in this combination.

Yes, sure. It has also been added to the rules. It's either BenchMate, Windows 7 or HPET system-wide enabled (if the benchmark uses QPC) for all platforms that suffer the APIC timer bclock bug (Intel Pre-Skylake, AMD).

I was short on time the last two days, but did get around to it now. I tested two scenarios: Core i9-10980XE + hooking WIN32 API functions and skewing the timestamps Normal score: https://browser.geekbench.com/geekbench3/8847332 Cheated by 50% skew: https://browser.geekbench.com/geekbench3/8847337 Cheated by 99% skew: https://browser.geekbench.com/geekbench3/8847336 Ryzen 2700X + bclock skewing Normal score: https://browser.geekbench.com/geekbench3/8847338 Bclock reduced by ~2 MHz: https://browser.geekbench.com/geekbench3/8847339 Both scenarios were successfully detected as invalid, so that's a good step forward in the right direction. As you are reluctant to answer any of my questions, I'm not able to effectively test any edge cases. If you are only using HPET via the CPU-Z SDK (my guess), there will be a number of other problems. For example disabling HPET in BIOS or switching HPET modes/setting the timestamp on-the-fly, HPET timestamp overflow, ... It's an endless battle, that would need a combined effort to solve it for overclocking/benchmarking in general. But I guess I'm utterly alone with that vision and it's still every man for himself out there.

Pre-Skylake is necessary to test this thoroughly otherwise there are two different clock domains for PCI/APIC/.. and CPU/... This is a theoretical assumption of course, non-K SKUs of certain generations and modded H-mainboards might give positive results for APIC PM timer skewing as well. Regarding the testing in general: We need to know what to test, blind testing is ineffective. A change log for the new timer validation or at least the strategy you are trying here would be necessary.

That's exactly the problem, the GPU driver overwrites these entries. It boggles my mind why AMD would do anything like that. Shows how much they care about their OpenCL CPU implementation. ?

I read your post to quickly, sorry. This seems to be the AMD driver bug where the GPU driver overwrites the registry entries that the AMD APP SDK previously added. Have a look at the following post at the answer to StingerYar:

The log says you should have the APU as "gfx902" in the "OpenCL GPU devices" node in the settings dialog. Is that not the case?

There is a log file called GPUPI.log. Can you upload it here?

BenchMate disables GPUPI's HWiNFO capability because they can't run next to each other and there also no need to measure the same data twice. So that is not an error, it's as intended. What's the exact problem?

You don't need it, BenchMate detects the hardware and sensor data during the run. And don't submit anything with GPUPI, do it with BenchMate => Save Result.

If you are having trouble with BenchMate crashes due to HWiNFO, you can try to enable or disable the "High Definition Audio" setting in BIOS. I've already worked on a fix with Martin from HWiNFO and it will ship with BenchMate 0.11.

I doubt it will work with an old version, nothing has been changed in this regard. Can you download HWiNFO and enable the debug mode there to acquire a HWiNFO.DBG file and upload it here? Your bug report sadly didn't upload this file. Here's a how-to to get the debug file: https://www.hwinfo.com/forum/threads/read-this-before-submitting-a-report.241/

This is out of our control and will always be. We have to focus on the things we can control. Also there will always be the issues of the faulty CPUs/OS versions in between. More confusion to add to the whole disaster, great. Anyways, BenchMate will go its way, with our without Geekbench. This can be much bigger than a single bench, no doubt about that.

I opened it and clicked the benchmark button. Changed bclock multiple times, reran the bench each time.

I got around to test the new version. Ryzen 2700X, Windows 10 Bclock 104 MHz, 3744 MHz Mem: 3198 MHz Score: https://browser.geekbench.com/geekbench3/8844471 SC 3830 MC 30513 __________________________________________ Bclock 100 MHz, 3750 MHz Mem: 3065 MHz Score: https://browser.geekbench.com/geekbench3/8844479 SC 3961 MC 30575 My conclusions: APIC Timer drift still skews the score. This is also true for all Intel CPUs below Skylake. Neither CPU nor memory frequency is detected correctly. <inserttoolhere> will get you a world record on air by hijacking API calls.

How?

12s barrier broken by almost half a second! Fuck yeah!

I appreciate the update as well. A benchmark developer showing interest to work together with HWBOT and the overclocking community should always be appreciated. In my opinion it's an absolute necessity to cooperate to be able to keep the benchmark in the ranks long-term. May I ask what the specific changes are? It is impossible to do this in userland applications. Timers can not be verified correctly by using WIN32 API functions alone, direct access to hardware devices is needed (a kernel driver). The only workaround is to enforce HPET system-wide like I introduced with GPUPI years ago when I had no other solution. I doubt that this is the right way for Geekbench as a mainstream benchmark. And even if a userland solution is found, 30 seconds with Cheat Engine are enough to change the timers to your liking. I've been there and if you think this through this is not the way to go with competitive benchmarks. My recommendation is to integrate Geekbench into BenchMate again, which solves all problems at once. I'm up for it, because in the end it's the best for overclocking and the community to not remove points from Geekbench if not necessary.

Looks like a HWiNFO issue to me. Can you submit a bug report, I will forward it to the HWiNFO dev so he can fix it?

Yes, this sadly happens, otherwise I would certainly ship HWiNFO with BenchMate. I have talked to Martin (HWiNFO's dev) about that and we are trying to figure out a way to solve the problems with mixing and matching different versions of HWiNFO.

Thanks, very much appreciated. BenchMate itself is not doing anything nasty, I was very careful with direct hardware access. My guess is that HWiNFO is intervening with the SMBus communication of EleetX. This should only be a problem during the benchmark run though, because otherwise HWiNFO is not doing anything after successful startup.

That's exactly why a screenshot can't be the future of benchmarking. There are many ways to get a score like that, I came up with four very different approaches to fake a screenshot for CINEBENCH. And I'm not counting mspaint.

Looks legit.