Jump to content
HWBOT Community Forums

Strunkenbold

Crew
  • Posts

    2200
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by Strunkenbold

  1. Already there: https://hwbot.org/hardware/videocard/radeon_graphics_mobile_lucienne_384_shaders/
  2. As said, this has minimal to no impact on the comp. The two added IGPs are just useful if a country needs to fill an empty slot. But they are not competitive to the desktop variants.
  3. I just saw someone submitting with a Comet Lake laptop (using wrong category). Didnt want to pull it from comp, so I added UHD Graphics 630 Mobile (Coffee Lake) and UHD Graphics Mobile (Comet Lake) which are just the mobile variants of existing allowed IGPs. Should have no impact on the compo.
  4. You forgot Prefix Radeon old man. ? https://hwbot.org/hardware/videocard/radeon_rx_550_640_shaders/ @459 Thx for reporting this! Most would just go ahead and submit in existing categories. ?
  5. https://hwbot.org/hardware/motherboard/p4m890m_lil_ms_7255/
  6. I just saw that you got no response to you request. However, in the meantime both were added: https://hwbot.org/hardware/processor/snapdragon_662_sm6115/ https://hwbot.org/hardware/processor/snapdragon_665_sm6125/
  7. https://hwbot.org/hardware/videocard/geforce4_mx_440_8x_pci/
  8. If thats really the plan, then we don't need discuss this much further, as single core results will be in the long run in the same category anyway. There is no reason to make a difference between FX and AL as its the same logic. The base category should have all single core results and we should move results from the p cores.
  9. Well with logic we have sometimes our problems here. Even I struggle sometimes, after all those years (ok this might be a problem I have in general). I always thought one of the unwritten rules was to don't create extra categories for the same named hardware even when some new revision brings new features like 64 bit or a die shrink. We always said its up to the overclocker benching with the best silicon available. Now having two categories for single thread results just because something is disabled or enabled pretty much breaks the mentioned logic. I always thought those new categories are just an intermediate step because of the limitations of the current code but if they keep existing in parallel I'm lost. Its okay to try something new with the hybrid stuff but please consider merging base and p cores categories when code is ready and let the user choose upon submission entering if he disabled e cores so the submission goes into e.g. 8 or 16 cores category just like unlocking a Phenom X2 goes into 3 or 4 cores hardware category.
  10. IMO all single core results have to go into the base category because the overclocker needs to choose which way is the fastest and we really dont want to give double points for same hardware. We should probably already start to moderate those categories and move all single thread results from the p cores categories. Later this needs to be handled with some new code. Those double categories arent the best thing yet. We likely want to have only one category per CPU. Maybe its possible to have something similar like the unlocked K10 CPUs.
  11. Notebook and Desktop version have zero difference in the name but we have two different hardware categories. The name got probably matched to the desktop category thus leading to the problem that the notebook variant gets linked to the desktop category. Technically we have to remove the match of the name string. For now all users need to edit their subs to change to the correct GPU.
  12. Issue found: In our db, Socket 940 wasn't configured to be able to host multiple CPUs. I fixed this now. It should be possible for you to change core count of your submission if you try to edit. @Leeghoofd The idea of those configuration for multi sockets was to prevent users entering wrong core counts for CPUs, like a quad core getting 16 core because user thinks he needs to select 4 x XYZ CPU on the submission page. Now it seems the mechanic behind this is broken as I still can select a different core count for single CPU systems when I make a submission for the first time.
  13. Core configuration is correct except i7 12700KF (8P) which was still at 12 cores. Fixed this now. i9 12900 is 8P + 8E = 16 i7 12700 is 8P + 4E = 12 i5 12600K is 6P + 4E = 10 i5 12600 and below just have performance cores
  14. Please don't submit in categories not belonging to your hardware. Cezanne is almost twice as fast than Raven Ridge.
  15. I have to agree that I kind of added those those new Ryzen APUs in a rush. I add those mobile categories in the future, when I have time.
  16. https://hwbot.org/hardware/processor/exynos_7904/ https://hwbot.org/hardware/videocard/mali_g71_mp2/
  17. https://hwbot.org/hardware/processor/snapdragon_660_sdm660/ https://hwbot.org/hardware/videocard/adreno_512/ https://hwbot.org/hardware/diskproduct/ssd_750/
  18. Super hard on this one, I dont find any information that this CPU has a GT2 graphics part. I suspect this is a GPU-Z detection problem / bug. For now its correct to submit in the existing category.
  19. Quick solution would be to just automatically launching those two CPU-Z windows when you click on save result in BM. Guess this would be no big deal for @_mat_ to implement, wouldnt it?
  20. If we choose the option where the user needs to disabling cores, I would only let the performance cores result count. It would be unfair for a CPU to have the possibility to obtain 2 times global or hardware points. Also we need to consider that if we change our decision at some later point and decide that those processors can make use of their full native core configuration, all core disabled results are getting pretty useless. So we might want make some conservative decision now like the 16 cores are 16 cores approach and better implement something smart when there will be time for. An, probably, over-complicated approach would be to create benchmark categories for the individual core configuration. I just took a look at the Snapdragon SoCs and there would be four possible combinations for 8 cores: 8P 4P + 4E 2P + 6E 1UP+1P+6E So that means there would be an additional 4 + 4, 2 + 6, 1 + 1 + 6 Cinebench ranking for instance. Every user could compare apples to apples then. However, I would not give global points for each config as would be an insane inflation of points because of dozens of new categories. Instead we should group those configurations in an unified ranking. The easiest way would be to just count all existing cores again. So in the above example all those configurations go into 8 cores ranking. IMO that would be fair. No one tells that you have to win with a CPU featuring 50 % efficiency cores over a CPU with 100 % performance cores. However if we want to change something, another approach would be to divide the amount of efficiency cores by two. 4 + (4/2) = 6 cores ranking (for Intel this would also mean 12 threads vs 12 threads, doesn't matter for ARM however) 2 + (6/2) = 5 cores ranking 1+1+(6/2) = 5 cores ranking Wouldn't be to hard to configure those new CPUs with some cores less in the db. So really a quick and dirty solution. Biggest concern is when efficiency cores are getting better than Rocket Lake and Zen3 because of architectural improvements or changes like added HT or Quad HT. To pick up the idea with splitting categories into low, mid, high and high end we might could come up with grouping existing categories in an unified global points ranking. Like 1 core 2 cores 4 cores (consisting of 3 core ranking and hybrid variations) 6 cores (consisting of 5 core ranking and hybrid variations) 8 cores (also including possible 7 cores and hybrid variations) 12 cores (anything from 9 to 12 and hybrid variations) 16 cores (anything from 13 to 16 and hybrid variations) 24 cores (anything from 17 to 24 and hybrid variations) 32 cores (anything from 25 to 32 and hybrid variations) 64 cores (anything from 33 to 64 and hybrid variations) Low core count categories are kept for historical reasons. 3 and 5 cores are getting killed as they are only Phenom and doesn't qualify for globals anymore IMO. Anything from 64 is server stuff and hasn't much to do with oc. It shouldn't be awarded just because someone works in a data center.
  21. I can understand the confusion and suspect a CPU-Z bug. VT8368 is the part number of KT400. CPU-Z correctly shows KT400 but also VT8377 which would be wrong, as its the part number of KT600. If the problem is still there we might need to report this to Franck.
  22. I've digged a little deeper on waybackmachine and while it seems that EVGA was not very creative with names in the beginning, Ive finally came up with this: https://hwbot.org/hardware/motherboard/nforce4_sli_edition_uatx_131_k8_nf44_ax/ Ive cleaned all EVGA boards while I was at this.
×
×
  • Create New...