I'm wondering if the offset is being applied in the original bios at all, because gpu-z did not read -6.25mv with that bios. But with the modded bios it does read -6.25mv
Software reading is inaccurate, for example even with -6.25mV on VDDCI with both my cards VDDCI in GPU-Z is 1.000V. Once offset removed it's still 1.000V but I could see differing VDDC at DPM 0 in monitoring. Also I get slightly differing readings between HWiNFO & GPU-Z.
Only way to truly know is see i2cdump & voltageobjectinfo.
Just as another bit of info I was reading buildzoid's blog and when he measured MVDDC (memory voltage) at idle it's 1.5V but under load can droop to 1.4xxV (readings taken by DMM.
How did you went about your "mod stage 1" ?
In the tutorial, in the cases where the offset is in the chip it self, you only say:
2. Take into account the offset when doing voltage changes in powerplay table.
Mod stage 1 I have done by editing VoltageObjectInfo, as only cracked coding this couple weeks ago.
At the time of writing tutorial in OP / quoted text from there:-
a) I was unaware of this extra dual voltage offset in memory of IR3567B (register 26)
b) it was written in the context of VDDC only offset in memory of IR3567B (register 8D)
You may have seen post on page 135
. How The Stilt has got +25mV VDDC & -6.25mV VDDCI for my card is:-
Register 26 = -6.25mV VDDC & VDDCI
Register 8D = +31.25 mV VDDC
Register 8E = 0mV VDDCI
(from i2cdump in that post, register = also offset location in i2cdump)
Thus complete outcome = +25mV VDDC & -6.25mV VDDCI
At the moment putting a tutorial regarding VoltageObjectInfo is dangerous IMO, firstly people can remove/change:-
i) VDDCR limit (OCP) ie max VDDC settable
ii) VDDCI limit
iii) meddle with voltage offsets
iv) switching frequency of VRM
v) Load Line calibration ie VDROOP between set VID & drooped/read VDDC
So you can see from above why The Stilt didn't wish to go into revealing VoltageObjectInfo "stuff" plus NDA.
Mod stage 3 helped me with my Vapor-X and is helping with Tri-X, it will also aid desktop use not going to MAX RAM clock, etc, so defo plus in my book to do.
Yep really enjoying the Tri-X 290, done over 12hrs continuous f@h at mod stage 3 now. Tonight gonna do 390MC+RAM timings mod, then next stage will be use the latest official bios I have for that card to see if it gain anything. Finally will also try a 390 ROM with mods, as I couldn't with Vapor-X 290X. Due to the custom PCB, on every attempt just blackscreening with a 390X ROM, even if made it more "compatible".
Hoping to add a good result to the nVida Vs AMD fanboy compo
No worries posting question here
. Do post in owners club as well to see if another has experienced this issue and perhaps they may state how resolved. That thread gonna have more subscribers / viewers that maybe able to share something.@rt123
, glad your happy and getting boost, thanks for feedback
Any chance of some performance stats between stock vs 390MC versions? when you have time
You Samsung IC owners are rare plus Lightning
In a non UEFI ROM you won't find GOP, you'd still have to "adjust" ROM to make HD7xxx Series UEFI Patch Tool BETA fix checksum / keep to correct size of ROM.
I just did a non UEFI 390MC mod for a Sapphire forum member. Due to VRAM_Info being larger than the stock one, I removed length 47h bytes at end of ROM. (Anyone else reading this, other edits were done as per info in OP regarding 390MC mod)
Depending on size of unknown area in ROM/data/command tables I can't state to you where a non UEFI ends data wise exactly. I can only tell by viewing ROM or having tables list for ROM.
You see after all those "elements" end, it's padded out to 10000 (ie last byte of data is FFFF) by empty data. When flashed and dumped it will become length 20000 (ie last byte is 1FFFF), again padded out (ie 00 or FF in this context). If working on a dumped ROM you can just trim off 47h bytes in the context of what I did for the Sapphire member. If a size reduction occurred due to mod you can add empty bytes to correct size.
Just as added info, in UEFI ROM the module will begin at 10000 and after it's data ends it's padded out to 20000 (ie 1FFFF is last byte data wise).
I hope I make sense with my explanation
, I will add to OP if it did?Edited by gupsterg - 2/12/16 at 12:18pm