Jump to content
HWBOT Community Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


_mat_ last won the day on October 18

_mat_ had the most liked content!

Community Reputation

378 Excellent

About _mat_

  • Rank
    robo cop
  • Birthday 04/11/1982


  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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, ...).
  4. 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.
  5. You have to download the whole AMD APP SDK from here, see "OpenCL drivers for CPUs": https://www.overclockers.at/news/gpupi-international-support-thread But you will only need to install the OpenCL driver (first entry if I remember), uncheck the rest in the installer.
  6. 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.
  7. What about cutting benches in general only after the season ends? That would hurt a little bit less at least.
  8. 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.
  9. @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.
  10. Using the latest version of BenchMate is recommended though. But doesn't change the validity of the result of course. :)
  11. 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:
  12. 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.
  13. 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.
  14. 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.
  • Create New...