Jump to content
HWBOT Community Forums

Strunkenbold

Crew
  • Posts

    2204
  • Joined

  • Last visited

  • Days Won

    37

Posts posted by Strunkenbold

  1. You're correct, the two Carrizo FM2+ CPUs were indeed missing. I guess the GPU is Wani, can you show me a picture with latest GPU-Z version?

    edit: Seems like GPU-Z is reporting different with each different version:

    1.16 = Wani
    2.16, 2.2.9 = Carizzo
    2.43 = Bristol

    Will need to come with an idea to solve this.

    edit2: GPU-Z reads out different chip revision but your late Carrizo CPUs have rev E6 like Bristol Ridge. Probably need to merge those categories.

    edit3: Ok, the real deal is that GPU-Z has a bug. Early versions reported Wani as GPU name, then they changed this when they began reading out chip revision and select Bristol or Carrizo. This works for almost all GPUs but rev E2 and E6 can be Bristol or Carrizo at the same time. This probably means that dividing Wani into Bristol or Carrizo doesnt make sense and its better to reunite them.

    edit4: Created thread over TPU to report the bug.

    edit5: No update by author of GPU-Z. I changed now all category names from Wani to Carrizo or Bristol.

    • Thanks 1
  2. 3 hours ago, Leeghoofd said:

    Hwbot took the decision once you disable all the E cores you fall into eg 12900k(8p) category. Seems pretty easy to understand and logic.

    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.

    • Like 1
    • Thanks 1
  3. 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.

    • Like 1
  4. 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. 

    • Thanks 2
×
×
  • Create New...