_mat_

Try to use the latest version of HWiNFO on its own. Does that work?

You are trying to submit a 100M score made with a GPU to HWBOT. That's not a valid category, HWBOT only allows 1B and 32B for GPUs to be uploaded. For CPU scores 100M and 1B is available on HWBOT. As for the Intel OpenCL setup, I'm not working for Intel so any bugs you encounter would better fit here: https://forums.intel.com/s/topic/0TO0P000000MWkIWAW/opencl?language=en_US

Well, that sucks. Seems like an error where the rendering got somehow aborted, so it shouldn't give a score. There should be some kind of validation inside the benchmark code to verify that the workload was really done. Thanks for reporting this, @superpatodonaldo.

The textures and models were correctly loaded though. That integrity value is reset on each run.

Well, what happened? Did you cheat or did CINEBENCH return this score? I can see btw that this is not a legit run, because the timers have not been called as often as it should been. timeGetTime() should be invoked about 6 million times.

It seems like the service32.exe or service64.exe does not exist. Check if both files are available in the bin directory of your BenchMate installation. If they are, check which executable files the "BenchMate Security Service (32/64 bit)" services are using. Normally this is pretty fail-safe, because BenchMate deletes these services if an error occurs and reinstalls them. Yes, there is a Trojan in there of course. False positive. What Antivirus software are you using? I have to report this to get it removed.

There is a log file in the log directory of your BenchMate installation called bmservice32.log. Please post its contents. Or you can submit an official bug report from the menu or by launching BugReport.exe.

Not surprising at all. The Windows Kernel Team works constantly to support and optimize all platforms months before they are released (read in a tweet some time ago). It's not always perfect I guess (Ryzen power plan for example), but from my knowledge there are many things to consider for best performance, compatibility and security. As already mentioned the ACPI implementation can be (or sometimes has to be) different like interrupt routing for the CPU and platform devices for example. The choice of timer for the System Interrupt is a part of this as well. And although lots of the ACPI implementation is actually provided by vendors as AML, the OS still has most of the work to do to interpret these correctly. I'm regularly taking a peek at the Linux kernel source code when implementing hardware-based features for my BenchMate kernel driver and well let's say it's a lot to take in. Also love the hate comments from the kernel devs for fking things up that have therefor be fixed in software. Another big thing is the thread scheduler, that is pretty close to the hardware. Optimizations there can lead to improved power efficiency, better latency and of course improved performance. I gather that's why a modern implementation of the scheduler leads to better multithreading performance in benchmarks on the latest platforms. I've also seen many different code paths in the WIN32 API as well, where some lead to a syscall (userland to kernel transition for a hardware-based implementation) while on other platforms that's not necessary. Ok, I'm already rambling. What I'm trying to say is that Windows XP is great for old platforms and/or old benchmarks. It has less overhead than any modern Windows because XP simply has very little security mitigations. It's also a native 32 bit OS, so 32 bit code doesn't have to go through the WOW64 subsystem. And let's not forget that old benchmarks were compiled with the appropriate tools at that time. Two famous examples: SuperPi: Compiled with the Borland C compiler that was especially famous for optimized 32 bit code back then. wPrime: Visual Basic 6 that hasn't even real threading, but uses COM to communicate between multiple spawned processes. The spawning is btw part of the time measured, so this also benches the COM implementation of the OS. I doubt that none of these would be faster on Windows XP if they were compiled for 64 bit, with latest compilers, using modern C++ with cache locality in mind and appropriate threading models (OpenMP, Intel's TBB, ...).

Sadly that's not the case. They have the same encryption key setup when it was split into the separate 3.3 categories. GPUPI 3.3 was meant to be the successor of GPUPI 3.2, not its own category. But the bot decided differently. I regret to ever having released 3.3 in the first place. It's best to just use BenchMate and submit it automatically from the application. It will end up in the correct category, no hassles. Btw, you can run BenchMate from your USB stick and submit on another PC.

Just as I expected. The bigger reductions use lots of local shared memory that smaller GPUs normally can't handle. The kernel should actually fail but it seems like the Intel driver just returns nonsense. Maybe I can check if there is enough memory available beforehand to avoid the confusing error that GPUPI gives. That should be reserved for stability issues. Thanks for your feedback! I won't be touching the old ATI Stream stuff with a stick. I've worked with it many years ago and it's really really buggy and also very slow. Maybe it was just me, but I thought that GPUPI won't be possible at that time and gave up. As for DirectX and OpenGL compute shaders, that would be a possible way to enable support for these two iGPUs. I've put it on my list, right below Vulkan compute support, which is something I wanted to look into for some time now.

What about cutting benches in general only after the season ends? That would hurt a little bit less at least.

We could do that and have another benchmark that can't be used on Windows 10 on AMD and Pre-Skylake. I'd rather not reward the "legal action threatening, not caring about the community and oblivious to obvious timer problems" behaviour shown by Geekbench's developer. We should really focus on benchmarks made by developers that give a fuck about overclocking. We will definitely not run out of benchmarks too soon.

@laine, thank you for reporting these problems. 32M on Intel iGPU: Have you tried smaller batch sizes? More than 500 MB of system memory might be more than Intel's OpenCL implementation can handle. It might be a driver problem as well, I will look into it. The Intel GPU OpenCL drivers are a bit nasty. 500M results: This is not caused by system instability, but rather a bug in GPUPI. The validation seems to be messed for some reason. Please use 100M or 1B, they should work fine.

Using the latest version of BenchMate is recommended though. But doesn't change the validity of the result of course. :)

Thanks, I've fixed it and it shows up in the right category now. I wouldn't bench it though, I am going to remove the Geekbench 5 categories as soon as BenchMate 0.10 is released. You can find more information about our great history with Geekbench here:

That's already implemented with version 0.9.x. You can verify that there has been no changes of resources that are used by CINEBENCH by having a look at the "Textures/Models" row in the result dialog. 196...073 is correct for R15. If one bit is out of order there would be a different number. BenchMate 0.10 improves this feature by showing an invalid score when the Textures/Models file integrity hash is out of order. That's not really good practice because I'd rather like to check these values based on the benchmark version that's used, but that would need to be implemented on the server-side (HWBOT). That will take some time as you know. Step by step. @mikebik The score looks good now. Be sure that the result dialog is on the screenshot. That's the best we can do right now without direct submission to the appropriate categories. As leeghoofd said this is in the works with the devs of HWBOT.

Great to hear that it works now.

I guess that's due to your Windows install not allowing a driver not signed by Microsoft. You can either enable test signing (bcdedit /set testsigning on + reboot) or wait for BenchMate 0.10, which has the driver signed appropriately. But if you drop a quick bug report, I can check for sure and get back to you.

You are right, these scores were not made with BenchMate. I can't even see it open in the taskbar. @mikebik What happened here? Would like to get your feedback to make BenchMate more user-friendly. It should be as intuitive as possible.

The rules are pretty clear on the topic. Use Windows 7 or lower or your benchmark can't receive any points. BenchMate is the solution we are working on so users like yourself can bench with Windows 10. It's an uphill battle but we're getting there! BenchMate 0.10 will be released in the next few days and will feature new benchmarks, lots of bugfixes, some built-in tweaks and other options as well as an auto-updater to painlessly introduce new updates and additional benchmarks in the future. As for your reported posts: Please use the "Report Submission" button on the score page's top right, so a moderator will have a look at them.

I wanted to upload them on my site for quite a while, so I've finally done that. You can find everything you need here: https://www.overclockers.at/news/gpupi-international-support-thread

@ADVenturePO Your error states that you don't have any OpenCL installations available, that support OpenCL 2.0. That's normally only the case if you have a very old setup (not your problem) or only an old OpenCL version available like the preinstalled one in Windows. So the solution to your problem is to install the appropriate CPU OpenCL driver from AMD. They are not installed with the graphics card driver, these are separate from the Adrenalin drivers for example. As @StingerYar stated, you should use the AMD APP SDK in its latest version. You can try older AMD APP SDK versions as well, they might give better performance (APP SDK 2.9 provides you with OpenCL 1.2 support which might be faster). Btw, it's good to know that you can install as many OpenCL versions in parallel as you want. Each one of them should show up in GPUPI. @StingerYar This sounds like a bug with the GPU drivers. They should install their OpenCL GPU version next to any other OpenCL versions, but it seems like they do not. Check the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors It should list all available OpenCLL DLLs on the system. It might be possible that the name of GPU version is the same as the CPU version. In that case add the full path to the AMD APP SDK version to this list. Last but not least, this is not a VC Redistributable problem! This would be something in the line of "msvcr140.dll is missing". GPUPI 4 will come with VC compiled inside. This is actually not prefered by Microsoft, but they don't seem to be capable to do this right, so I don't have any other choice as it makes my products suck more. My latest works like BenchMate are already compiled with the VC runtime inside, hence their huge executable sizes.

Without any arguments your feedback is useless. Not sorry. You are welcome to add some constructive feedback though, it might change things for the better in the future.

As the new 3DMarks are separated in workloads, where each test and sometimes subtest got their own executable, it's necessary to check the LOD Bias setting via NVAPI before (or during) each run inside the workload executable. You can't change it in between as far as I'm aware. As soon as the executable is loaded, the NVIDIA driver settings seem to be locked it. There might be some way with releasing and reinitializing the necessary Direct3D interfaces, but that would be a lot of work. And as soon as you can do something like that, it's a lot easier to just piggyback the settings of the workload, a plain JSON passed to the workload executable as a "locked" file. That was the only way I've found to fuck with LOD in the new 3DMarks. To say something ontopic as well: It has to be considered, that points in Port Royale are currently rather expensive. I heard that @Splave sold a testicle to compete with the YouTubers. They now call him the Lance Armstrong of overclocking, cause he's still going strong with one nut. Might be an urban legend though.

ColdbugMate for GPUs incoming?