Jump to content
HWBOT Community Forums

havli

Members
  • Content Count

    435
  • Joined

  • Last visited

  • Days Won

    3

havli last won the day on October 30 2018

havli had the most liked content!

Community Reputation

82 Excellent

About havli

  • Rank
    robo cop

Converted

  • Location
    CZECH REPUBLIC

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You mean the elapsed and remaining time? Elapsed time is measured directly by the wrapper, using Java nanoTime() function. And remaining time is prediction based on the amount of frames finished and actual framerate. The x265 encoder executable also measures time (internally, but reports it as fps). However this is the "wall clock time"... so less accurate and vulnerable to system time manipulation. In earlier versions of the benchmark, the score was taken directly from the encoder. But after some cheated scores were discovered I changed the time measuring to use nanoTime() and calculate the fps myself.
  2. @_mat_ At this time I have no plans for future x265 development... Other than perhaps reuploading updated package with recent cpu-z version once in a while, like I did this year after Ryzen 3000 launch. The main executable is more than 1.5 years old and considering I see barely any problems or complains... it means either people don't care 😄 or everything works reasonably well. If you wish to integrate x265 into BenchMate using the DLL injection method, I have no objections. 🙂 However doing new version with native BenchMate integration seems like to much work, especially with testing and validation (which I always did with each x265 version) on many different platforms, even the obscure ones and on each of them multiple OS. That is much effort and time which I don't want to spend this way.
  3. Old versions of GPU-Z should work in 2k. For example 0.4.6 worked for me https://hwbot.org/submission/1074470_havli_3dmark2001_se_radeon_7200_ddr_4634_marks
  4. Hint for the X265 4K Dual Core. Perhaps the locked Skylake i3 / Pentium / etc. with BCLK overclocking and disabled AVX might be faster than almost default with AVX2. But who knows...
  5. 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.
  6. 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/
  7. Very nice and efficient run! My 270X can reach these clocks too... but I doubt I could get anywhere near your score. :D
  8. Not really, it is pain to install W7 on some modern platforms... And for example Raven Ridge is W10 only. In the future this wil get worse and worse.
  9. 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.
  10. 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.
  11. @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?
  12. 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.
  13. 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.
  14. ... 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.
  15. 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.
×
×
  • Create New...