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 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
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 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
you can decompile it so its not as scary as assembly but its still scary enough 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
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...
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?
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.