Jump to content
HWBOT Community Forums

_mat_

Members
  • Content Count

    570
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by _mat_

  1. I thought about this long and hard today. I have a vision of course. A vision that came together in the last few years while working on and supporting GPUPI, talking to overclockers, researching benchmark security and breaking every bench out there. So yes, I think that poeple want easier access to benching to get the community growing. They want to trust all posted results, screenshots and system data. I also think that everybody wants more system data, like much more! And I am pretty sure nobody wants to ever fill out a submission form again for ten results in a row. That said I made a decision today. Fulfilling my promises will take more time and I don't think we have that luxury. We need a solution right now. So I am going to take a big shortcut and release the first few versions of BenchMate as a wrapper to HWBOT. Although I disabled a couple of features again, this will be a HUGE step forward in the right direction. I am currently working on integrating HWBOT submissions by result file and online. It shouldn't take too long, so expect a beta version very soon.
  2. @Leeghoofd I am working on it all day currently. Yesterday I made a huge breakthrough that finally made Windows 7 support happen. That took considerably more effort than I ever imagined. There is also a 32 bit version of BenchMate now. Last but not least I implemented a very complex kernel to user-mode communication called "Inverted Call Model". That enables BenchMate to receive any change from within the driver within milliseconds. It also has less impact on performance than querying all process information and states every 500 ms. So, yeah. It's very exhausting work. I need to be really thorough to make this happen the right way, lot of rewriting involved and lots to learn as well. But it is happening, that's for sure. And it's much more than a wrapper. It's a completely new take on the workflow of benchmarking.
  3. I meant of course with a wrapper in place. Or a very good benchmark implementation that securely handles timing and scores. It's just not possible on XP.
  4. To put a lot of unnecessary pressure on myself: I am going to release the first version of my generic wrapper on the 11th of April. Regarding donations/financing, let's talk about that when the first version is out and stable.
  5. I highly doubt that any benchmark on Windows XP can be called secure. XP is not built with security (or stability 😛) in mind, that's why it was nearly impossible for Antivirus tools to secure it. Securing benchmarks with a wrapper uses very similar techniques as Antivirus tools. Protecting processes, detecting changes in the memory of a process, Anti-Debugging measures and so on. With Windows 7 and above Microsoft provides more functionality that can be used to implement these features. On Windows 10 it's even easier. That's not all of course. There is the new driver model since Vista and a multitude of improvements to the kernel that all strengthen the security of the OS. I still think that the efficiency of the bench should decide the OS. That's the natural way of benching. The question is if a recompiled version of SuperPi for example can perform better on the latest Windows versions.
  6. This is normally the solution. As far as I can see on your screenshots you are not installing the AMD OpenCL SDK 2.9.1 or 3.0, but an old legacy AMD display driver. Try this download: https://www.softpedia.com/get/Programming/SDK-DDK/ATI-Stream-SDK.shtml
  7. @Leeghoofd, those are two very different errors. Crashes while saving the result file are hardware detection problems, they have to be looked at from platform to platform and from GPUPI version to GPUPI version. GPUPI 3.2 is less stable than 3.3 in that regard, but that's what newer versions are for I guess. Not getting one loop out of it seems to be a fatal error error during the kernel compilation phase. GPUPI 3.3.3 is more optimized and uses less common functionalities of OpenCL. Some of those seem problematic in combination with certain platforms and drivers. Both problems will be fixed with GPUPI 4 because the hardware detection has been improved (as with every version) and OpenCL will no longer be used for CPUs (so no compilation phase). I will NOT fix any of the GPUPI 3.x versions, they are dead. I can not bugfix two different versions, it is not possible with my already limited time at hand. So all fixes currently go into GPUPI 4, which will be released after BenchMate.
  8. What are the problems you are refering to? Without a detailed description it's difficult to help. As for step by step for Intel CPUs: Download the latest Intel OpenCL runtime: https://registrationcenter.intel.com/en/forms/?productid=3207 Open GPUPI, "Calculate", select your CPU in the latest Intel OpenCL platform you can find in the settings dialog and run. There could be inconveniences regarding your OS timer, where GPUPI states that you can't submit due to possible timer skews. Either enable HPET (GPUPI 3.3 will give you that opportunity by just pressing a button) or run Windows 7 or Windows 10 prior to RS5.
  9. Thanks for the report, will have a look at it as soon as I can. Hope I still have X79.
  10. To circumvent HPET in GPUPI use Windows 7 or GPUPI 3.2 + Windows 10 prior to RS4. RS5 changes the QPC timer frequency to 10 MHz and GPUPI currently can't handle that.
  11. I've looked into R20. Timers have not changed much, it still relies mostly on timeGetTime (uses RTC) and additionally QueryPerformanceCounter (mostly TSC or HPET if manually enabled in OS). I still think that timeGetTime is the primary timer to measure performance as QPC is mostly used for UI dependend stuff internally in Windows while timeGetTime is only used if the developer chooses to do so. Anyways R20 should have the same OS/platform restrictions as R11.5 and R15. Btw timer calls can be easily shown with my TimerBench project (menu Tools => Measure). An advantage of R20 is the missing scriptability. While R15 is scriptable via Coffee script, R20 seems to have no such functionality. Coffee script support is huge vulnerability currently present in R15, an easy one-liner can simply set a new benchmark score. Problematic are the configuration options available to customize the benchmark run in R20. There are a number of options listed in resource/config.txt which can also be applied as a command line argument. I have not figured out yet if changing these values will impact the benchmark score. But it was possible for example to run the test with 128 threads instead of the normally chosen 16 for my 9900K (-200 points) and enable a console: So that should be looked at, but as far as I can see it, R20 might be the better choice in terms of security.
  12. Although that would be perfectly valid as a new rule, it's definitely less fun. Might be even more fun to distribute the global points by cpu architecture.
  13. I only meant the web submission of course. If there is an error while saving the dat file, it's a benchmark issue. marco, thanks for submitting the ticket. Didn't get around to it.
  14. I have the same problem on my dev system as well. It's because the online submisson returns an HTTP error 400 when submitting. It's the same issue as:
  15. The HWBOT data file upload often gives very cryptic error messages when uploading into a wrong category. I am getting similar requests from fellow overclockers all the time, so this is definitely something that needs improvement.
  16. Great work! Bulldozer is as fun as overclocking can get.
  17. The crash during the online submission in GPUPI happens because of this problem: It should be possible to fix it on the bot side of the interface. In any case I have already improved the online submission in GPUPI 4 to avoid crashes like these.
  18. I don't know when it stopped working, but I am getting reports since January that GPUPI crashes when submitting online while data files are working. As websmile was able to submit a result with y-cruncher half an hour ago, I guess the problems are related to a specific combination of OS/hardware. I am currently working with Win10 RS5 + 9900K/Z390 and 2990WX/X399. Both platforms have the same submission problems. Do you have a detailed error log for these HTTP 400 errors? The response body is an HTML error page btw but no specific information on it. I am guessing it is triggered by the web application.
  19. Pushing this. Online submission is not working, guys! @richba5tard
  20. The submission API currently returns a 400 error. No specific error message. Doesn't work with GPUPI, y-cruncher and x265. @richba5tard @Leeghoofd
  21. GPUPI 4 will be equally fast on GPUs, but faster on CPU when using the native path without OpenCL. That's my goal and it's necessary to leave OpenCL behind once and for all. The 3.3 categories should then be renamed to 4.0 (or 3.3+) to host all new GPUPI versions. The whole situation kind of sucks balls, I should have never released 3.3 so early. Would have been better to release the optimizations with GPUPI 4, but we are all smarter afterwards, right?
  22. You misunderstood my past post. With Windows 7 GPUPI is falling back to RTC which is safe on all platforms but the EVGA SR-2 (you will be notified if it's detected). So normally no need for HPET on Windows 7 for GPUPI! On Windows 10 RS4 and before you don't need HPET if you are running Skylake or higher. All other will need HPET because RTC and RDTSC are not safe on Windows 10 Windows 10 RS5 needs HPET enabled on all platforms currently because QPC frequency was changed and GPUPI can't detect it yet!
×
×
  • Create New...