Jump to content
HWBOT Community Forums

cbjaust

Members
  • Posts

    646
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by cbjaust

  1. It's this one: http://hwbot.org/submission/3939629_cbjaust_gpupi_for_cpu___100m_pentium_4_3.2ghz_(prescott)_12min_37sec_485ms and the problem is GPUPI 3.1.1 picks up my mainboard as something it is not. (DH100 or something...) It should be a LanParty Pro 875B and I think that once the result goes in the chipset gets hard coded or something and so amount of adding the correct name gets the dropdown box to show up with the correct selection. Anyway thanks in advance.

  2. Of the four Phenom II CPUs in the hwbot database that are chip harvested Thuban cores: x4 650T, x4 840T, x4 960T Black Edition and x4 970 Black Edition, only two are categorised as Zosma (960T and 970 BE) the other two are categorised as Thuban. Obviously this leads to ambiguity, either all the above mentioned CPUs are classed as Zosma or they are classed as Thuban but not both. Now I know our erstwhile database caretaker has recently resigned which leads to a bit of a dilemma.

    • Like 1
  3. 38 minutes ago, Strunkenbold said:

    Yes I remember there was something similar with those unlocked Haswell mobile CPUs. You have to prevent that Windows loads the intel firmware on boot.

    I dont think that you need to implement the fix in GPUPI. All needed is the patch exe from the passmark guys.

    To quote their readme:

    This is reminds me of The Stilts Bulldozer Conditioner...

    All we need is someone to test if it really works.
    I think I have somewhere a board and a CPU both from scrap and not known to work maybe its time to test this bundle now.

    The patch when implemented immediately sets the performance back to "normal" :( Rerunning the patch and selecting no to the workaround gets back the mad performance. :)

     

    • Thanks 1
  4. 6 hours ago, unityofsaints said:

    Thanks for all the time you spent investigating this! ? It would be funny to submit a bug report with AMD just to see their reaction.

    Are you using Win 7 64-bit SP1, AMD SDK 2.91 and GPUpi 3.2 non-legacy with HPET off?

    Not sure if it's HPET or some Windows Update making the performance "Normal" but a fresh 2008 R2 install and the F2 BIOS on the GA-A75-D3H did the trick. I was using a pretty much up to date Windows 7 x64 install before and had HPET on. So yeah. Interesting that you stumbled on to this mad performance and great work by _mat_ verifying his softwares.

  5. Well I probably need some kind of guide for newbies because with older CPU's that should be supported by OpenCL and AMD's APP I can never get them recognised, not to mention the difficulty locating AMD's earlier SDK versions. Most of the time I'm just glad GPUPI recognises the CPU and runs. You've got a neat benchmark but it's annoyingly frustrating to just get working.

  6. I tried my socket 478 system again for Team Cup DDR Stage 3 and this time I tried 3.1.1 but it has the same issues with crashing on the HWINFO.dll module when starting the benchmark. So I deleted HWINFO.dll and the bench ran fine but at the end it had the same crash as 3.2 on module "StackHash_0a9e".

    I also tried 3.2 again but trying to save still crashed with the "StackHash_0a9e" module.

    Help!

    Cheers

    Edit: 2.3.4 works just fine, result file attached.

    cbjaust_GPUPI_for CPU_100M_12m-49.578s.result

  7. 3 hours ago, yosarianilives said:

    In the database they are listed as Grenada even though they're Hawaii. As there would need to be hw purchased I'd like to verify before hand. 

    Yeah true, GPU-z identifies R9 390X as Hawaii though. I consider them to be Hawaii.

    2 hours ago, ozzie said:

    280  is tahiti, not hawaii, 285 is tonga, 290 is hawaii, ,

    that's what I said, didn't I? ?

×
×
  • Create New...