Force radeon driver to allow DP fullspeed

Discussion in 'Videocards - AMD Radeon' started by OneB1t, Mar 15, 2016.

  1. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    Force radeon driver to allow DP fullspeed or CU unlock

    there must be some way to fool AMD driver into full speed double precision calculations (and maybe force unlock CUs as well)...

    i know which memory location is used for this "performance crippling" but need to get better experience with atikmdag.sys dissasembly to see what exactly is going on..

    can someone help me with it? here are some parameters from gpu initialization
    [​IMG]

    from what i understand there are some offsets to read/write to physical memory allocated at 0x00000000FEA00000

    this position can be readed/writed from AIDA64 or RW everything
     
    Last edited: Mar 16, 2016
  2. OnnA

    OnnA Ancient Guru

    Messages:
    4,501
    Likes Received:
    327
    GPU:
    Fiji-X HBM 1120/575
    Great.
    Unlocking True Power of Radeon GPU's !
     
  3. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    here is my physical memory copy for 290X
    http://pastebin.com/aVYJCdQ8
    i also have some offsets to it
    0 = gpu ID
    0x089BC = F8000005 [SE0 SH0] // this is unlock status of GPU last byte is DP speed
    05= 1/8
    01= 1/2
    0x089C0 = 00000000 [SE0 SH0] // software mask (on some 290 make card unlockable)

    if we found which part of kernel driver reads this part of memory i think there is big chance to unlock card performance :D problem is that kernel driver is pretty big and also i dunno how to debug it while its running (some ideas?)

    there is no way to modify this memory as far as i know (allready tryed with modified VBIOS and RW everything...) so other way is to hack driver
    also in this part of memory there are alot of sensor values and settings which are normally hidden from user
     
    Last edited: Mar 16, 2016
  4. vase

    vase Ancient Guru

    Messages:
    1,653
    Likes Received:
    1
    GPU:
    -
    i like where this is going.

    how can we contribute.

    i am not familiar with any assembler like code.
     

  5. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    you can decompile it so its not as scary as assembly but its still scary enough :D

    second problem is that im also not that good with dissasemblers so it will prolly take some time if noone smarter will not come to help :)
     
  6. nav-jack

    nav-jack Master Guru

    Messages:
    254
    Likes Received:
    0
    GPU:
    980 ti 1520/2000
    i love where this is going. i'm not smarterer enough for this stuffs though guize
     
  7. hzhang

    hzhang New Member

    Messages:
    1
    Likes Received:
    0
    GPU:
    R9 280X / 3GB
    I can confirm that the bit you mentioned is correct by analyzing the opensource AMDGPU driver:

    http://lxr.free-electrons.com/sourc...include/asic_reg/gca/gfx_7_2_sh_mask.h#L15579

    Code:
    #define CC_GC_SHADER_ARRAY_CONFIG__DPFP_RATE_MASK 0x6
    #define CC_GC_SHADER_ARRAY_CONFIG__DPFP_RATE__SHIFT 0x1
    The register CC_GC_SHADER_RATE_CONFIG is 0x226f * 4 = 0x89bc. According the mask and shift, the second and third bits are controlling the DPFP_RATE.

    Also it is confirmed by another source:

    http://www.gpugrid.net/forum_thread.php?id=3607&nowrap=true#34852


    Interestingly, for later generations, the register moved to 0x2312 (CC_GC_SHADER_RATE_CONFIG) and 0x2313 (GC_USER_SHADER_RATE_CONFIG):

    http://lxr.free-electrons.com/source/drivers/gpu/drm/amd/include/asic_reg/gca/gfx_8_1_d.h#L1976 (search for mmCC_GC_SHADER_RATE_CONFIG)
    http://lxr.free-electrons.com/sourc...include/asic_reg/gca/gfx_8_1_sh_mask.h#L13989 (search for DPFP_RATE)


    I disassembled the fglrx driver for 64-bit linux, also searched in the source code of the AMDGPU driver. However, I didn't find anywhere in the drivers that reads the second and third bits of the register CC_GC_SHADER_ARRAY_CONFIG. The only place the driver accesses this register is in function gfx_v7_0_get_cu_active_bitmap() (or the funcion get_cu_active_bitmap() in the closed source fglrx driver, which basically has the same logic based on disassembly), and it simply reads the CU masks and don't handle DPFP_RATE bits at all:

    http://lxr.free-electrons.com/source/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c#L3855

    Basically, only the higher 16 bits are used, and bit 1 - 11 consist of a mask indicating how many CUs are enabled. Bits 12-16 are always 1. If a bit is set to 1, 256 CUs are disabled. On locked R9 290, these bits are 0xf801, and on R9 290X and unlockable R9 290, they are 0xf800. It explains why you can unlock some R9 290s because their CUs are not locked by the fuse.

    My current conclusion is that the driver cannot control the DP rates; once the bits on GPU are fused, the DP units run at a lower rate regardless what driver you use. I hope I am wrong...
     
  8. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    ok what about bios itself? there is ATOM table inside which these registers are readed (maybe we can point to different part of memory which will contain 0x00 not 0x05?
     
  9. user1

    user1 Master Guru

    Messages:
    805
    Likes Received:
    99
    GPU:
    hd 6870
    I hate to break it to you but that guy hasn't logged in for nearly 2 years ,

    Also a vbios mod will not unlock full DP, it is controlled with HW bits, I've read there is a way to override this ,but it requires special tools that are under NDA.
     
  10. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    tools under NDA do the same thing as i can do :D problem is just to which part requires mod
     

Share This Page