_mat_
-
Posts
1003 -
Joined
-
Last visited
-
Days Won
41
Content Type
Profiles
Forums
Events
Blogs
Posts posted by _mat_
-
-
Intel's OpenCL driver never supported XP, only Vista and above. And the latest versions will only work on Windows 7/8.
There are a few Catalyst drivers for XP that should work. Take a look here (left side, will need a user account). There are also a few old AMD APP SDK versions with XP support, search the web for it.
I would suggest to run Windows 7, plugin and AMD card and install the latest Catalyst with OpenCL 2.0 support. It should give you the best scores. Seems like NVIDIA is the only vendor that has their latest drivers XP ready, even though it's inoffical and can not be found on nvidia.com/geforce.com.
-
Which GeForce driver version did you use? Invalid runs without unstable overclocking are a sign of old buggy drivers.
-
It will be possible after May the 3rd when manual submission of scores will be disabled.
-
I am very happy to hear that. Keep pushing it!
-
Looks very close to my implementation.
Thanks mate!
-
Seems to be a driver bug, maybe the CPU is not supported by the new Intel drivers. You can try older versions like 14.x, but I recommend to benchmark with AMD's OpenCL 2.0 drivers anyway to get the best score.whit win 7 64bit the intel opencl is not working agen.but the amd is working
i only need manuel enter the cpu
Thanks for noting the CPU detection problem. HWBOT lists this CPU as QX9775, but the hardware device name is X9775 inside the drivers. This incompatibilities happen all the time. I will include a manual override for those CPUs with GPUPI 2.2.
-
What's the version of the Intel OpenCL driver?
Btw, you should try the AMD driver included in the latest catalyst. It should be faster.
-
Congrats!
The bench is not so bad, is it?
-
Very nice score! 18 cores and 64 bit FTW!
-
Please describe your problem exactly. We are more than happy to help!
-
Smart.
Well, that all went pretty fast now because of you guys suddenly submitting scores with the new version. That certainly was a big surprise ... in a good way of course, because you just overclocked the launch date!
Btw, I've updated HWBOT's internal benchmark version to 2.1 too, so from now on only submissions with 2.1 will be accepted. Automatic submissions with GPUPI 2.0 will fail, but you can still submit the scores manually.
As for the new data file saving and uploading: It will start working after the 3rd of May, when manual submission of scores is disabled (as it's said in the annoucement). HWBOT implements it only that way, but it won't matter in a few days anyway.
-
How did you guys get the download links for GPUPI 2.1? Guessed it?
It's officially not released right now, because we are currently discussing the problems with the new 64 bit version and ongoing competitions.
-
Both parameters adjust the workload to the GPU architecture.Is it allowed to alter batch size and reduction, seems many are running the benchmark at non default setting lol -
As I am still waiting for HWBOT staff to test the new timing methods, I took the time to implement the promised legacy version of the benchmark. I currently have it running on Windows XP including OpenCL and CUDA support for GeForce 200 series cards.
Now I started experimenting with getting rid of the double precision restriction. I already coded some quadruple floating point algorithms, but it's not looking good. 1M is working, but everything higher needs much more precision as I expected. I am still trying to wrap my head around some float128 bit shifting code, that could possibly work. Too early to tell yet.
What would be possible is to outsource the double precision math to the CPU. It's not really a big part of the calculation, but it would alter everything that we got today. And it would be much slower for systems with double precision support.
-
I guess mixing cards is currently on a trial run by the HWBOT staff. It's intriguing but there may be social concerns. Performance and cheating wise it should not be a problem. My suggestion for a rule is, that the fastest card decides the submission category. Therefor it doesn't matter what the other cards are, the result will always be slower or at least equal than with the same cards. The fastest card can easily be determined by the statistics below the result. The automatic submission exactly does that for you.
What I don't understand right now is the negative energy focused on the bench by some guys here. If you want it to fail, it's going to happen because it's not about having the bench to be unbreakable by cheaters (and haters), it's about embracing it and working things out. GPUPI adds a lot of new possibilities to the table, we can use/enjoy them, abandon others. But it only works if we do it together.
-
No benchmark is really safe from cheating currently.Well.... I don't feel the same Hence the thread I don't know enough about coding and manipulation to know how easy or hard that is to protect from cheats.
You are welcome to add your constructive thought here to this discussion. You're right with the rest ... keep it to yourself.Or....I could keep it to myself and jump on the GPUPI global points train and wait for the wreck.Just like UCBench.
That's fine. I'm good with that. Thanks for the time.
-
The fastest one counts. Try to find a loop hole, then we can talk about discontinuance of points.Doesn't really matter. There's no way to identify multiple cards being used. Only the newest one.It's a cheats dream come true.
Points for this bench should be discontinued until all the flaws are worked out.
-
Nobody knew how fast 4x 290X would be on LN2. I had a a guess, but below 4 seconds is surpising nonetheless. In a good way though, the faster the better!I agree, much appreciatedMy questions in reply: Why enable WR points for it, knowing how long it takes a 4+ GPU setup to complete it on day 0?
Why code the bench in such a way that it will complete in less time with each new generation of hardware? The benchmark, by design, has a limited shelf-life in terms of stress.
I implemented the benchmark like SuperPi so getting faster with each generation is part of the game. Yes, that introduces some problems but it's better than having some batches/second counter. Don't you think?
The only thing that comes to my mind is to reverse the problem. We could make the main category 20 or whatever seconds and the end result the number of digits the system was able to crunch in that time. Where I do see a problem is to validate those digits and how to handle them inside the HWBOT system.
-
Massman and I have discussed this topic for some time and it was a difficult decision. But I would dare to say, that we came to an understable conclusion. Please hear me out.
This benchmark is very different to others that currently receive points. It scales very well with frequency and the number of graphics cards (up to 8 GPUs as theoretical limit). Additionally it likes some cards more than others. So a 290X is more than twice as fast than a GTX 980 ... and those are top modells for gamers and overclockers right now. That enables a huge performance spectrum ranging from an entry card like the HD 7770 or GTX 650 Ti at more than 2 minutes to the current world record of about 4 seconds.
Yes, that's too short so let's look at other options: The next official choice would be 32B. The current single card record is 17 minutes, the world record is at about 6. All slower graphics cards will have to crunch for hours to get a result. Clearly the time for 32B as the main category that receives points has not come yet.
It would also be possible to introduce a new bench target like 2B or maybe the existing 10B. I didn't propose them, because they are not that magical. 1B and 32B are the analogy to 1M and 32M of our beloved SuperPI and that's why I thought of them as the main categories. But whatever, let's take 10B for example. A GTX 980 with 1200 MHz needs 30 seconds for 1B and about 13 minutes to calculate 10B. Wait a minute ... why 13 and not only 5 minutes (10 times 30 seconds)? That's the problem here. For 1B the benchmark calculates the partial results up to 500 million with a way more efficient kernel. Higher numbers have to use arithmetic with more precision and that will slow down the calculation a lot. So 10B is actually more than 25 times slower than 1B. Too slow to be fun, no doubt.
Just for the fun of it I added 2B to the next version of the benchmark. A GTX 980 with 1200 MHz needs about 2 minutes to calculate the result and it may push 4x 290X back to ~20 seconds or so:
2B might be a good alternative and we should dig into that. It would help the world record time indeed, but would it be more fun for most of us? No, because most of us will bench single card, maybe dual. And that's where 1B is currently the most fun and will be for some time in the future. So fark PR and their theatrics. I wrote this benchmark so overclockers have fun with it and that's all that matters to me. And without any doubts that's also what mattered most to our Turrican.
-
I've just tested a freshly compiled 64 bit version of GPUPI 2.1 and it's as fast as GPUPI 1.2 Beta. I will include it in the release!
-
I'll send out the latest version again today and include you. Sry, it didn't happen on purpose.
Btw, it shouldn't be necessary to delete the 1.2 Beta submissions. I am currently testing GPUPI 2.1 in 64 bit and I hope it will be faster anyway.
-
New version is as good as done!
I have added a few features to help the moderators:
- Automatic window resizing after a benchmark to avoid cutting of statistics or result. It's only done if necessary and helps especially for larger multi GPU systems.
- Ctrl+A selects all text in output window now
- Watermark for invalid results:
HWBOT crew is still testing the new timing methods. Haven't heard much from them, but I hope we will release soon.
Well, on the other hand it gives me some time to reintroduce the 64 bit version of the bench.
PS: Yes, this is not really an invalid result, just a test.
- Automatic window resizing after a benchmark to avoid cutting of statistics or result. It's only done if necessary and helps especially for larger multi GPU systems.
-
The speed differences seem to be possible by the 64 bit support, that was available in 1.2 Beta. I removed it because it made no sense for graphics cards. Well, I can reintroduce it, the code path is still built into the new version. I bet GPUPI 2.x with 64 bit support will be faster than the old beta versions too.
But I am a bit worried because we will end up with a lot of executables, which is not very rookie friendly:
- GPUPI.exe (CUDA + OpenCL support)
- GPUPI_CUDA.exe (only CUDA support - not really necessary, only if OpenCL support would avoid starting the bench)
- GPUPI_OpenCL.exe (only OpenCL support - necessary for Windows XP)
- GPUPI_GT200.exe (compiled with CUDA toolkit 6.5 for CUDA 2.0 support of Geforce 200 series cards)
- GPUPI_64bit.exe (64 bit for fastest CPU support)
- GPUPI.exe (CUDA + OpenCL support)
-
Have a look at the log file "GPUPI.log" right next to the executable. Does it say anything more specific?
Reasons for this error can be an unstable network connection or an unstable system.
GPUPI - SuperPI on the GPU
in Benchmark software
Posted