havli

Yes, Windows 7 Pro CZ I never had problem benchmarking GPUPI on CZ windows. The xeon system is now disassembled, but the very same install of win7 (just connected HDD to another PC) worked fine on socket 1366 Xeon next day. I guess the data file just got corrupted somehow. Maybe a solar flare or something.

Thank you. 4 points and two gold cups are no big deal... still I'm curious what the problem is. Yesterday I put the HDD to Nehalem Xeon PC (no reinstall) and suddenly GPUPI submit is working again. Really strange, must be some kind of obscure incompatibility.

Clock and RAM timing are tied together. 155 - 166 MHz = 6ns RAM, 183 MHz = 5.5ns RAM. Check this: Radeon DDR -> http://kwaz.cz/index.php?strana=grafika&idg=200&pocetvyrobcegpu=ATi - 166 MHz, 6ns DDR Radeon DDR VIVO -> http://kwaz.cz/index.php?strana=grafika&idg=186&pocetvyrobcegpu=ATi - 183 MHz, 5.5ns DDR GF2 MX400 is a different case - clock and memory type varies... but name remains the same. So only one category for this one. Radeon R100 exists in 5 different versions (official by ATi) and they have (had) different name.

Well, the Radeon R100 situation is a bit more complicated. In reality there are following cards based on the R100 GPU: Radeon SDR - 32 MB SDRAM, 160/160 MHz Radeon 7200 - 64 MB SDRAM, 155/155 MHz Radeon LE - 32 MB DDR, 148/148 MHz + disabled Hyper-Z Radeon DDR - 32/64 MB DDR - 166/166 MHz (some of them are AIW) Radeon DDR VIVO - 64 MB DDR - 183/183 MHz On HWBOT we currently have: All-In-Wonder Radeon DDR Radeon 7200 DDR Radeon 7200 SDR At some point ATi decided to rename all R100 Radeons to simple "Radeon 7200 Series". So it is difficult to determine what type exactly you have. I guess because of that we have only two categories - R7200 SDR and DDR. Plus the All-In-Wonder Radeon DDR which was added on my request some time ago. Not because of the TV Tuner and Video IN... these have no impact on overclocking. I asked to add it because it is a different videocard with lower default clock. Same as for example GF4 MX 440 and MX 460. ------------ I agree AIW variants should be merged - if they are 100% identical to existing variant of given VGA (apart of the TV tuner of course). From the top of my head - Rage 128 Pro / Rage 128 Pro AIW or Radeon 9000 / Radeon 9000 AIW. For example these have identical memory and stock frequency.

Update: Single CPU on the 771 platform now results in the same error. Weird, it was working fine two days ago... and I'm not aware of any changes in OS, drivers or other SW. Another PC using Pentium D 945 + windows 7 x64 works just fine. Well, the OpenCL driver is older and I'm running legacy version of GPUPI because of that... still, the "Unable to parse the datafile" error sounds completely unrelated to this.

Strange thing is single CPU setup didn't suffer from this problem. http://hwbot.org/submission/2959283_havli_gpupi_for_cpu___100m_xeon_5050_4min_21sec_356ms http://hwbot.org/submission/2959280_havli_gpupi_for_cpu___1b_xeon_5050_56min_40sec_31ms I will try to remove the second CPU to check if GPUPI submit works again.

mat, can you please take a look at this data file? Suddenly I'm unable to submit my results - Invalid data file: Unable to parse the datafile. Similar error shows up when uploading directly from GPUPI. Testing system is: 2x Xeon 5050 (stock, not overclocked) 8GB RAM Windows 7 x64, HPET on GPUPI 2.1.2 or 2.2 (both 64bit) http://hw-museum.cz/data/temp/2x_xeon_5050_GPUPI_for%20CPU_100M_02m-14.666s.result Thanks

I'll see what I can do about the DPI scaling. If all goes good, it might get implemented after v1.2 Time labels are in place and working quite good. Of course the remaining time is not very accurate - encoding speed is not linear, so time sometimes go backwards, depending on current scene. CLI: Oh, I understand now. I'm testing processors for web magazine too (retro hardware), unfortunately my methodology forces me to keep the benchmarking sequence running in person. It should be possible to implement batch run - using command line to start the benchmark and save results automatically... in theory at least. This will take some work, so no ETA on this one. Currently the code is not designed for operation like this. 8k: The download is big enough as it is (almost 500 MB). Adding another big video... uh, that would be too much IHMO. Also RAM capacity might become a limiting factor. 1080p ffmpeg + x265 needs at least 512 MB (no problem here), 4k = 1,5GB, 8k = who knows, I bet it would be a lot. Also when running "overkill mode" (aka multiple instances of encoder at the same time), RAM requirements grows very fast. L4 cache can indeed make a huge difference in some applications, mostly games. I saw the Broadwell reviews. Huge Haswell-EP Xeons with large L3 cache (>20 MB) sometimes can pack similar boost. Apparently when performance critical part of the application can fit in L3 or L4 cache, performance increase is massive.

trodas: Thank you, I'll update the RAM requirements section. P4 Celeron is really slow by the way borandi: I'm aware of the scaling issue. Java Swing doesn't work well with non-default DPI, so I disabled the scaling completely to avoid weird looking and broken GUI layout. In the current version (1.1.1), screenshot is captured as a png. I realise now the size of lossless png is too big, especially for large screens. So I'm going to use jpg instead to keep the size reasonable in the next update. Total time and ETA to finish should be possible to add if I find a free spot for it in the GUI. Command line interface - I don't think this is a good idea, there ale enough options to to get the best score possible as it is. And most people are running default settings anyway. Actually, the x265 console output is written to text file after each run even now. It looks like this: yuv [info]: 3840x2060 fps 23976/1000 i420p8 unknown frame count raw [info]: output file: run0-2160p.hevc x265 [info]: HEVC encoder version 1.7+374-b015514a93868e2d x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit x265 [info]: Compiling by KG7x [x265.ru] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX x265 [info]: Main profile, Level-5 (Main tier) x265 [info]: Thread pool created using 4 threads x265 [info]: frame threads / pool features : 2 / wpp(33 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40 x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 0 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 2 / 0 / 0 x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1 x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60 x265 [info]: tools: rd=2 psy-rd=0.30 signhide tmvp fast-intra x265 [info]: tools: strong-intra-smoothing deblock sao 1 frames: 0.44 fps, 314.64 kb/s 2 frames: 0.74 fps, 2176.72 kb/s 3 frames: 1.02 fps, 3028.76 kb/s 5 frames: 1.52 fps, 2940.84 kb/s 6 frames: 1.47 fps, 2705.78 kb/s 8 frames: 1.83 fps, 2589.36 kb/s 9 frames: 1.94 fps, 2566.13 kb/s 11 frames: 2.00 fps, 2455.78 kb/s 13 frames: 2.23 fps, 2517.81 kb/s 14 frames: 2.30 fps, 2522.64 kb/s 16 frames: 2.34 fps, 2439.85 kb/s 18 frames: 2.53 fps, 2796.70 kb/s 19 frames: 2.57 fps, 2788.14 kb/s 21 frames: 2.57 fps, 2933.98 kb/s 23 frames: 2.71 fps, 3159.12 kb/s 25 frames: 2.82 fps, 3180.12 kb/s 26 frames: 2.72 fps, 3174.97 kb/s 28 frames: 2.84 fps, 3494.32 kb/s 29 frames: 2.81 fps, 3524.84 kb/s 31 frames: 2.76 fps, 3747.71 kb/s 34 frames: 2.91 fps, 4068.00 kb/s 36 frames: 2.92 fps, 4213.74 kb/s 38 frames: 2.82 fps, 4158.86 kb/s 39 frames: 2.80 fps, 4177.12 kb/s 41 frames: 2.87 fps, 4248.72 kb/s 42 frames: 2.89 fps, 4270.79 kb/s . . . . . 8k - when quantum computers are ready. No, I didn't speak to them. I just saw this http://x265.ru/en/x265-hd-benchmark/ , did some testing on various hardware and realized the x265 is very good for benchmarking both latest CPUs and legacy hardware as well. I thought - the encoder is opensource... so why not create my own GUI for it and use it on HWBOT.

Please add: Asus PCH-DL http://hwbot.org/submission/2957756_havli_black_hole_benchmark_xeon_3.2ghz_%282mb_l3%29_3604_marks thx.

Yeah, the java function to take screenshot only works on the primary monitor (by default). I'll do some research to see whether it is possible to extend it to capture the whole desktop. ------- trodas -> sent PM.

Thank you, I'm glad you like the benchmark. It is good to hear it really works on old school hardware. I did some quick testing during development, but I didn't have the patience to wait this long. Aleslammer: Dual Socket 771 PC was one of my testing rigs... I did a lot of alpha testing there. I like dual-CPU boards very much, so I tried to optimize the benchmark frontend to work well on these things. 11.4 fps @ 1080p s really good score for "old" Core 2 architecture. My best score is around 4.5 fps for single Xeon L5410 and ~2 fps for 2x Xeon 5110.

Well, no need to change the score precision then. The Windows Vista - 10 mixup seems to be cpu-z error, this is beyond my power to fix. And Skylake is not affected by the RTC bug, so no problem there. http://forum.hwbot.org/showthread.php?p=402927#post402927 If the OS is detected wrong on older platforms too, please use older cpu-z version 1.72.1 (copy it to the x265 older) - there was no problem with win10 during my testing. http://hwbot.org/benchmark/hwbot_x265_benchmark_-_1080p/ http://hwbot.org/benchmark/hwbot_x265_benchmark_-_4k/ Enjoy.

Yes, this is possible and relatively easy. X265.exe only provides two decimal digits, but I can calculate the final score with more precision easily as: total frames / elapsed time. It would be best to implement this change before the benchmark goes public. MBit/s sounds kinda weird. FPS is a common unit for video encoding speed, I want to keep it that way.

You are using windows 10, right? Weird thing is cpu-z detects it as Vista. Therefore the benchmark runs even without HPET.... which it shouldn't. Can you please upload hardware.txt located in x265 folder (only available when the benchmark is running)?

Well, opensource... I don't know, the code is quite a mess. And also rather long - over 10000 lines of code. Maybe in future. The screenshot inside data file is in PNG format, I dont like the artifacts usually produced by JPEG. 0.58fps @ 4K is good score af a ULV Laptop. My workstation based on two Core2 Xeons (4C/4T in total) only scores 0.4fps. I'm looking forward to see the Skylake score. Hopefully the Timer detection will be working reliably, as it does on older platforms.

Cool, so it works on PIII after all. And even with 512 MB RAM. Unfortunately Java is the only suitable language for me. My c++ or c# skills are way too low for complicated project like this. The final version however will be a portable benchmark with built-in java... Thank you for the testing. btw - little reminder - no need to waste more power and time continuing this run (unless you are curious what the final score will be ). The result file is not valid for (future) submission.

Yeah, if it works, then I will update the minimum system requirements. Also the final version is almost ready. All the mentioned "Known bugs / things to be improved in the final version" things are fixed / implemented.

Well, 290X 4GB and 8GB are ok as one category. The overclock doesn't differ much and 4GB is more than enough for all benchmarks at the moment. So no problem here. I'm sure there are plenty of VGAs like 290X (no performance and OC difference). These can be merged for sure. The opposite example is GeForce 2 MX. 32MB overclocks better and because of that it is faster in 3DMarks 2000 - 2003. 64MB wins in Aquamark because it is less dependent on AGP texturing in there. http://hwbot.org/hardware/videocard/geforce2_mx400_32mb/ http://hwbot.org/hardware/videocard/geforce2_mx400_64mb/ I guess this is not the only case... So the conclusion - I agree to merge some categories but others should remain separate. It is going to be difficult to decide. And even more difficult in case of adding hardware that isn't in the database yet.

Wait a minute - so this means the existing categories with different RAM capacity are getting merged? I don't think this is a good idea. Cards with more RAM overclocks worse most of the time... so they would be in disadvantage. Also they tends to have lower stock clocks. In some benchmarks this is compensated by better performance (3DMark 06 128MB vs 256 MB). But mostly the performance is the same at the equal clock.... and lower in absolute. For example these two FireGL X1: http://hw-museum.cz/view-vga.php?vgaID=68 -> http://hwbot.org/hardware/videocard/firegl_x1_128/ http://hw-museum.cz/view-vga.php?vgaID=186 -> http://hwbot.org/hardware/videocard/firegl_x1_256/ Obviously the 256MB version is much harder to overclock and because of AGP Pro it can't be used on fastest AGP motherboards like AM2NF3-VSTA or 4core-Dual-sata2.

Strange - I've just installed 340.52 and OpenCL is still giving me "invalid result" message. GPUPI 1.4 @ CUDA is working fine. GPUPI 2.2 @ OCL = the same as 1.4 @ OCL. 2.2 @ CUDA... as I wrote before. Maybe I should try it on clean windows install. Maybe it will help.

Unfortunately, batch size seems to have no effect. I tried 1M, 2M, 4M, 5M, 10M, 20M Always halt few seconds after "Batch 4 finished". Reduction Size doesn't help either.

This is certainly step in the right direction. Now all presets up to 100M works fine @ CUDA . 500M and above however results in this error: OpenCL never worked for me, not even in old 1.4 GPUPI. I think you said it is caused by poor nvidia OCL implementation on these old GPUs.

I'm sorry to bring this up again... but despite all efforts Nvidia G200 still refuses to work with GPUPI 2.2 (legacy). Although the error message is different this time. If you manage to fix this issue, I promise to bench all G200 videocards I can find. LOG START at 2015-08-16 01:03:07 ---------------------- Starting run to calculate 1000000 digits with 1 batches Batch Size: 1M Maximum Reduction Size: 64 Message box: Press OK to start the calculation. (Start) Error while calculating series term! Result digits: 000000000 Result time: 0.006000 Device statistics for NVIDIA GeForce GTX 285: Calculated Batches: 1 of 4 (25.000000%) Kernel time: 0.000000 seconds Reduction time: 0.000000 seconds Message box: Invalid result! (Error)

Seriously... why so many complains about one simple problem? Just keep trying older cpu-z versions and eventually you will find a working one. Why insist on validation for aquamark? Simple screenshot will do.