Jump to content
HWBOT Community Forums

_mat_

Members
  • Posts

    1003
  • Joined

  • Last visited

  • Days Won

    41

Posts posted by _mat_

  1. Casanova, this is in no way intended and should not be the message taken away from my post.

    The truth is that I have been researching on timers and benchmark security in general for quite some time now and found multiple issues. The issue shown in the video is just one of those, although it's a pretty tough one. It's important to know that not a single bit of executables, drivers or OS code was edited to achieve these results. What has changed is how the system is perceived through the eyes of the benchmark. It's just not reliable the way it's done currently.

    What really should be taken away from this is the fact that this needs attention, needs to be changed and fixed. And it's not only one thing.

    Edit: Just to clarify, HWBOT knows about these problems since last year.

  2. I think the new points system is not a good solution because it doesn't motivate to compete in all benches equally. In fact the whole idea of "the more subs the more points" is shifting the interest towards certain benches where it is next to impossible to compete against the well known overclockers while others are not benched at all for obvious reasons. A fair points distribution system could make it easier to compete in the long run which could attract new benchers.

    There is also the big topic of trust issues. Too many benchmarks can be easily tricked because the screenshot is the only source to judge by. These benchmarks need to be updated or removed. Although this is a very painful process, it is necessary for extreme overclocking to be taken seriously. But that's not all, the following things need change in my opinion:

    • Timing and result handling have to be unified! Benchmarks are currently horrible at this, some are better some are so easily cheatable it's a joke.
    • The submission system should have a SDK, so it can be easily integrated into benchmarks and updated in a unified way when changes are needed. HWiNFO, a unified timer and result handling have to be a part of this SDK. The benchmark just feeds the right values to it and fires the submission process.
    • The logic/validation of submissions have to be server-side. The benchmark can do it on its own to improve user experience but the server decides if this is a valid score. This would allow old benchmark versions to be valid in certain situations and would have circumvented the timer skew bugs in Windows 8 and higher. The next bug will come along sometime and the already difficult OS/hardware/benchmark combination will end up as a clusterf***.
    • Benchmarks should not bother with vendor and device names of hardware, because there is always a problem with matching the local and server names. The benchmark will therefor only send the vendor and device ids, the server translates them back into readable names.
    • Benchmarks should be thorougly inspected by someone with knowledge of reverse engineering and locating serious security issues. Together with the SDK submission integration this could end up in a certificate of some kind.

    I know that this is a lot of input on benchmarks, but don't forget that benchmarks are the main focus of overclocking. Without them there is nothing to measure so they are key to the overclocking business. To understand how bad the situation currently is I decided to finally release the following video to the public. This is a tool I wrote in not even a day that completely screws with CPU-Z and XTU in an undetectable manner. I won't go into technical details for now for the sake of extreme overclocking in general. With GPUPI 4 I already found a way to fix these security issues (and lots of others).

     

    • Like 4
    • Thanks 3
    • Confused 2
    • Sad 2
  3. The performance of the new versions in the GPU categories will be the same. The CPU categories are a different chapter as there will be a native AVX path that should be faster than OpenCL on modern CPUs.

    So yes, my recommendation will be to rename the 3.3 categories to GPUPI 4. Just Like Geekbench.

    • Like 1
    • Thanks 1
  4. GPUPI 3.3 will be discontinued, so no, there won't be a direct upload to the new benchmark category.

    BUT there will be good news soon. I am currently working on GPUPI 4 which will introduce a whole new foundation for timing and handling of benchmark results. I won't get into it right now, but I can guarantee some surprises.

    I also have the intention to maintain GPUPI 3.2 by releasing a minor version until GPUPI 4 gets out of the beta phase.

    • Like 1
  5. The problem is that the GPUPI 3.2 Legacy version is compiled with CUDA 6.5 to be able to be compatible with as many NVIDIA cards as possible (all that support double precision calculations in fact). But CUDA 6.5 will never be as fast as GPUPI 2.3.x with CUDA 8 support. Same goes for GPUPI 3.x with CUDA 9 btw.

    Well, it seems like this will be a huge problem with continued support for new graphics card architectures and especially new CUDA versions. But I may have already found a way to tackle this with runtime compilation or by running PTX assembly directly. I will have a look at this in the next few weeks, it will need a lot of testing.

    As for submission with GPUPI 2.x please read my answer here:

     

    • Like 1
  6. 9 hours ago, Splave said:

    maybe 32b is turning into a more viable option for global points now that its much faster?

    Would definitely be one of the hardest GPU categories to give points, right? GTX 1080 Ti at 3000 MHz for over 4 minutes anyone? :) 

  7. Yes, it's cleaner code with improved comparability between different devices and the OpenCL path is now implemented correctly as it always should have been.

    The different OpenCL drivers produce closer results (although AMD OpenCL 1.2 = AMD APP SDK 2.9-1 is now the best choice in all categories), Batch Size and Reduction Size are not as picky as it was before and on NVIDIA cards the OpenCL implementation comes very close to the CUDA implementation, which indicates that everything is done right now.

    The bottom line is GPUPI is now much better as a benchmark in general. I would have done this with GPUPI 1 already, if I could have. But I wasn't good enough at OpenCL coding and mathematics back then (OpenCL is a brutal beast though).

    The good news is that something like this won't happen again. I will not touch the algorithm anymore, because it's pretty much maxed out the way I do it. The next step is an OpenMP path that gets rid of the OpenCL implementation, but that's many months away and will not overrule current results. The CPU path will be split into OpenCL and OpenMP (or Native, don't know yet), so no rebenching necessary. The new path will make use of AVX and whatever comes next to support the hell out of everything that comes in my way. :)

    I know the XTU coders and they don't seem to be interested in overclocking, let alone competitive oc. They just do their job and as far as my experience with XTU SDK goes, it's not entirely a good one (sry guys). I really try to do things differently with GPUPI. I want it to be on the bleeding edge too, but I wouldn't have introduced the speedup with 3.3 if everybody in this thread would have stood against it. As I already said: GPUPI should first and foremost be fun to bench.

  8. The last bugfix release is already an hour old, so lets post a new one: GPUPI 3.3.2

    Download here: https://www.overclockers.at/news/gpupi-3-is-now-official

    Changelog:

    • Bugfix: Application crashed while saving a result file
    • Bugfix: Some Intel iGPs could not compile the OpenCL kernels due to an incompatibility
    • Bugfix: Application crashed on certain systems while benchmark run initialization (due to memory detection)
    • The hardware detection of the memory manufacturer is a delicate process and can crash the application, so it will be skipped when running HWiNFO in "Safe Mode"
    • Improved the error message when an OpenCL reduction kernel can't be initialized due to limited shared memory (only possible on weak iGPs)

    All open bugs should be fixed now! Thanks to everybody that helped to improve GPUPI!

    • Like 2
    • Thanks 1
  9. 41 minutes ago, Jokot said:

    I just tried with both 290x and 390 and it crashed right when bench was suppose to start (GPUPI 3.3.1)

    Thanks to the open Debug Log window I can narrow this down to the memory not being properly detected by HWiNFO.

    Can you please test GPUPI 3.2 as well? No screenshot needed, just a confirmation, that it's not working there too. Thanks!

  10. 20 minutes ago, GeorgeStorm said:

    Thought I'd have a quick go, seemed to crash whilst saving screenshot everytime, with skipping and not skipping detection, and having hwinfo full or off.

     

    Specs:

    W7, Q9550, GTX970 (what I was using to run it).

    Can you do me a favor please and post a screenshot with open Debug Log (Menu: Tools => Debug Log). Please open the log window before you are saving the result file. Is that possible or is the application instantly closed?

  11. GPUPI 3.3.1

    Not a day old and already a bugfix release. :P

    Download here: https://www.overclockers.at/news/gpupi-3-is-now-official

    Changelog:

    • Bugfix for kernel compilation on old AMD graphics cards
    • Bugfix for command line mode when using "-a" parameter (optional API selection)
    • Improved error message including a tip when the calculation fails due to the watchdog timer resetting the graphics driver (only happens on old graphics cards when a kernel takes longer than 5 seconds).
    • Improved error message when an OpenCL device runs out of ressources including a tip how to fix it (for example on old AMD graphics cards with reduction size 512)
    • Bugfix for Multi-GPU Mode: If one of the devices abort the calculation due to an error, the benchmark run is now aborted.

     

  12. Then lets push forward! I love it! :D

    A few facts:

    • Due to the less complex calculation code, the comparison between different GPU/CPU architectures and GPGPU APIs (CUDA VS OpenCL) is fairer than it ever was. No extra code for compatibility, just what's necessary to make it run.
    • The improved handling of OpenCL makes better use of the devices (= CPUs and AMD GPUs). That results in less differences between the OpenCL drivers. Plus Batch Size and Reduction Size are not that important than they were before. They are still if you want the golden cup, but beginners won't score as bad if they just click Calculate + Ok.
    • AMD OpenCL 1.2 now trumps everything that Intel has got. Even for 100M on Intel CPUs. The Intel OpenCL drivers suck.
    • AMD OpenCL 2.0 works much better now. It still has problems with bigger reduction sizes like 512 and 1024. Seems like 256 is the best currently.

    I have just uploaded a version with some last minute fixes for the HWBOT submission (better wording, removed the screenshot canceling).

    Please download GPUPI 3.3 from here: https://www.overclockers.at/news/gpupi-3-ist-final
    It's now official! 

  13. 21 minutes ago, bolc said:

    i could run 3.1 without c++ 2015 i think
    on the legacy version, i tried safe mode, will put it off next :)

    That's not possible, C++ 2015 is necessary since 2.x. It might just have been installed by another application with an installer.

    22 minutes ago, bolc said:

    on the normal version, appcrash on opening
    thanks

    That's definitely not enough information to get anything fixed. Are you opening the normal version with your Q9950? That can result in an OpenCL error, if you don't have an OpenCL 2.x runtime installed. GPUPI would complain about a missing "clCreateCommandQueueWithProperties" function. Old hardware should only use the Legacy version, it supports OpenCL 1.1.

  14. 8 minutes ago, GeorgeStorm said:

    It doesn't really affect me as I've got most of the hardware I've run gpupi on, but it never feels great beating others because the software has got better, nothing to do with you, also nullifies their hard work no?

    The way I see it as an overclocker, you are beating others by being active and putting more effort into it. I remember Turrican redoing each of his impacted GPU scores with every new CPU generation out there. There is a multiude of other factors that need rebenching as well:

    • Driver updates
    • Tweaks uncovered
    • New OS version
    • Bugfixes and cheat protections for benchmarks

    I guess it's safe to say, that rebenching is pretty normal to be in the top ranks. Especially in the race for Hardware Masters.

    17 minutes ago, GeorgeStorm said:

    Also @_mat_ I'm confused, so which version is being released, the one that's significantly faster or only 200ms faster?

    That's what I am trying to find out together with all of you. I don't want to overrule things like that, just because I can. I want to make a good decision, that keeps overclockers happy and motivated to bench GPUPI. That's my only goal with the benchmark!

  15. 6 minutes ago, bolc said:

    Vcomp140.dll missing :D

    c++ 2015 required ?

     

    ok so with c++ 2015, appcrash when loading, on win7 64 pro edition

    The Visual Studio C++ 2015 Redistributable is needed for the normal version of GPUPI since 2.x. Download is here: https://www.microsoft.com/de-at/download/details.aspx?id=48145 (use the 64 bit version).

    Btw, the Legacy Version needs the Visual Studio C++ 2013 Redistributable because CUDA 6.5 can not compile on newer version of Visual Studio.

    Just now, bolc said:

    Legacy edition starts but crashes on running confirmation
    ep45-ud3p / q9550

    Have you tried different settings for the hardware detection? You can try "Safe Mode" first and select "Off" if that doesn't help. I reckon that this is just a compatibility issue with HWiNFO.

×
×
  • Create New...