Dies ist der offizielle Overclocking & Modding Thread für RDNA 4, aktuell mit den Modellen RX 9070 XT und RX 9070. Weitere Modelle sind angekündigt und werden folgen!
Dieser Thread ist für die Diskussionen aller, die MEHR Leistung wollen, sei es durch Overclocking (OC) oder Overclocking durch Undervolting (OCUV). Bitte in der Nähe des Themas bleiben – aber ähnlich wie bei den RDNA2 und RDNA3 OC-Threads wird man auch mal das ein oder andere Auge zudrücken, wenn sich die Community hier unterhält.
Tuning Tools & Wissen, Informationsquellen
Von Benik3 entdeckte versteckte Befehle:
--skip-ssid-check
--flash-both-partitions
--fs
-f
--force
--force-recovery-path
Nicht-versteckte Befehle
Debug logging related options:
--debug-log-status arg
(Optional)This switch enables debug logging.
By default debug logging is enabled.
Usage:
Enable Debug Logging:
--debug-log-status=true
Disable Debug Logging:
--debug-log-status=false
--debug-log-options
Lists the debug logging options for the tool. Usage: --debug-log-options
--debug-log-filename arg
(Optional) Specifies the name of the debug log file name. The tool shall use this name suffixed with a number, where the number indicates an incrementing number indicating each instance of the binary. Be default the help file name starts with the name of process. Usage: --debug-log-filename=[Filename]
--debug-log-filepath arg
(Optional) Specifies the location of the debug log file path. If this is empty or not specified then the following folders shall be used for generating debug log files: Windows: %APPDATA%\\AMD folder
ESXi: <datastore>/AMD/Logs/
Linux: /var/log/AMD
Usage: --debug-log-filepath=[Filepath]
--debug-log-filesize arg
(Optional)Specify the size of the Log file in MegaBytes (MB). 1 to 50. Defaults to 40 MB.
Usage: --debug-log-filesize=[Size in MB]
--debug-log-filepolicy arg (Optional)Specify the policy to use when the
log file size hits the size limit.
Valid values are NEWLOG and REUSE. Defaults to
NEWLOG
NEWLOG(1): Generates a new log file
REUSE(2): Continues using the same file
(will start writing from the
begining)
Usage:
--debug-log-filepolicy=NEWLOG
--debug-log-filepolicy=REUSE
Generic options:
--version Show the version of the binary.
Usage:
--version
-h [ --help ] [=arg(=ALL)] Displays this help text if no argument is
specified. If an argument is specified then
the help for the specified command is shown.
Usage:
--help/h/?
--help/h/? <command>: --help
debug-log-filepolicy
--? [=arg(=ALL)] Displays this help text if no argument is
specified. If an argument is specified then
the help for the specified command is shown.
Usage:
--help/h/?
--help/h/? <command>: --help
debug-log-filepolicy
--show-progress Shows progress for any long activity the tool
does. Can be used along with any command.
Usage:
--show-progress
--silent
The tool operates silently without
displaying any noticeable output except for
the primary outcome. Can be used along with
any command.
Usage:
--silent
--accept-EULA Accept the EULA agreement. You can see the
EULA by --show-EULA.
Usage:
--accept-EULA
-e [ --show-EULA ] Shows the EULA for the tool
Usage:
--show-EULA
Options related to the console:
--cls Clear the screen
Usage:
cls
--exe arg Load and execute macro file (db32 script)
Usage:
exe [ScriptName]
--open arg Open a file to log the session activities
until the close command. Additionally multiple
open commands will redirect the console
activity to the last opened file.
Usage:
open [File]
--close Closes the last opened session log file.
Usage:
close
--flush Flushes the text to the last opened session
log file.
Usage:
flush
Common tool ptions:
-i [ --device ] [=arg(=-132)] ASIC on which the operation has to be
performed. This is a 0 based index.
Usage:
--device/-i=0
: Specifies ASIC at index 0
--device/-i=0,1
: Specifies ASICs at index 0 and 1
--device/-i=-1
: Specifies to work on all ASICs
detected
--device/-i
: Same as above i.e., specifies to
work all ASICs detected
-a [ --advanced ] When this flag is specified, it tells the tool
to work in advanced mode. The work will depend
on the tool. This has to be used along-with -i
option
Usage:
--advanced/-a
: Work to show/perform advanced
operations
--advanced --device/-ai:
: Work to show/perform advanced
operations
--show This flag instructs the tool to show
information. What information is to be shown
is specified by the other switches.
Usage:
--show --device
: Show device inforamtion
--show --device --advanced
: Show advanced device inforamtion
Command line switches for the flash capability:
-s [ --save ] arg This flag instructs the tool to save the VBIOS
image. This has to be used along-with the
--device switch and the --vbios-info. If
--vbios-file is not specified then the file
name is constructed at run time with the
following format [ASIC]_[BDF]_[Index].rom
-p [ --flash ] arg Write VBIOS image in file <file> to flash ROM
in ASIC <Num>.
Usage:
-p <Num> <File>, or
--flash --device [Num] --vbios-file <File>
--vbios-info This flag when used along with --show flag
instructs the tool to show the VBIOS
Information from the file specified by using
the --vbios-file option
--vbios-file arg Specify the VBIOS file to work with. This
option can be used to save the VBIOS image to
this file as well as to read VBIOS image from
this file
--bios-file-info arg Display the BIOS info in the given file
--ifwi-version This flag when used along with --show flag
instructs the tool to show the version of the
IFWI. This flag should always be used with
--device command.
Usage:
--show --ifwi-version --device [Num]
--pspbl-version This flag when used along with --show flag
instructs the tool to show the version of the
PSP Boot Loader Version. This flag should
always be used with --device command.
Usage:
--show --pspbl-version --device [Num]
--savefile-at-end This flag instructs the tool to save the whole
VBIOS content read from the ROM Controller at
the end of read operation. This should always
be used only with --save flag. If not used, by
default the tool keeps writing ROM contents
read in each iteration to the file.
--save-flashed-bytes This flag instructs the tool to save the bytes
being flashed to the SPIROM to a file for
debugging purpose. This will enable the user
to additionaly verify what and how many bytes
have been written to the SPIROM at the end of
flash operation. This flag should always be
used with --flash command only. If not used,
by default the bytes won't be additionally
saved to a file.
--active This flag is used along with -ai command to
show the ACTIVE partition details i.e.
Partition where dGPU is booted from.
Usage:
-ai [Num] --active, or
--advanced --device [Num] --active
--inactive This flag is used along with -ai command to
show the INACTIVE partition details i.e.
Partition which would be targeted to be
flashed.
Usage:
-ai [Num] --inactive, or
--advanced --device [Num] --inactive
--fa This flag enables force flashing the same IFWI
version. Should be used with the --flash
switch.
Usage:
-p <Num> <File> -fa, or
--flash --device [Num] --vbios-file <File>
--fa
--fp This flag instructs the tool to bypass BIOS
part number check and perform a force flash.
This flag should always be used with --flash
command only.
Usage:
-p <Num> <File> -fp, or
--flash --device [Num] --vbios-file <File>
--fp
--fv This flag enables downgrading the IFWI by
performing a force flash. This bypasses
checking the VBIOS/IFWI version. This flag
should always be used with --flash command.
Usage:
-p <Num> <File> -fv, or
--flash --device [Num] --vbios-file <File>
--fv
--checkpn arg Compare Part Number of the current IFWI in the
device with the Part Number in the IFWI image
specified.
Usage:
--/-checkpn <Num> <File>, or
--/-checkpn --device <DeviceIndex>
--vbios-file <IFWI Image>
--cr arg Calculates the 16-bit ROM checksum for device
<Index> of size if size is specified and
compare with sum if expected sum is specified.
Usage:
-cr <Num> <size> <sum>, or
--cr --device [Num] <size> <sum>
--complete This flag instructs the tool to calculate
checksum of Complete IFWI.This flag should be
used with --cr/--cf command only.
Usage:
-cr <Num> <size> <sum> -complete, or
--cr --device [Num] <size> <sum>
--complete
--biosimage This flag instructs the tool to calculate
checksum of VBIOS image in IFWI.This flag
should be used with --cr command only.
Usage:
-cr <Num> <size> <sum> -biosimage, or
--cr --device [Num] <size> <sum>
--biosimage
--cf arg Calculate 16-bit checksum for file <File> and
if expected checksum has been specified then
compare the calculated checksum with the
specified checksum.
Usage:
-cf <file> <sum>, or
--cf --vbios-file <File> <sum>
--pa arg Write the VBIOS image in the given image file
to all applicable ASICs.>.
Usage:
-pa <file> or
--pa --vbios-file <File>
--padevid arg Flash the VBIOS Image to ASIC which matches
the specific Device ID. This command should be
used along-with the -pa switch and also can be
used along-with other -pa switches like
(-pasvid, -pavbpn -passid).>
Usage:
-pa <file> padevid <id>
-pa <file> padevid <id> passid <id>
--pa --vbios-file <File> padevid <id>
--passid arg Flash the VBIOS Image to ASIC which matches
the specific Subsystem ID. This flag should be
used with --pa switch and also can be used
along-with other -pa switches like (-padevid,
-pasvid, -pavbpn).>
Usage:
-pa <file> passid <id>
-pa <file> passid <id> padevid <id>
--pa --vbios-file <File> passid <id>
padevid <id>
--pasvid arg Flash the VBIOS Image to ASIC which matches
the specific Subsystem Vendor ID. This flag
should be used with --pa switch and also can
be used along-with other -pa switches like
(-padevid, -passid, -pavbpn).>
Usage:
-pa <file> pasvid <id>
-pa <file> pasvid <id> padevid <id>
--pa --vbios-file <File> pasvid <id>
padevid <id>
--pavbpn arg Flash the VBIOS Image to ASIC which matches
the specific PartNumber. This flag should be
used with --pa switch and also can be used
along-with other -pa switches like (-padevid,
-pasvid, -passid).>
Usage:
-pa <file> pavbpn <part number>
-pa <file> pavbpn <part number> pasvid
<id> padevid <id>
--pa --vbios-file <File> pavbpn <part
number>
--checkifwi arg Compare SHA256 hash value of active partition
of the specified device with the SHA256 hash
value of the partition in the IFWI image
specified.
Usage:
--/-checkifwi --device <DeviceIndex>
--vbios-file <IFWI Image>, or
--/-checkifwi --device <DeviceIndex>
--vbios-file <IFWI Image> --inactive
Common tool Options:
--no-workload-execution This flag instructs the tool not to execute
workloads to prevent the GPU from going to a
Low Power State. When specified, the tool will
perform operations without running any
workload. This can be useful in scenarios
where running workloads is not desired or
required for example collecting PM Logs when a
GPU related benchmark/stress application is
also running.
Benchmark Ergebnisse
ShirKhan's Steel Nomad Rangliste @ HardwareLuxx
MrH Open CL Benchmark @ HardwareLuxx
✵✵✵ ✵✵✵ ✵✵✵ ✵✵✵
Tuning Anleitung von @oese: BIOS flash, EVC2, shunt mod
The tutorial was written in English by Oese for our international friends.
Oese: Ok, so a first introduction to 9070 XT modding with a) BIOS flash and b) EVC2 and c) shunt mod.
Resumé:
Benching with the shunt mod and EVC2 is great fun. It just feels different without TBP limits. The clocks slider actually does something, UV still helps to hold temps low and using EVC to dial in TGP and VID’s is quite interesting to do. Many, many opportunities.
If you only use shunts and no EVC2, cooling will result in lower GPU core current and TGP also, so UV and outdoor/balcony sessions will help to improve scores anyhow. At the moment I cannot use higher TGP via the EVC2 due to temperature (hotspot) limitations. Benching outside, TGP and current limits are several % away from 100% when hotspot temp kicks in and lowers my scores, so that’s that.
With the ASUS Prime OC, which is a great card with very good voltage regulation, a lot of capacitors out of the box, 3x8 pin and a dual BIOS, I feel this is the best low-budget tuning card, but it will need water to shine! And maybe the Taichi and XFX Mercury OC has better binned GDDR?
It will be interesting how the cards behave with better cooling, if TGP and current protection will be useable or result in stutter. So far, with reduced max boost clock the card is much useable and frames feeling absolutely smooth, possibly due to lower TBP restraints and less clock dips.
Tonight I will try the quiet BIOS if it has lower TGP/current limits build in but I doubt it..
Have fun tweaking and generating scores!
✵✵✵ ✵✵✵ ✵✵✵ ✵✵✵
Dieser Thread ist für die Diskussionen aller, die MEHR Leistung wollen, sei es durch Overclocking (OC) oder Overclocking durch Undervolting (OCUV). Bitte in der Nähe des Themas bleiben – aber ähnlich wie bei den RDNA2 und RDNA3 OC-Threads wird man auch mal das ein oder andere Auge zudrücken, wenn sich die Community hier unterhält.
- Radeon RX 9070 XT: AMD / TPU (GPU Database) / ✵ TPU offizielle (BIOS Collection) / TPU unverified (BIOS collection)
- Radeon RX 9070: AMD / TPU (GPU Database) / TPU offizielle (BIOS Collection) / TPU unverified (BIOS collection)
Tests
OC-Threads
Themenspezifische Threads
Laberthreads & Sammlungen
- HardwareLuxx Test: ASUS TUF Radeon RX 9070 OC, ASUS TUF Radeon RX 9070 XT OC, Powercolor Hellhound Radeon RX 9070, Powercolor Red Devil Radeon RX 9070 XT, Sapphire Nitro+ Radeon RX 9070 XT
- PCGH Test: Sapphire Nitro+ AMD Radeon RX 9070 XT Gaming OC, XFX Quicksilver Radeon RX 9070 XT Magnetic Air Edition, Gigabyte Radeon RX 9070 XT Gaming OC, Sapphire Pulse Radeon RX 9070 XT Gaming, Asrock Radeon RX 9070 XT Taichi, Sapphire Pulse Radeon RX 9070 Gaming, XFX Quicksilver Radeon RX 9070 OC Gaming Edition, Asrock Radeon RX 9070 Steel Legend OC
- PCGH Nachtest der 9070 XT mit aktuellen Treibern vom Juni '25
- Computerbase Test: ASRock Radeon RX 9070 XT Taichi OC, Asus Radeon RX 9070 XT TUF Gaming OC, Sapphire Radeon RX 9070 XT Pure, Sapphire Radeon RX 9070 XT Nitro+, XFX Radeon RX 9070 XT Mercury OC Magnetic Air RGB
- Igor's Lab Test
- Tech Power Up mit einer Liste internationaler Sammlung Reviews vieler RDNA4 Karten
- HardwareLuxx: 9060 XT OC-Modelle und 9060 XT Reaper
- PCGH Test der 9060 XT
- Igor's Lab Test von 2 Modellen der 9060 XT (Nitro+, Swift)
OC-Threads
- ✵ OCN Sammeltrhead
- Computerbase: dortiger OC-Thread
Themenspezifische Threads
- HardwareLuxx Sammelthread zum Spulefiepen dieser Karten
Laberthreads & Sammlungen
- PCGH Sammlung "Alles zur 9070 XT"
- Hardwareluxx Smalltalk
- PCGH Laberthread
Tuning Tools & Wissen, Informationsquellen
- ✵✵ Red Bios Rebellion Team
- ✵ MCT (More Clock Tool), Alternative zum Adrenalin Treiber
- MSI Afterburner, weitere alternative zum Adrenalin Treiber
- Radeon Slimmer zum Abspecken des Adrenalin Treibers
- AMD RDNA4 / RX9000 - Wasserkühler & 9070XT VRM List @ HardwareLuxx
- ✵ EVC: EVC-Thread zu RDNA2, EVC Screen mit Oeses 9070 XT, Formcodierung I2C Lötpunkte
- DDU (Display Driver Uninstaller), Tool zum sauberen Entfernen von Treibern
- Google Sheet mit Modellvergleich 9070 XT und ein anderes Google Sheet und noch eins
- ✵ Vulkan Memtest zum Check wann die Fehlerkorrektur voll zuschlägt, der MrH Benchmark (siehe unten) kann das im Prinzip auch -> Anwendungsbeispiel #1 (ShirKhan) und #2 (RedF)
- CH34A1 Hardware Programmierer Thread (Bios Flash) - hier im Luxx
- OCN: Recherchebeitrag zu Shunts und anderen Komponenten auf verschiedenen 9070 XT
- PCGH: Gurdi hat das XT Bios auf eine non-XT geflasht (Beitrag + etliche folgende)
- Igor: ersetzt die VRAM Pads durch Putty
- ✵ OCN: Hardware Flash-Anleitung für non-XT zur XT
- ✵ PCGH PLUS (Paywall): Gurdis Hardware Flash Anleitung nonXT zur XT
- ✵ Igor's Lab: hellms aktuellste Aussage zum Thema I2C @ Linux (01.05.) + Linux on the go + aktueller Stand bzgl. "Linux-MPT" (von hinten her lesen
- Modifizierte Version von Benik3 auf OCN
- Gurdis Headliner bei Igor, Gurdis Headliner bei PCGH
- meine X-Flash Tabellen als Google Sheet (XT->XT, non-XT->XT)
Von Benik3 entdeckte versteckte Befehle:
--skip-ssid-check
--flash-both-partitions
--fs
-f
--force
--force-recovery-path
Nicht-versteckte Befehle
Debug logging related options:
--debug-log-status arg
(Optional)This switch enables debug logging.
By default debug logging is enabled.
Usage:
Enable Debug Logging:
--debug-log-status=true
Disable Debug Logging:
--debug-log-status=false
--debug-log-options
Lists the debug logging options for the tool. Usage: --debug-log-options
--debug-log-filename arg
(Optional) Specifies the name of the debug log file name. The tool shall use this name suffixed with a number, where the number indicates an incrementing number indicating each instance of the binary. Be default the help file name starts with the name of process. Usage: --debug-log-filename=[Filename]
--debug-log-filepath arg
(Optional) Specifies the location of the debug log file path. If this is empty or not specified then the following folders shall be used for generating debug log files: Windows: %APPDATA%\\AMD folder
ESXi: <datastore>/AMD/Logs/
Linux: /var/log/AMD
Usage: --debug-log-filepath=[Filepath]
--debug-log-filesize arg
(Optional)Specify the size of the Log file in MegaBytes (MB). 1 to 50. Defaults to 40 MB.
Usage: --debug-log-filesize=[Size in MB]
--debug-log-filepolicy arg (Optional)Specify the policy to use when the
log file size hits the size limit.
Valid values are NEWLOG and REUSE. Defaults to
NEWLOG
NEWLOG(1): Generates a new log file
REUSE(2): Continues using the same file
(will start writing from the
begining)
Usage:
--debug-log-filepolicy=NEWLOG
--debug-log-filepolicy=REUSE
Generic options:
--version Show the version of the binary.
Usage:
--version
-h [ --help ] [=arg(=ALL)] Displays this help text if no argument is
specified. If an argument is specified then
the help for the specified command is shown.
Usage:
--help/h/?
--help/h/? <command>: --help
debug-log-filepolicy
--? [=arg(=ALL)] Displays this help text if no argument is
specified. If an argument is specified then
the help for the specified command is shown.
Usage:
--help/h/?
--help/h/? <command>: --help
debug-log-filepolicy
--show-progress Shows progress for any long activity the tool
does. Can be used along with any command.
Usage:
--show-progress
--silent
The tool operates silently without
displaying any noticeable output except for
the primary outcome. Can be used along with
any command.
Usage:
--silent
--accept-EULA Accept the EULA agreement. You can see the
EULA by --show-EULA.
Usage:
--accept-EULA
-e [ --show-EULA ] Shows the EULA for the tool
Usage:
--show-EULA
Options related to the console:
--cls Clear the screen
Usage:
cls
--exe arg Load and execute macro file (db32 script)
Usage:
exe [ScriptName]
--open arg Open a file to log the session activities
until the close command. Additionally multiple
open commands will redirect the console
activity to the last opened file.
Usage:
open [File]
--close Closes the last opened session log file.
Usage:
close
--flush Flushes the text to the last opened session
log file.
Usage:
flush
Common tool ptions:
-i [ --device ] [=arg(=-132)] ASIC on which the operation has to be
performed. This is a 0 based index.
Usage:
--device/-i=0
: Specifies ASIC at index 0
--device/-i=0,1
: Specifies ASICs at index 0 and 1
--device/-i=-1
: Specifies to work on all ASICs
detected
--device/-i
: Same as above i.e., specifies to
work all ASICs detected
-a [ --advanced ] When this flag is specified, it tells the tool
to work in advanced mode. The work will depend
on the tool. This has to be used along-with -i
option
Usage:
--advanced/-a
: Work to show/perform advanced
operations
--advanced --device/-ai:
: Work to show/perform advanced
operations
--show This flag instructs the tool to show
information. What information is to be shown
is specified by the other switches.
Usage:
--show --device
: Show device inforamtion
--show --device --advanced
: Show advanced device inforamtion
Command line switches for the flash capability:
-s [ --save ] arg This flag instructs the tool to save the VBIOS
image. This has to be used along-with the
--device switch and the --vbios-info. If
--vbios-file is not specified then the file
name is constructed at run time with the
following format [ASIC]_[BDF]_[Index].rom
-p [ --flash ] arg Write VBIOS image in file <file> to flash ROM
in ASIC <Num>.
Usage:
-p <Num> <File>, or
--flash --device [Num] --vbios-file <File>
--vbios-info This flag when used along with --show flag
instructs the tool to show the VBIOS
Information from the file specified by using
the --vbios-file option
--vbios-file arg Specify the VBIOS file to work with. This
option can be used to save the VBIOS image to
this file as well as to read VBIOS image from
this file
--bios-file-info arg Display the BIOS info in the given file
--ifwi-version This flag when used along with --show flag
instructs the tool to show the version of the
IFWI. This flag should always be used with
--device command.
Usage:
--show --ifwi-version --device [Num]
--pspbl-version This flag when used along with --show flag
instructs the tool to show the version of the
PSP Boot Loader Version. This flag should
always be used with --device command.
Usage:
--show --pspbl-version --device [Num]
--savefile-at-end This flag instructs the tool to save the whole
VBIOS content read from the ROM Controller at
the end of read operation. This should always
be used only with --save flag. If not used, by
default the tool keeps writing ROM contents
read in each iteration to the file.
--save-flashed-bytes This flag instructs the tool to save the bytes
being flashed to the SPIROM to a file for
debugging purpose. This will enable the user
to additionaly verify what and how many bytes
have been written to the SPIROM at the end of
flash operation. This flag should always be
used with --flash command only. If not used,
by default the bytes won't be additionally
saved to a file.
--active This flag is used along with -ai command to
show the ACTIVE partition details i.e.
Partition where dGPU is booted from.
Usage:
-ai [Num] --active, or
--advanced --device [Num] --active
--inactive This flag is used along with -ai command to
show the INACTIVE partition details i.e.
Partition which would be targeted to be
flashed.
Usage:
-ai [Num] --inactive, or
--advanced --device [Num] --inactive
--fa This flag enables force flashing the same IFWI
version. Should be used with the --flash
switch.
Usage:
-p <Num> <File> -fa, or
--flash --device [Num] --vbios-file <File>
--fa
--fp This flag instructs the tool to bypass BIOS
part number check and perform a force flash.
This flag should always be used with --flash
command only.
Usage:
-p <Num> <File> -fp, or
--flash --device [Num] --vbios-file <File>
--fp
--fv This flag enables downgrading the IFWI by
performing a force flash. This bypasses
checking the VBIOS/IFWI version. This flag
should always be used with --flash command.
Usage:
-p <Num> <File> -fv, or
--flash --device [Num] --vbios-file <File>
--fv
--checkpn arg Compare Part Number of the current IFWI in the
device with the Part Number in the IFWI image
specified.
Usage:
--/-checkpn <Num> <File>, or
--/-checkpn --device <DeviceIndex>
--vbios-file <IFWI Image>
--cr arg Calculates the 16-bit ROM checksum for device
<Index> of size if size is specified and
compare with sum if expected sum is specified.
Usage:
-cr <Num> <size> <sum>, or
--cr --device [Num] <size> <sum>
--complete This flag instructs the tool to calculate
checksum of Complete IFWI.This flag should be
used with --cr/--cf command only.
Usage:
-cr <Num> <size> <sum> -complete, or
--cr --device [Num] <size> <sum>
--complete
--biosimage This flag instructs the tool to calculate
checksum of VBIOS image in IFWI.This flag
should be used with --cr command only.
Usage:
-cr <Num> <size> <sum> -biosimage, or
--cr --device [Num] <size> <sum>
--biosimage
--cf arg Calculate 16-bit checksum for file <File> and
if expected checksum has been specified then
compare the calculated checksum with the
specified checksum.
Usage:
-cf <file> <sum>, or
--cf --vbios-file <File> <sum>
--pa arg Write the VBIOS image in the given image file
to all applicable ASICs.>.
Usage:
-pa <file> or
--pa --vbios-file <File>
--padevid arg Flash the VBIOS Image to ASIC which matches
the specific Device ID. This command should be
used along-with the -pa switch and also can be
used along-with other -pa switches like
(-pasvid, -pavbpn -passid).>
Usage:
-pa <file> padevid <id>
-pa <file> padevid <id> passid <id>
--pa --vbios-file <File> padevid <id>
--passid arg Flash the VBIOS Image to ASIC which matches
the specific Subsystem ID. This flag should be
used with --pa switch and also can be used
along-with other -pa switches like (-padevid,
-pasvid, -pavbpn).>
Usage:
-pa <file> passid <id>
-pa <file> passid <id> padevid <id>
--pa --vbios-file <File> passid <id>
padevid <id>
--pasvid arg Flash the VBIOS Image to ASIC which matches
the specific Subsystem Vendor ID. This flag
should be used with --pa switch and also can
be used along-with other -pa switches like
(-padevid, -passid, -pavbpn).>
Usage:
-pa <file> pasvid <id>
-pa <file> pasvid <id> padevid <id>
--pa --vbios-file <File> pasvid <id>
padevid <id>
--pavbpn arg Flash the VBIOS Image to ASIC which matches
the specific PartNumber. This flag should be
used with --pa switch and also can be used
along-with other -pa switches like (-padevid,
-pasvid, -passid).>
Usage:
-pa <file> pavbpn <part number>
-pa <file> pavbpn <part number> pasvid
<id> padevid <id>
--pa --vbios-file <File> pavbpn <part
number>
--checkifwi arg Compare SHA256 hash value of active partition
of the specified device with the SHA256 hash
value of the partition in the IFWI image
specified.
Usage:
--/-checkifwi --device <DeviceIndex>
--vbios-file <IFWI Image>, or
--/-checkifwi --device <DeviceIndex>
--vbios-file <IFWI Image> --inactive
Common tool Options:
--no-workload-execution This flag instructs the tool not to execute
workloads to prevent the GPU from going to a
Low Power State. When specified, the tool will
perform operations without running any
workload. This can be useful in scenarios
where running workloads is not desired or
required for example collecting PM Logs when a
GPU related benchmark/stress application is
also running.
Benchmark Ergebnisse
| 3DMark Leaderboards 9060 XT | |
| 3DMark Leaderboards 9070 XT | 3DMark Leaderboards 9070 |
ShirKhan's Steel Nomad Rangliste @ HardwareLuxx
MrH Open CL Benchmark @ HardwareLuxx
✵✵✵ ✵✵✵ ✵✵✵ ✵✵✵
Tuning Anleitung von @oese: BIOS flash, EVC2, shunt mod
The tutorial was written in English by Oese for our international friends.
Oese: Ok, so a first introduction to 9070 XT modding with a) BIOS flash and b) EVC2 and c) shunt mod.
A BIOS flash is only possible via the hardware flasher CH341a. I used Version 1.7, but older versions are also possible with the 1.7v module. It is an easy and quite safe mod, however due to power limit restrictions not far apart in the different models it only helps in gaining few more points in benchmarks, real world performance uplift is low to barely noticeable but at the cost of higher temperatures and power consumption.
Cards with the highest power target use a 340W BIOS, so I looked for cards that come with 340W max TBP (total board power). From my experience with the 7900 XTX I knew that flashing a BIOS with different output connectors could result in connectors not working, so the BIOS to look for was a 3xDP + 1xHDMI card with a 340W BIOS.
I picked the Taichi BIOS since those criteria were met. The BIOS chips on the ASUS Prime OC 9070 XT are on the back side of the card, thus, easily accessible without removing the cooler as the backplate of this card may just be removed. With a Sapphire Pure I didn’t have this luck before since that card had a backplate bolted to the PCB with screws that were only accessible from the front side so the cooler needed to be removed.
Performance BIOS on this card was on the side of the respective BIOS switch position, right one or U3 in that picture below.
The BIOS chip on my card was a Gigadevice GD25LB16ETJG, seemingly SPI_NOR, which is not known by NeoProgrammer. For flashing, I connected the 8-pin clamp to the BIOS IC. It is important to match pin 1 which is indicated by a small pit on the chip. Don’t be irritated by the color markings on the chip! However, certain ranges of chips often use similar commands for unlock, erase and write so I gave it a try. Pick an IC profile that has the same capacity (indicated here by “16”). Somehow though I got weird errors opening BIOS files in NeoProgrammer, so I switched to AsProgrammer. That program does not provide chip detection. So I used NeoProgrammer to check if the clamp had proper connection to the chip and then AsProgrammer for getting the work done. There were 2 profiles available for a 25 type chip with 16 Gbit. I tried the first GD 25Q16 which did not work so I tried the second.
I finally succeeded applying the IC Profile GD 25Q16B in AsProgrammer.
In AsProgrammer, unlike NeoProgrammer, the steps of unlocking, erasing, writing and verifying need to be made manually, so I did this in that order. Verification succeeded finally (unlike the other GD25Q16 profile) so I tried booting the card.
Hurray, the card booted with performance BIOS enabled and showed ASRock as manufacturer which indicated the new BIOS taken from the ASRock Taichi stored at TPU BIOS library.
Using HWInfo64 and Benchmarks, I verified the higher power target and actually entered 340W territory in 3DMark.
Cards with the highest power target use a 340W BIOS, so I looked for cards that come with 340W max TBP (total board power). From my experience with the 7900 XTX I knew that flashing a BIOS with different output connectors could result in connectors not working, so the BIOS to look for was a 3xDP + 1xHDMI card with a 340W BIOS.
I picked the Taichi BIOS since those criteria were met. The BIOS chips on the ASUS Prime OC 9070 XT are on the back side of the card, thus, easily accessible without removing the cooler as the backplate of this card may just be removed. With a Sapphire Pure I didn’t have this luck before since that card had a backplate bolted to the PCB with screws that were only accessible from the front side so the cooler needed to be removed.
Performance BIOS on this card was on the side of the respective BIOS switch position, right one or U3 in that picture below.
The BIOS chip on my card was a Gigadevice GD25LB16ETJG, seemingly SPI_NOR, which is not known by NeoProgrammer. For flashing, I connected the 8-pin clamp to the BIOS IC. It is important to match pin 1 which is indicated by a small pit on the chip. Don’t be irritated by the color markings on the chip! However, certain ranges of chips often use similar commands for unlock, erase and write so I gave it a try. Pick an IC profile that has the same capacity (indicated here by “16”). Somehow though I got weird errors opening BIOS files in NeoProgrammer, so I switched to AsProgrammer. That program does not provide chip detection. So I used NeoProgrammer to check if the clamp had proper connection to the chip and then AsProgrammer for getting the work done. There were 2 profiles available for a 25 type chip with 16 Gbit. I tried the first GD 25Q16 which did not work so I tried the second.
I finally succeeded applying the IC Profile GD 25Q16B in AsProgrammer.
In AsProgrammer, unlike NeoProgrammer, the steps of unlocking, erasing, writing and verifying need to be made manually, so I did this in that order. Verification succeeded finally (unlike the other GD25Q16 profile) so I tried booting the card.
Hurray, the card booted with performance BIOS enabled and showed ASRock as manufacturer which indicated the new BIOS taken from the ASRock Taichi stored at TPU BIOS library.
Using HWInfo64 and Benchmarks, I verified the higher power target and actually entered 340W territory in 3DMark.
The 340W brought me close to other 340W cards, but since my VRAM is quite slow with only 2720 FT stable, I needed more power and decided to connect the EVC2. Thankfully, the board designers provided a I2C-bus connection at the top end of the card that was 1:1 to what was used before on NV 30x0 cards. Thus, soldering was easy and was successful at my first try (however let aside my only basic soldering skills and associated problems, see picture for reference xD).
The Voltage controllers are MP2686A which are currently unknown to the EVC2SE software, however the software detects chips at addresses 22 and 24. My first try was using the MP2857 profile (same as with 7900 XTX), which proved to be useable, and was added manually on both addresses.
A bit of research delivered VID and TGP control of the GPU core and the VDDCI interface (good for VRAM overclocking) on the MP2686A on address 22 and VSOC and VMEM on 24, also useful for VRAM. Monitoring works, but readings are a bit off so don’t be confused by that. Vid control works correctly though, proven by HWInfo64 readings on my side.
Address 22
Address 24
Adding +75 mV to VDDCI, and +50 mV to VRAM and VSOC provided more stable VRAM clocks, for benching and with good cooling maybe up to 150mV could be used (with care!! Probably not with memtest_vulkan due to its heavy load..)
However lowering Loop 1 Iout gain, which results in lower TGP readings (was the way to go with 7900 XTX to bypass power restrictions) does not provide results with the 9070 XT at first. However, there was an effect unveiled by HWInfo64-readings, as you can see below.
The Voltage controllers are MP2686A which are currently unknown to the EVC2SE software, however the software detects chips at addresses 22 and 24. My first try was using the MP2857 profile (same as with 7900 XTX), which proved to be useable, and was added manually on both addresses.
A bit of research delivered VID and TGP control of the GPU core and the VDDCI interface (good for VRAM overclocking) on the MP2686A on address 22 and VSOC and VMEM on 24, also useful for VRAM. Monitoring works, but readings are a bit off so don’t be confused by that. Vid control works correctly though, proven by HWInfo64 readings on my side.
Address 22
Address 24
Adding +75 mV to VDDCI, and +50 mV to VRAM and VSOC provided more stable VRAM clocks, for benching and with good cooling maybe up to 150mV could be used (with care!! Probably not with memtest_vulkan due to its heavy load..)
However lowering Loop 1 Iout gain, which results in lower TGP readings (was the way to go with 7900 XTX to bypass power restrictions) does not provide results with the 9070 XT at first. However, there was an effect unveiled by HWInfo64-readings, as you can see below.
As TBP readings control the power limit, we need to deal with the shunts. These are typically found close to the power connector. Additionally, shunts are located near the PCIe slot, but those only measure the 5v supply and are not used by the GPU vCore.
It was my first shunt mod so I did a bit of research. Since it was Saturday and I did not have shunt resistors or anything at home despite solder stuff and a multi-meter, I did a close look at the shunt sensing circuit and found that there were unoccupied slots for additional shunts that could easily be used. To measure the resistance between the two solder pads already showed 0 Ohms so I thought bridging them won’t do any harm – probably despite allowing some of the current to bypass the shunt resistor originally in place, which was intended.
A big plus was that the original shunts could be left untouched and the bridges could be removed again easily if anything didn’t work out. So, no risk no fun, light up the torch (or better, use an electronic solder iron xD).
For 3 connectors, 3 bridges have to be made in total. Really an easy mod for any half-skilled person, this is how it looks when it’s done, hope you see the difference!
Et voilá:
After putting the card together, it booted up without problems and everything was fine. No problem with driver or anything. However, 3DMark scores were low. Opening up HWinfo then showed very high hotspot temperatures with a delta of over 50K and higher TGP then TBP so yep, something happened. Readings at the power outlet revealed like 100 W more were pulled.
However, with EVC2 connected and TGP gain lowered, the card went far into its thermal limits (Hotspot like 110°C, max. Hotspot 116°C), resulting in bad throttle and FPS drops despite sustained high clocks. It occurred that thermal and possibly TGP / current protection resulted in power gating / clock stretching, visible by lower effective clocks!
The workaround proved to use maximum clock offset in the driver, setting to -150 MHz I was able to bench and get somewhat good scores without overheating. However, above 100°C hotspot results in clock gating / lower effective clocks. More testing at -300 Mhz revealed that the cooler worked with temperature delta of 20-30 K like before, so that was not the problem. The rather weak and slim cooler of the ASUS Prime OC without any vapor chamber simply was not able to cope with the heat produced, especially the hotspot. Doing an outdoor balcony bench session provided better results but still inferior to the top end cards with better cooling and better VRAM, however I did not use VRAM tuning with EVC2 yet in that session. Interestingly, there are no differences in behavior with the Taichi BIOS, although the Taichi does not use shunts (and therefore might be tuned only via TGP / EVC2?). Some Taichi owners should provide HWInfo footage and show Limits of the Taichi, whether its TBP also (from what data source?) or just TGP/GPU current (which is limited to 330A at Taichi perf BIOS).
It was my first shunt mod so I did a bit of research. Since it was Saturday and I did not have shunt resistors or anything at home despite solder stuff and a multi-meter, I did a close look at the shunt sensing circuit and found that there were unoccupied slots for additional shunts that could easily be used. To measure the resistance between the two solder pads already showed 0 Ohms so I thought bridging them won’t do any harm – probably despite allowing some of the current to bypass the shunt resistor originally in place, which was intended.
A big plus was that the original shunts could be left untouched and the bridges could be removed again easily if anything didn’t work out. So, no risk no fun, light up the torch (or better, use an electronic solder iron xD).
For 3 connectors, 3 bridges have to be made in total. Really an easy mod for any half-skilled person, this is how it looks when it’s done, hope you see the difference!
Et voilá:
After putting the card together, it booted up without problems and everything was fine. No problem with driver or anything. However, 3DMark scores were low. Opening up HWinfo then showed very high hotspot temperatures with a delta of over 50K and higher TGP then TBP so yep, something happened. Readings at the power outlet revealed like 100 W more were pulled.
However, with EVC2 connected and TGP gain lowered, the card went far into its thermal limits (Hotspot like 110°C, max. Hotspot 116°C), resulting in bad throttle and FPS drops despite sustained high clocks. It occurred that thermal and possibly TGP / current protection resulted in power gating / clock stretching, visible by lower effective clocks!
The workaround proved to use maximum clock offset in the driver, setting to -150 MHz I was able to bench and get somewhat good scores without overheating. However, above 100°C hotspot results in clock gating / lower effective clocks. More testing at -300 Mhz revealed that the cooler worked with temperature delta of 20-30 K like before, so that was not the problem. The rather weak and slim cooler of the ASUS Prime OC without any vapor chamber simply was not able to cope with the heat produced, especially the hotspot. Doing an outdoor balcony bench session provided better results but still inferior to the top end cards with better cooling and better VRAM, however I did not use VRAM tuning with EVC2 yet in that session. Interestingly, there are no differences in behavior with the Taichi BIOS, although the Taichi does not use shunts (and therefore might be tuned only via TGP / EVC2?). Some Taichi owners should provide HWInfo footage and show Limits of the Taichi, whether its TBP also (from what data source?) or just TGP/GPU current (which is limited to 330A at Taichi perf BIOS).
Resumé:
Benching with the shunt mod and EVC2 is great fun. It just feels different without TBP limits. The clocks slider actually does something, UV still helps to hold temps low and using EVC to dial in TGP and VID’s is quite interesting to do. Many, many opportunities.
If you only use shunts and no EVC2, cooling will result in lower GPU core current and TGP also, so UV and outdoor/balcony sessions will help to improve scores anyhow. At the moment I cannot use higher TGP via the EVC2 due to temperature (hotspot) limitations. Benching outside, TGP and current limits are several % away from 100% when hotspot temp kicks in and lowers my scores, so that’s that.
With the ASUS Prime OC, which is a great card with very good voltage regulation, a lot of capacitors out of the box, 3x8 pin and a dual BIOS, I feel this is the best low-budget tuning card, but it will need water to shine! And maybe the Taichi and XFX Mercury OC has better binned GDDR?
It will be interesting how the cards behave with better cooling, if TGP and current protection will be useable or result in stutter. So far, with reduced max boost clock the card is much useable and frames feeling absolutely smooth, possibly due to lower TBP restraints and less clock dips.
Tonight I will try the quiet BIOS if it has lower TGP/current limits build in but I doubt it..
Have fun tweaking and generating scores!
✵✵✵ ✵✵✵ ✵✵✵ ✵✵✵
Zuletzt bearbeitet:
:P
