havli

Updated package with CPU-Z 1.89.1 and newer version of bundled Java is now available. http://hw-museum.cz/data/hwbot/HWBOT_X265_2.2_cpu-z_1.89.1.zip The benchmark itself remains exactly the same, no changes from version 2.2. The new Java might help in some rare cases of application crash when saving the data file. CPU-Z 1.89.1 improves HW detection.

I think this is due to the drivers being older than X299 platform... and thus not allowing to run SLI. Each platform must be white-listed in the driver, otherwise it won't show option to enable SLI. Try this patch https://www.techpowerup.com/forums/threads/sli-with-different-cards.158907/

Very nice and efficient run! My 270X can reach these clocks too... but I doubt I could get anywhere near your score. :D

No, performance should remain the same. The encoding is performed outside of java. The whole benchmark is more or less just a wrapper to x265 encoder.

Thank you for the log file. It seems this might be some kind of a bug in Java. Same problem here for example https://bugs.openjdk.java.net/browse/JDK-8178873 X265 only uses the built-in portable java, should be completely independent on the installed x86 or x64 versions of Java. It even works on systems with no Java installed at all, as a portable benchmark (this was the goal after all). Now the question is how to deal with this issue. One thing that might help could be changing the GUI style to not look like standard Windows application. This would require me to do some changes in the code, redesign all the graphics objects slightly.... and in the end it would look ugly (IMO ) . Another possibility worth trying is to download updated version of portable Java and replace the old one in X265/Java folder. I have no idea if this can fix the crashing problem or not. On my PC X265 works with both portable java versions (1.8.0_51 and 1.8.0_181)... but I never had this problem. Link for 1.8.0_181 is here: https://www.softpedia.com/get/PORTABLE-SOFTWARE/Programming/Java-Portable.shtml (the x86 version) The direct online submission problem shouldn't be related to this bug, as it doesn't use the file chooser window (which can cause troubles). So this is most likely what _mat_ mentioned.

@marco.is.not.80 There should be log file next to the executable... HWBOT_x265_Benchmark_log.txt - Does it say anything interesting? The code for manual file saving is unchanged since the beggining (2015 I think) as well as the bundled portable Java. Of course it is possible I did some mistake in there, however it must be very rare set of conditions because in 99.99% cases it works. My bet is something is missing / broken in your OS. Possibly some service or function that is used when saving the file. The benchmark shouldn't just quit like you are experiencing. In case something goes wrong, it might just hang or do nothing... however not quit silently. Btw - did you try to redownload the whole benchmark again to make sure some of the files aren't corrupted?

Is price of the GPU alone really that important? To get competitive score you must have other equipment (CPU / MB / RAM / LN2 cooling) worth of hundreds $ at very least. So not very cheap anyway.

As for the CPU support - stock PC-DL should be able to run any Prestonia or Gallatin Xeon. Even the 4MB Xeon MP works https://hwbot.org/submission/3520109_havli_superpi___1m_xeon_mp_3.0ghz_33sec_735ms Also it is possible to change CPU voltage (VID) by socket pinmod (similar to socket 462) but is isn't very practical.

... and the last one can turn off the server and switch the lights off. //edit... but similar analysis of x265 would be interesting of course. On the other hand It holds a risk of finding some kind of a security hole which may not be possible to fix at all... or would take too much of time to be worth it. The fact the benchmark developer is still here doesn't guarantee unlimited maintenance and support.

XTU is one thing... but with enough effort I'm sure many benchmarks can be hacked like this. And I seriously doubt those vulnerabilities will be fixed.

Are PCI VGAs better than AGP for OC? Also I often used PCI SCSI controller because most of the time XP survived moving to completely different platform which doesn't work with IDE. No idea how that can affect OC though.

Version 2.44 should be the correct one. Later versions don't work IIRC. I'm not using this bench anymore but from what I can remember - you must submit your score directly, saving the datafile and uploading it later never worked. Also I recall having similar issues of closing the benchmark by itself after the run. Perhaps try to run the bench first and after it is finished login and submit. But it is just a guess.

Yes, but most likely different clocks than you actualy have when running 3DMark. Also the rules say just "A verification screenshot is required, including motherboard and GPU sensor tabs ". I take it as - sensors must be present on the screenshot but doesn't matter when you run it and what it shows.

Hmm, why is GPU-Z sensors tab required for CC? Cooling methods are unlimited as far as I know, so not because of temps... this is not LCC, so no clock limit either. Most people (me included) open the GPU-Z after the run is finished... so there is nothing to see besides idle status of the GPU. I don't mind putting extra window on the screenshot, just don't see the point as it shows no relevant info.

I was developing the benchmark on SB-E platform and at the time I performed a lot of testing. AVX had zero inpact on performance when running on SB (Core and Xeon series - those do support AVX). You can try it yourself - either by using Windows 7 non-SP and SP1... or the built-in function of x265, the CPU features override (which is much more convenient). AVX2 on Haswell and later improves the performance a lot. AVX1 perhaps helps too on some architectures, but certainly not on SB/IB.

AVX makes no difference on Sandy Bridge (in x265)... SSE4 is the key.

Here is cpu-z validation link. http://valid.x86.fr/i37akj Thanks

Actualy I didn't try versions other than 3.2 and 3.3.2. Those behaved the same - appcrash. Thanks fro the tip, I'll try the 3.1 next time.

I think the singlecore stage will be very exciting... especially when you get to the point of having a great score and then you flip the coin whether you get the data file saved, or appcrash. I have a feeling there will be a lot of smashed keyboards.

GPUPI 3.x is a hit or miss it seems. Today I was running it on C2D and always appcrash when saving data file. On the other hand, A64 AM2 was running just fine http://hwbot.org/submission/3927537_havli_gpupi_for_cpu___100m_athlon_64_le_1640_(orleans)_8min_27sec_791ms

I'm not really sure... but isn't s939 too old to support HPET? AM2+ boards definitely support it, never tried it on older platforms.

This is weird. Do you have the same Windows install for both systems? Java version shouldn't matter - x265 is using built-in portable Java... in order to run as a portable benchmark without any special requirements on SW installed.

Buggy bios maybe? At least my UD3P is really pain to use, especially with K8 CPUs.

Thanks for the link, if simple standalone patch is sufficient, then it is worth trying.

Ok, I take it as no other benchmarks. You realy don't need to teach me what overclocking is about I'm here long enough to know a few tricks here or there myself. The thing here is to evaluate whether it is worth the extra time spent or not. In other words - what is better - quantity or quality? For example SuperPI 32M - we all know it is best to run in on tweaked XP (for most platforms)... but is it worth the effort to install XP just for one benchmark, when I'm running the other 20 on W7 64? For most cases it isn't. And the same applies here, on top of that the uncertainty of GPUPI future (what version will have points... 3.2, 3.3, 4.0... or which one will ger merged / deleted) might be discouraging people from putting too much work in it.