Nagi (amdgpu-wddm) 0.7.216.102-tester.31

Nagi (amdgpu-wddm) 0.7.216.102-tester.31

A tester release of Nagi (amdgpu-wddm), an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and Nagi Control App of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes two records
that only this installer and this control program read.

The release before this one is 0.7.216.101-tester.30. This release replaces it. The notes of
0.7.216.101-tester.30 list the changes since 0.7.216.100-tester.29v2, and they apply to this release too, with the
changes below.

This release has two flavours from the same source line:

• Release is the package for normal testing. It excludes raw kernel diagnostics and shader overrides.
• Lab keeps those diagnostics for driver development and fault investigation. Its download names end in
  -lab. Use it when a diagnostic procedure specifically asks for it.

Both flavours are signed with our test certificate and still require Windows test-signing mode. The release
flavour prepares the driver files and submission CAB for Microsoft attestation. It is not Microsoft-signed and
has not passed HLK certification. Buying an EV certificate does not itself sign or certify this package.
The user-mode driver files are installed through the driver package into the Windows DriverStore.

How to install

Choose the release flavour unless you need the lab diagnostics. The single file amdgpu-wddm-setup-0.7.216.102-tester.31.exe holds the whole
package: copy it to a local folder and double-click it. Or unpack the whole zip file to a local folder, then
double-click setup.exe in the folder it makes. The setup window asks for administrator rights itself. It reads the
state of the computer and shows what it will change. Your click on Install is your consent, and the window asks
nothing more. It restarts Windows by itself after a countdown of 15 seconds, and it continues after each logon. On
the command line, run files\install.cmd from the unpacked folder as administrator, with all its switches.
INSTALL.md in the package gives all ways.

• The product version is 0.7.216.102-tester.31. Windows reports its driver package version as 40.7.216.102.
  The package manifest records the build and identity of each component. Keep the files of each flavour together.

New

• Nagi Control App can write a log file for a game. A game or program that does not work as you expect can now
  be recorded. You turn the switch on in Nagi Control App, you start the game, and the driver writes what it does
  into a file for you to send us. The switch runs for a time that you choose and then stops by itself, so a log
  cannot fill your disk: each file stops at 64 megabytes, and every program that starts while the switch is on
  gets a file of its own. "Stop now" ends the recording at once. The Direct3D 11, Direct3D 12 and Vulkan drivers
  all write into these files.

• The driver now starts with 24 of the 40 graphics cores, and you choose how many to use. 24 is the number
  that the firmware of the board switches on by itself. The Graphics page of Nagi Control App selects any number
  from 24 to 40 in steps of two. It can also map the pairs of cores one by one, so a pair that makes the computer
  unstable can stay off.

• A DirectX 12 game that builds its shaders while it loads now loads faster. Such a game asks the driver for
  one pipeline after another, and each one holds a shader to compile. The driver compiled them one at a time, on
  the thread of the game that asked. It now compiles them on all the cores of the processor but one, and the game
  goes on while they are built. On our board the first load of Death Stranding fell from 498 seconds to between
  308 and 368. A game that needs a pipeline at once still waits for that one pipeline, so nothing is ever drawn
  with a shader that is not ready. "If something goes wrong" below says how to turn this off for one game or for
  every program.

Fixed

• The desktop compositor and other programs can read the shared driver settings. An earlier candidate
  denied access to the root key, so the desktop router selected the CPU even with the GPU path enabled.
  The driver now grants read access at that key. Write access and private records remain restricted.

• The driver activates its saved device state when Windows starts the device. An earlier tester.31 candidate
  tried to activate that state while Windows was still adding the device. An upgrade from tester.30 could then
  fail before the driver started, with Code 31 and status 0xC000014D. Device addition now prepares the state,
  and device start activates it. The shared-state reader also requests the service configuration access it needs.

• The installer keeps its DriverStore directory paths separate. An earlier candidate joined three directory
  names into one path, so the driver-package installation could fail before the new driver was selected.

• The desktop now appears when the firmware starts the screen in a scaled mode. Some boards leave a small
  picture stretched to the full size of the screen when Windows starts, for example a picture of 800 by 600 on a
  screen of 2560 by 1440. The driver refused the plan that Windows inherited from the firmware in that state, so
  the screen stayed on the Windows logo, and the third start in a row was refused by the safety rule of the driver.
  The driver now reads the geometry of the output, accepts the inherited plan, and keeps the native mode as the
  fallback. It also starts a board whose inherited picture runs above 300 megahertz, which it refused before, and
  a start that is refused all the same now undoes its own preparation, so the next start finds a clean
  state. Checked on our board at 800 by 600, at 1024 by 768 and at the native mode of the screen. (GitHub issue 38)
  Note: while the screen is started that way, the driver shows only the mode it inherited. The desktop is a small
  picture stretched to the full size of the screen, and Windows lists that one mode. Set the picture of the
  firmware to the native mode of the screen to get the full size back. If a Windows setting holds the small picture
  instead, open a command prompt as an administrator, run bcdedit /deletevalue {globalsettings} graphicsresolution, and restart the computer. The driver work that asks the screen for its own mode in this
  state is in development, and this release does not promise it.

• The whole desktop no longer becomes slow while the Epic Games Launcher is visible. With that window open the
  taskbar answered a message in about 50 milliseconds instead of 0.6, and the desktop drew only about 20 times a
  second, with the GPU almost idle. Windows copies the picture of such a window through a surface that the
  processor reads every frame, and that surface was in a memory that the processor reads slowly. It is now in the
  memory that is fast for the processor. On our board the measured answer of the taskbar with the launcher visible
  fell from 49.3 to 0.9 milliseconds. (GitHub issue 41)

• The Direct3D 11 driver now offers only the driver interface that the graphics adapter supports. It offered a
  newer one than the adapter reports, which the Windows compatibility tests refuse at every feature level, and
  which made one Direct3D 9 test fail to create its device. The controls of 0.7.216.100-tester.24 for the vertical
  synchronisation keep working as before.

• The support report of Nagi Control App now holds every crash record of the last 24 hours. It kept only the
  records whose text names a part of the graphics stack, so a game that closed itself in its own code left no
  record in the report, and a report about "the game does not start" held nothing to read. The report now keeps
  every Application Error, Application Hang and Windows Error Reporting record of the last 24 hours, newest first
  and at most 500 of them.

• The driver package no longer carries a restart directive that Windows refuses for a graphics driver. The
  installer asks Windows to stage the driver set and to bind it at the restart, which it does itself after the
  countdown, so the installation works as before. The package now passes the Windows driver package check. The
  installer also writes a receipt of the step that put the driver on the GPU.

• The command-line tool writes each measurement at once. bc250kmd_cli dpm, telemetry and fan write a
  line for every sample. Sent to a file, they wrote nothing until the program ended, so a program that watched the
  temperature from that file saw no line at the start of a run, or a hot sample late.

• The installed driver reports the version number that games read, and you set nothing for it. Windows records
  this driver under a number in the AMD style, 40.7.216.102 for release 0.7.216.102, because some games refuse to
  run on an older AMD driver version. The number comes with the package, there is no setting to turn on, and the
  last step of the installer reads the number back from the installed driver and writes it in one line.

• Nagi Control App starts the right Quake II RTX. The benchmark page asked Steam for the program number of
  the old demo, so the benchmark did not start on a computer with the game from Steam. It now asks for the number
  of Quake II RTX itself.

• "Render on CPU" says what it can and cannot do. The text of that setting promised more than the setting
  gives: the processor path does not offer all of DirectX 11, and most games made after 2012, Counter-Strike 2
  among them, do not start with ...

Nagi (amdgpu-wddm) 0.7.216.101-tester.30

Nagi (amdgpu-wddm) 0.7.216.101-tester.30

A tester release of Nagi (amdgpu-wddm), an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and Nagi Control App of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes two records
that only this installer and this control program read.

The release before this one is 0.7.216.100-tester.29v2. This release replaces it. The notes of
0.7.216.100-tester.29v2 list the changes since 0.7.216.100-tester.29, and they apply to this release too, with the
changes below.

How to install

Take one of the two downloads. The single file amdgpu-wddm-setup-0.7.216.101-tester.30.exe holds the whole
package: copy it to a local folder and double-click it. Or unpack the whole zip file to a local folder, then
double-click setup.exe in the folder it makes. The setup window asks for administrator rights itself. It reads the
state of the computer and shows what it will change. Your click on Install is your consent, and the window asks
nothing more. It restarts Windows by itself after a countdown of 15 seconds, and it continues after each logon. On
the command line, run files\install.cmd from the unpacked folder as administrator, with all its switches.
INSTALL.md in the package gives all ways.

• The kernel-mode driver is version 0.7.216.63. Its driver package has the date 10/13/2026 and the version
  0.7.216.101. Tester.29v2 has the same date, and Windows keeps an installed driver package that a new one does not
  rank above, so this release takes the next version number.
• The package is built from train/b33 b614581, merged into main as b4a6ad3.

New

• The Direct3D and Vulkan drivers that games use now build shaders on a stack of their own. Release
  0.7.216.100-tester.29v2 did this for the desktop files only. There, the desktop (dwm.exe) of Windows 24H2 and
  25H2 builds its shaders on a thread with a small stack, and the shader compiler needs more than that stack holds.
  The compiler now moves to a larger stack that it reserves and checks itself before it builds a shader or a
  pipeline. This release does the same in the Direct3D 12, Direct3D 11 and Vulkan drivers, 64-bit and 32-bit. We
  saw the stack overflow in the desktop only, not in a game. A program that builds shaders on a thread with a small
  stack can no longer stop for this reason.

Fixed

• On a board with the 8-core processor unlock, the driver no longer uses broken numbers from the chip's
  measurement table. The driver reads a table of power, voltage, clock and temperature numbers from the chip
  once a second. The fan uses its power number, and the driver log and Nagi Control App show the others. Reports
  from the community say that on a board with the 8-core unlock and the original chip firmware, the numbers of
  cores 6 and 7 overwrite other fields of that table, among them the GPU clock and the GPU temperature. The
  driver now checks every table before it uses it. A field that the chip did not write, a number outside its
  range, or the pattern of those overwritten fields refuses the table. The driver then keeps the last good table.
  After three refused tables in a row, it stops reading the table until the next start. The fan then follows its
  temperature curve without the power number, and the driver log says why the table was refused. Our own board has
  six cores, so we could test the check only with recorded and constructed tables, not with an unlocked board.
  Please tell us what the driver log says on yours.

• Windows Explorer no longer closes with an error when the driver stops. The driver stops when you update or
  remove it, or when you disable the GPU in Device Manager. Explorer then asked our Direct3D 11 driver for more
  work, that request failed, and the cleanup after the failure read a part of the request that did not exist yet.
  The cleanup now finds every part ready, and Explorer gets the normal "device removed" answer. The same fix is in
  the Vulkan drivers, 64-bit and 32-bit, and in the driver that draws the Windows desktop.

• The support report of Nagi Control App holds the startup diagnostics again. In 0.7.216.100-tester.29v2 the
  part of the program that collects them stopped before it wrote a line, and the report said only "Worker exit
  -532462766." Now it writes every section. When one check fails, the report names the error and the other checks
  still run.

• The support view no longer says that the start confirmation task is not installed when it is. Nagi Control
  App runs without administrator rights, and Windows does not let such a program read this task. The view now says
  that it cannot read the task from there, and it shows the result of the task's last run from its log.

• Recent games no longer lists web browsers and Windows programs. Every program that uses Direct3D appears in
  that list, Microsoft Edge and the Snipping Tool too. Nagi Control App now hides browsers, store clients and the
  programs of Windows. "Show hidden games" lists them, and "Show" puts one back in your games.

Known issues

• On some boards the screen stays on the Windows logo after the restart of the install (GitHub #38). This
  happens when the firmware of the board shows a low resolution, for example 800x600, scaled up to a monitor with a
  higher resolution. The driver starts, but it does not show the desktop. If the screen stays on the logo, switch
  the computer off and on. After two such starts the driver does not start again, and Windows shows the desktop
  without it. To prevent this, run bcdedit /set {globalsettings} highestmode on as administrator before you
  install, and restart Windows. The firmware then uses the native resolution of the monitor. We are working on a
  fix.

• On a board with the 8-core unlock, the power numbers can be missing. When the driver refuses the measurement
  table, Nagi Control App shows no power numbers, and the fan takes no extra speed for a high load. The temperature
  still drives the fan, and the emergency rule at high temperature stays on. The GPU clock control does not use this
  table, so it is not affected.

• On our test board, a restart of Windows sometimes stops before Windows starts again. Windows ends
  normally. Then the screen stays black, and the board does not start Windows until its power is switched off
  and on. We saw this eight times in three days of tests, with this release and with the releases before it, and
  once in the final test of this package. We do not know the cause yet. If it happens on your board, switch the
  power off and on, and tell us.

• The known issues of 0.7.216.100-tester.29v2 apply.

Settings affected

• The installation keeps the settings that you changed. A setting that you did not change gets the new default of
  this release.

• This release adds no setting and changes no default. DpmMaxMHz, SubmitWatchdogMs, FanLoadBoost,
  EnableDpAudioContainerId, HangRecoveryWaves, EnableRingVmFlush, CuMode and TdrDelay stay as
  0.7.216.100-tester.29v2 set them.

If something goes wrong

• When the driver does not start, send us the text file that the installer names at the end of its run, or the
  support file of the setup window, which holds the same text.

• If a game or program that ran on 0.7.216.100-tester.29v2 stops at its start or while it loads shaders on this
  release, tell us. The stack change of this release touches every shader build.

• On a board with the 8-core unlock, send us the support report from Nagi Control App. Its driver log holds the
  reason for each refused measurement table.

• Look at the preview of a support file before you send it. When you find personal data in it, do not send the
  file, and tell us in the report so that we can fix the application.

Nagi (amdgpu-wddm) 0.7.216.100-tester.29v2

Nagi (amdgpu-wddm) 0.7.216.100-tester.29v2

A tester release of Nagi (amdgpu-wddm), an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and Nagi Control App of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes two records
that only this installer and this control program read.

The release before this one is 0.7.216.100-tester.29. This release replaces it. It is a second issue of tester.29
for a short test, and it carries the changes that we prepare for 0.7.216.100-tester.30. The notes of
0.7.216.100-tester.29 list the changes since 0.7.216.100-tester.28, and they apply to this release too, with the
changes below.

How to install

Take one of the two downloads. The single file amdgpu-wddm-setup-0.7.216.100-tester.29v2.exe holds the whole
package: copy it to a local folder and double-click it. Or unpack the whole zip file to a local folder, then
double-click setup.exe in the folder it makes. The setup window asks for administrator rights itself. It reads the
state of the computer and shows what it will change. Your click on Install is your consent, and the window asks
nothing more. It restarts Windows by itself after a countdown of 15 seconds, and it continues after each logon. On
the command line, run files\install.cmd from the unpacked folder as administrator, with all its switches.
INSTALL.md in the package gives all ways.

• The kernel-mode driver is version 0.7.216.62. Its driver package has the date 10/13/2026.
• The package is built from main 720b42f. The tag of this release names main 1574fd5, the source of the first
  build, because the tags of this repository cannot move. The two differ only in the installer and the build script.

New

• An update now always puts the kernel driver of the package on the GPU. Windows keeps an installed driver
  package when a new package has the same INF file, or the same date and version. The first build of this release
  had this fault. Over 0.7.216.100-tester.29 it could leave the kernel driver of tester.29 on the GPU, and its
  verification passed, because it compared the version only. That build was available for about one hour and
  nobody downloaded it. Each release now has its own date and an INF line with the hash of its kernel driver. After
  the install, the installer checks that Windows will start the kernel driver of the package, and stops with the
  reason if it will not. The verification compares the hash of the kernel driver that runs with the package.

• The installer asks you nothing after your click on Install. There is no box to tick and no YES to type. When
  BitLocker is on, the installer pauses it for the restarts that it needs and tells you that it did. The uninstaller
  asks nothing either.

• The release also comes as one file. amdgpu-wddm-setup-<version>.exe unpacks the package into a folder that
  only administrators can write to. It tests every file and installs from there. It removes that folder when the
  installation ends.

• The Microsoft Visual C++ runtime installs itself. The driver's programs need the Microsoft Visual C++
  2015-2022 Redistributable (x64). The package now carries Microsoft's own installer for it. The installer runs it
  when the runtime is missing or older than 14.44. It tests the file's SHA-256 and its Microsoft signature first.
  This step needs no internet.

• 64-bit OpenGL programs run on the GPU. This release has an OpenGL driver (ICD) for 64-bit programs. Windows
  loads it for every 64-bit OpenGL program, with no file beside the program. Until now Windows gave such a program
  its own software renderer, which is OpenGL 1.1. verify.cmd shows the line OpenGL ICD.

• A notice at sign-in tells you when the graphics driver is not running. When the driver's guard switched the
  driver off, the notice says so in plain words. Its button "Turn the graphics driver back on" starts the driver
  again without a restart of Windows. When the driver did not start for another reason, the notice opens Nagi
  Control App, which explains what happened. On a healthy computer you see no notice.

• The small blue window after logon says what it is for. Its two lines read
  Nagi start check: confirming that the GPU driver started correctly. and
  Nothing to do. This window closes by itself in m:ss. The time counts down to its close. In Nagi Control App, Settings, you can turn this window off. Read the warning next to that box before
  you do it.

• The driver's name is Nagi. The control application is now "Nagi Control App" and the setup window is
  "Nagi Setup". The installation puts "Nagi Control App" in the Start menu and on the desktop, and
  "Nagi Control App (recovery)" in the Start menu. An install over an older release removes the old
  "amdgpu-wddm Control" shortcuts, but only those that start our own program. The switches
  -NoStartMenuShortcut and -NoDesktopShortcut of install.cmd leave the shortcuts out. The files, folders,
  registry keys and tasks keep their technical name amdgpu-wddm.

• The installer supports Windows 11 23H2, 24H2 and 25H2 and the general builds after them. An older Windows 11
  gets a line that advises an update, and the installation continues. Windows 10 and older are refused.

• A native Polish speaker read every Polish text of the setup window and of Nagi Control App.

• An install now gives all 40 graphics cores of the GPU. The board's firmware switches on 24 of them, and
  every release until this one left it at 24. The game results that we publish are measured with all 40 cores. To
  keep the firmware's number, use install.cmd -CuMode 24, or select "Standard (24)" on the Graphics page of
  Nagi Control App. Both write the number 24 into the driver's settings, so a number that you choose yourself
  is kept by every later install. Where the driver itself went back to 24, the Graphics page says so and does
  not call that number your choice. The first start with 40 cores needs the confirmation of the small blue
  window after logon, as before. Without that confirmation the next
  start goes back to 24 cores and records why. An install and an upgrade keep that 24 and name it in the report,
  because the driver went back for a reason. install.cmd -Repair sets all 40 cores back, and so does "All (40)"
  on the Graphics page. All 40 cores use more power and make more heat than 24. The unlock's reference measured
  about 30 W more at 1500 MHz. That is a reference, not a promise for your computer.

• The Nagi logo. Nagi Control App and Nagi Setup show the Nagi logo beside their name, and a tip in each
  says what the name Nagi stands for.

• The Nagi wallpaper. After the installation is confirmed, Nagi Control App sets the Nagi wallpaper once for each
  person who signs in, and saves that person's previous background first. The setup window has a box for it next to
  the shortcuts, on by default, and install.cmd -NoWallpaper leaves it out. In Nagi Control App, Settings, "Nagi
  wallpaper" sets it again or restores your previous background. The uninstaller does not change your background.

• Through a passive DisplayPort-to-HDMI adapter, you can now choose the screen mode, and the screen plays
  sound. Up to this release the driver kept the one mode that the board set at power-on. It now offers the modes
  of the screen that the adapter can carry, changes to them and changes back. It also sends sound to the HDMI
  screen. A restart of the GPU device without a restart of Windows, for example from Device Manager, keeps the
  picture and the modes. On our test board, with an LG screen at 1920x1080 through such an adapter, these all gave
  a picture: 75 Hz, 60 Hz, 75 Hz again, 1280x720 at 60 Hz and back. A test tone came from the screen.

• The window that Windows shows when a program wants to open a network port now draws on the processor. That
  window is "Windows Security", with the Allow and Cancel buttons. On the last release it stayed white and empty,
  with only the program icon in it. It drew no text and no buttons, so there was nothing to answer. The program
  behind that window is PickerHost.exe, the File Picker UI Host. Windows uses the same program for the file open
  and save windows. This driver now gives that one program the processor driver instead of the adapter. It
  already does the same for the sign-in screens. Nothing changes for your other programs. This one program name is
  the whole change. You can put that program back on the adapter. Add PickerHost.exe to the Allow list
  under HKLM\SOFTWARE\amdgpu-wddm\AppRouter. That also helps us find the cause. To see the window at all, start
  a program that listens on a network port from a folder that has no firewall rule yet.

• The Vulkan driver keeps one set of internal data for each adapter. Up to this release it used one and
  the same slot for every adapter that is not reached through the desktop path. On a computer with a second AMD
  adapter the two could share that slot. The driver now names each slot by the adapter's own identifier, so each
  adapter gets its own. A computer with one adapter works as before. We have one adapter in our test board. Tests
  on a development PC cover this change, and no measurement on two adapters does.

Fixed

• The GPU starts on newer Windows builds again (Code 43). Windows 11 24H2 and 25H2, and recent updates of
  23H2, refused the driver with code 43 ("Invalid user mode driver name", 0xC0000182). The installer left the
  first of the driver's file names empty, for Direct3D 9. It now writes <> there, which those builds accept.
  Direct3D 9 programs still go through D3D9On12 of Windows.

• **Windows ...

amdgpu-wddm 0.7.216.100-tester.29

amdgpu-wddm 0.7.216.100-tester.29

A tester release of amdgpu-wddm, an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and amdgpu-wddm Control of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes two records
that only this installer and this control program read.

The release before this one is 0.7.216.100-tester.28. This release replaces it. The notes of 0.7.216.100-tester.28
list the changes since 0.7.216.100-tester.27, and they apply to this release too, with the changes below.

How to install

Unpack the whole zip file to a local folder, then double-click setup.exe in the folder it makes. The setup window
asks for administrator rights itself. It reads the state of the computer, shows what it will change and asks before each
restart of Windows. After each logon it starts by itself and continues. On the command line, run
files\install.cmd from that folder as administrator, with all its switches. INSTALL.md in the package gives
both ways.

New

• The zip file now unpacks to a folder that holds one file and one folder: setup.exe, which is what you
  double-click, and files, which holds everything else. Up to the last release the folder held eleven files,
  four folders, and the setup window two levels down, in a folder named setup, which was easy to miss.

• The setup window has the look of the control application. The same title bar, the same colours in light and
  dark, and the same buttons. Every screen reads in English, Polish, Japanese and Korean. The window takes the
  keyboard alone, and it works with a screen reader.

• The installer reads the Secure Boot state of your firmware and says what it found (BD-125). The standard
  BC-250 firmware versions P2.00, P3.00 and P5.00 have no Secure Boot setting, so the state is off there and you
  do nothing. The installer now prints off (not built into the firmware) and names where it read that. On a changed
  firmware that does have the setting the installer stops before it changes anything and tells you where the
  setting usually is.

• The message about the test certificate says what the installer adds and where. It names the two certificate
  stores of the computer that get our test certificate, and it says that the uninstaller takes the certificate
  away again.

• The graphics engine now gets the page tables of the program that draws a picture as commands in front of that
  picture, on the engine's own command ring. Earlier releases wrote them through the registers of the chip
  before each picture. This is the setting EnableRingVmFlush, which 0.7.216.100-tester.24 added with the value
  off, and from this release it is on. On our test board The Witcher 3 Remaster at HIGH with ray tracing gave the
  same time for each picture with the setting on and off at the same GPU clock: 70.23 ms on and 70.33 ms off at
  1300 MHz. With the setting on, the driver reported no GPU fault, no freeze and no lost picture. One pair of
  sessions cannot show a difference smaller than about half a millisecond.

• The driver records it when Windows stops a start that nothing confirmed. Up to this release the driver wrote
  why a start failed, and nothing at all when the start itself went through and Windows stopped the device a
  moment later. That second case is the one in the field reports of 2026-10-11: the start reached its stage 39,
  and Windows stopped the device and showed Code 43. The driver now writes the stage before the stop, the health
  of the start, the generation of the device, the number of this boot, the times of the stop and the last 64 lines
  of its log to HKLM\SYSTEM\CurrentControlSet\Services\bc250kmd\Parameters\StopRecord. You do not need to turn
  anything on and you do not need a restart.

• A start that a healthy desktop confirms leaves no stop record when Windows stops the device later. An older
  record stays in place in that case, so the installer and the control application compare the number of the boot
  in the record with the number of this boot before they show it as this start's.

• A start that failed leaves no stop record either. The driver stops the device itself to undo such a start, so
  Windows stopped nothing, and the reason of that failure is in StartRecord with the step and the status that
  failed. The stop record therefore means one thing only: a start that reached a started device, that nothing
  confirmed, and that Windows then stopped.

• The stop record holds no reason from Windows, because Windows gives the driver none when it stops a device. Our
  tools say so in the report instead of naming a cause that nobody measured.

• The installer collects the details by itself when the driver does not start. The last step of the
  installation reads the state of the device, the start record, the stop record and the health of the start. When
  those readings show a driver that did not start, the installer writes one text file for that run next to its
  log. The file holds the decision and the readings behind it, the two records, the entries of the Windows system
  log of this boot from Display, the DirectX kernel, Plug and Play and the service control manager, the sections
  of setupapi.dev.log of the graphics device, and the newest files of C:\BC250\kmdlog. The collection takes at
  most 20 seconds and at most 4 MB. It changes no result of the installation.

• The setup window puts that file into its support file as run-<n>-diagnostics.txt, and the result screen says in
  your language that it collected the details. The command-line installation prints the name of the file in its
  last lines. A test run with -DryRun collects nothing.

• amdgpu-wddm Control collects the same details when it starts on a driver that did not start. It reads the
  two records and the state of the device, and it puts the result into the support report. The work runs in a
  program of its own with a time limit, so the window stays usable.

• The kernel-mode driver is version 0.7.216.39.

Fixed

• The driver starts when the firmware of the board scales its picture (BD-124). The firmware of the board
  draws its own start-up picture in one size and sends it to the monitor in another size. The driver of
  0.7.216.100-tester.28 read only the size on the monitor side, so it refused such a mode and stopped with Code
  43. One field report shows the case: the firmware picture is 1024 by 768, and the link to the monitor runs at
  1920 by 1080. The driver now reads the two sizes apart. It keeps the size of the firmware picture, the size on
  the monitor side and the way the chip scales between them as one set, and it gives Windows that set. A mode that
  the driver keeps this way is never changed by the driver: it writes no scaler value and no timing value for it.

• The driver reads the monitor data of an HDMI link and turns the sound on (BD-124). Through a passive
  DisplayPort-to-HDMI adapter the board sends HDMI signals. The driver now reads the monitor data over the two
  data lines of such a link, so Windows learns the name of your monitor and the sizes that it offers. It also
  turns the sound of the HDMI link on. Up to this release such a link had no sound at all.

• A serial number or a machine ID stayed in a support file and in a bug report. The rule that removes those
  values needed a line that ends in one single character, and every log of Windows ends its lines in two. The rule
  therefore matched nothing at all, in any file of any support file or bug report of the releases up to
  0.7.216.100-tester.28. The user name, the profile path, the computer name, the MAC addresses and the e-mail
  addresses were taken out as the documents promise. The serial numbers, the machine IDs, the product IDs and the
  UUIDs were not. The rule is fixed, and a test of the application now reads the values back out of a finished
  support file.

• The same rule also missed a value behind a prefix. A line of setupapi.dev.log, a line of an event message and
  a line of the driver's own log carry a time or a tag in front of the word, and the rule stopped at the first
  colon of the line. It now looks past such a prefix.

• A support file can name a second account of the computer. The reports take out the user name and the profile
  path of the account that collects them. A log of Windows can also name another account of the same computer, and
  such a name stayed in the file. The reports now take out the account name of every other C:\Users\<name> path,
  the security identifiers and the computer name of an event entry.

• install.cmd -Console kept only the first switch. The command line of install.cmd -Console -DryRun lost
  -DryRun, so a test run installed for real. Every switch now reaches the installer.

• INSTALL.md named the wrong command for the test mode of Windows. The table of changes now shows
  bcdedit /set '{current}' testsigning on, with the quotation marks that PowerShell needs. A command prompt does
  not need them. The installer itself always passed the argument correctly.

• INSTALL.md named 1500 MHz as the highest GPU clock of the automatic clock control. The release default is
  2000 MHz.

• A record of this start could be reported as a record of an earlier start of the computer. When Windows stops
  the driver after a start that nothing confirmed, the driver keeps a record of that stop. The record carries the
  number of the start of Windows that wrote it, so a reader can tell a fresh record from one that an earlier start
  left behind. Windows keeps that number in two places, and the copy our readers used can stay one behind for the
  first minutes. A ...

amdgpu-wddm 0.7.216.100-tester.28

amdgpu-wddm 0.7.216.100-tester.28

A tester release of amdgpu-wddm, an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and amdgpu-wddm Control of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes a record that
only this installer and this control program read.

The release before this one is 0.7.216.100-tester.27. This release replaces it. The notes of 0.7.216.100-tester.27
list the changes since 0.7.216.100-tester.26, and they apply to this release too, with the changes below.

How to install

Unpack the zip file to a local folder, then double-click setup\amdgpu_wddm_setup.exe in that folder. The setup
window asks for administrator rights itself. It checks the computer, shows what it will change and asks before each
restart of Windows. After each logon it starts by itself and continues. install.cmd stays the way to install on the
command line, with all its switches. INSTALL.md in the package gives both ways.

New

• The setup window is the usual way to install. It shows the checks, the changes, the consents and the restarts
  in plain words, in English, Polish, Japanese and Korean. On a problem it tells you the next step, and it can
  save a support file. The setup window installs the driver only: for llama.cpp, Ollama or a model, install with
  install.cmd.
• HIP: device-to-host copies of model outputs now run on the GPU. On our test board, text generation (tg128) is
  about 26 % faster on Gemma 4 12B (39.0 against 30.9 tokens a second) and about 28 % faster on TinyLlama 1.1B.
  Prompt processing is unchanged. BC250_HIP_GPU_COPY=0 puts the copies back on the processor. Our llama.cpp
  build uses this runtime. Our Ollama build has its own copy of the earlier HIP runtime, so it does not get
  this change yet.
• amdgpu-wddm Control can change the GPU memory size of the BC-250 (BD-116). The Board memory card of the
  Performance page offers 8 GB and 12 GB. The change needs an administrator, and it takes effect when Windows
  starts the next time. The card shows the size in use now and the size of the next start apart. "Restore" puts
  back the setting that the board had before the first change. The driver of 0.7.216.100-tester.27 could not
  find the board's settings memory, so its card offered no size. This driver reads and writes it through the
  fixed ports of the board.
• Direct3D 12 programs can draw one scene into several views with one draw (view instancing, tier 2). A
  program uses this, for example, for the two eyes of a stereo picture or for the faces of a shadow map. The
  driver reports tier 2 only when its Direct3D 12 engine supports it. It does not report tier 3.
• Direct3D 12 render passes go to the driver. The driver now gives Windows its own render pass functions, so
  Windows does not do render passes with its own steps.
• The Performance page has a new card, "Ray tracing benchmark". It measures how fast your card traces light and
  shows the result in pictures a second. It needs Quake II RTX on the computer: the free game of NVIDIA, from
  Steam or from the maker's own page. The driver package does not hold the game and never downloads it. The card
  finds a Steam copy by itself, and you can also choose the folder yourself. It says plainly when a folder holds
  no game, no game data, game data it cannot read, or a copy without the test scene.
• One run of the card measures both ways your card can trace light, one after the other, because a game can ask
  for either and the speed differs. The card names them "First way" and "Second way" and gives the technical name
  of each under it. Each way takes about twenty seconds on our own board. The game opens in a small window of its
  own, 1280 by 720, and closes again when it has finished. The card shows the pictures a second, the highest
  temperature and the average clock of each way, with the date and the driver release of the run.
• The test of the card stops by itself when the chip stays at 87 degrees, and after three minutes for each way.
  "Stop the test" ends it at once. The card then says which of those happened instead of showing a number. The
  last ten runs stay on this computer, so you can see whether a new driver release changed the number.
• amdgpu-wddm Control has a new page, "Windows settings". It can stop some background activities of Windows,
  for example the diagnostic data service, the indexing service and some telemetry tasks. Each change is optional. The page saves the
  earlier setting before each change, and "Restore" puts that setting back. It does not remove Windows parts, and
  it does not touch security, the network or the Windows Update service. The installer applies the recommended
  changes only when you give it -ApplySystemTuning.
• The installer can install the programs that run language models on the board. It asks one question for
  each one, and yes is the answer in capitals, so Enter is enough. The two are our build of llama.cpp and our
  build of Ollama. Both are open projects under the MIT licence. They go into
  C:\Program Files\amdgpu-wddm\tools\llama and C:\Program Files\amdgpu-wddm\tools\ollama, and both folders go
  on the machine search path, so you can start them in any command prompt after the restart.
• The installer can also get a model for you. After the two questions it shows a short list with the size and
  the licence of each model: Gemma 12B, which is the model this board was measured with, Qwen3 1.7B, which is small
  and quick, and Qwen3.6 35B A3B, which needs the board memory at 12 GB. The answer is none, because a model is a
  download of gigabytes. The model files go into C:\Users\Public\Documents\amdgpu-wddm\models. For Ollama the
  installer gets the same model through Ollama itself, which keeps it in its own format in its own folder. A model
  that you choose for both programs is therefore downloaded twice and kept twice, about 13 GB for Gemma 12B. The
  question says so for each model, with the sum, before anything is downloaded.
• The installer checks an extra and a model before it uses them. The package holds the address, the size and
  the SHA-256 of every download, and it refuses a file that does not match. A refused, skipped or failed extra
  never stops the driver installation: the driver is installed first, and the extras come last.
• An installation without a window can choose with switches. -Components llama,ollama and
  -NoComponents, -Models gemma12b and -NoModels, and -ComponentDir <folder> to take the files from a folder
  instead of the internet. prepare-offline.cmd takes the same switches and puts the files into components\ and
  models\ of the prepared folder, next to the firmware.
• Use bc250-ollama.cmd to start our Ollama, not ollama.exe. It is the same program, with the port and the
  model folder of this installation already set. bc250-ollama.cmd run gemma4:12b-it-qat in the installed folder
  is the whole of it. A bare ollama.exe uses the Ollama defaults, so it can reach another Ollama on the same
  computer instead of ours.
• Our Ollama can use the board in two ways. The user environment variable BC250_OLLAMA_BACKEND selects
  auto, vulkan or rocm_bc250. The installer writes auto, which lets Ollama decide. Stop and start the
  server after a change. An Ollama that you installed yourself is left alone: our copy keeps its models in
  %LOCALAPPDATA%\bc250-ollama\models and takes the next free port when the usual one is in use.
• The uninstaller removes every registration of an extra and keeps your models. It removes the two folders,
  the two entries in the machine search path, and the logon entry and the settings that an extra wrote.
  uninstall.cmd -RemoveModels removes the models as well, from both model folders.
• The kernel-mode driver saves a record of the GPU programs before it resets a stopped GPU. The record names
  each wave that was running and its place in the program. bc250kmd_cli waves saved shows the record of the
  last reset, and bc250kmd_cli waves reads one now.
• Board controls need a BC-250. The fan, the clock limits, the processor limits and the memory size are board
  controls. The driver gives them only after it identifies the board as a BC-250. amdgpu-wddm Control and
  bc250kmd_cli board-caps read the limits from the driver. On another board the controls say that they are not
  supported, and the driver does not touch the board.
• The kernel-mode driver is version 0.7.216.32.
• The Direct3D 12 driver of both architectures, its engine, the Direct3D 12 and Direct3D 11 GPU drivers of both
  architectures, the 64-bit Vulkan driver, the HIP runtime, amdgpu-wddm Control, its helper library and
  bc250kmd_cli are new builds.
• The driver keeps the reason of a failed start (BD-122). When the driver does not start, Windows shows only
  Code 43. The driver now writes the step that failed, its error code, the measured values of that step and the
  last lines of its log to HKLM\SYSTEM\CurrentControlSet\Services\bc250kmd\Parameters\StartRecord.
  verify.cmd of this package shows this record in plain words. So do tools\start-confirm.ps1 -Probe and
  tools\bc250kmd_cli.exe stages in C:\Program Files\amdgpu-wddm: they read the registry, so they answer also
  while the device shows Code 43. Please attach their output to a report of a driver that does not start.
• A start that fails on the picture mode of the board now records its timing (GitHub #38). When the
  driver refuses the timing that the board set at power-on, the start record also holds the timing values that
  the driver read, so a report tells us the mode of y...

amdgpu-wddm 0.7.216.100-tester.27

amdgpu-wddm 0.7.216.100-tester.27

A tester release of amdgpu-wddm, an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and amdgpu-wddm Control of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes a record that
only this installer and this control program read.

The release before this one is 0.7.216.100-tester.26. This release replaces it. The notes of 0.7.216.100-tester.26
list the changes since 0.7.216.100-tester.25, and they apply to this release too, with the changes below.

New

• amdgpu-wddm Control shows the GPU memory size of the BC-250. The board keeps a part of the machine's
  memory for the GPU. The Performance page of amdgpu-wddm Control now has a Board memory card, which shows the
  size that is in use now. The card is made to change that size too, with two choices, 8 GB and 12 GB, but on
  this build it says that a change is not available (BD-116). Read the first known issue below.
• Only a BC-250 gets the size control. On another adapter the Board memory card shows the memory size and
  says that the control is not supported. The driver touches no board hardware there.
• The automatic clock control may now go up to 2000 MHz. The release before this one let it go up to
  1500 MHz. The GPU still starts at 1000 MHz, it still drops to 500 MHz when nothing uses it, and the
  temperature and voltage limits are the same as before. You can still choose a lower limit in the Tuner page
  of amdgpu-wddm Control. A machine that locks up under load at a high clock speed is a known risk of this
  hardware: choose a lower limit if that happens, and tell us.
• The kernel-mode driver keeps a record of each HIP dispatch. Before a HIP program sends work to the GPU,
  our HIP runtime gives the driver the name of the GPU function and the place of the work in the queue. If the
  GPU then faults or stops, the driver's record names the function that caused it. This is how we found the
  HIP fault below.
• The kernel-mode driver is version 0.7.216.28.
• The 64-bit Vulkan driver, amdgpu-wddm Control, its helper library, bc250kmd_cli and the HIP runtime are new
  builds.

Fixed

• A Vulkan program now sees the real GPU memory size. The 64-bit Vulkan driver reported the memory size of
  the machine the driver was first measured on, which was 8 GB, whatever the board was set to. It now reports
  the size the board really keeps for the GPU, so a program that asks how much GPU memory it may use gets a
  larger answer after you choose 12 GB. A program that needs more memory than 8 GB can now be told that the
  memory is there.
• A Vulkan program that gives one of its GPU locks to another program keeps its own copy. Vulkan lets a
  program hand one of its GPU locks to another program through a Windows handle. The 64-bit Vulkan driver took
  the handle away from the program that gave it, so that program then held nothing. It now keeps its own copy,
  as Vulkan asks, and it applies the rights, the inheritance and the name that the program asked for. The other
  program cannot use the lock yet: read the known issues.
• A HIP program no longer makes the GPU fault (BD-110). Our HIP header gave gridDim as a count of
  work-items, not as a count of workgroups. A GPU function that steps through its data by the size of the grid
  then went far past the end of its buffer, the GPU faulted, and Windows stopped with stop code 0x116. The
  driver's dispatch record named the function. Now the header gives the count of workgroups, and the HIP
  runtime, vadd.exe and bc250hipblas.dll are built again with it. The same change fixes other device
  functions of the header, for example atomic operations, the ballot of a part of a wave and conversions of
  half-precision numbers.
• The installer and the uninstaller work on a Windows in a language other than English (#35). They
  found our driver packages in the English labels of pnputil, and they read the test signing setting in the
  English text of bcdedit. On a Windows in another language, for example Spanish, the uninstaller left our
  driver in the driver store, and the test signing check gave the wrong answer. Now they find the driver packages
  through the DISM driver objects, and they read the test signing setting through the BCD WMI interface. Neither
  of these depends on the language of Windows.

Measured on our test board

These are results from the test of this release on our own BC-250, with the GPU memory size at 8 GB and the
automatic clock control on. Your results can be different.

Program	Mode	Result
Rise of the Tomb Raider, benchmark	Direct3D 12, preset High, empty shader cache	51.24 frames per second overall
Rise of the Tomb Raider, benchmark	Direct3D 12, preset High, shader cache of an earlier run	77.59 frames per second overall
Quake II RTX, timedemo	ray tracing with VK_KHR_ray_tracing_pipeline	59.73 frames per second
Quake II RTX, timedemo	ray tracing with VK_KHR_ray_query	60.92 frames per second
The Witcher 3 Remaster, in the game world	Direct3D 12, preset High with ray tracing	13.0 frames per second
llama.cpp, TinyLlama 1.1B Q4_0	HIP, prompt of 512 tokens (pp512)	1868.00 tokens per second
llama.cpp, TinyLlama 1.1B Q4_0	HIP, generation of 128 tokens (tg128)	122.31 tokens per second

On HIP, the greedy answer of TinyLlama, 16 tokens, was the same as the answer of the processor.

Experimental: HIP runtime

• This package has our own HIP runtime, amdhip64.dll, with our hipBLAS library bc250hipblas.dll. The
  installer puts them in the tools\hip folder of the install folder and adds that folder to the end of the
  system PATH, so a HIP program finds them after the restart that ends the installation. If AMD's own
  amdhip64.dll is in System32 or earlier on PATH, Windows loads that one first. The uninstaller deletes
  the folder from PATH again.
• To check the runtime, run tools\hip\vadd.exe. It adds two vectors on the GPU and compares each value with
  the result of the processor. It must report a pass.
• This package does not contain llama.cpp. The source repository has the recipe that builds the HIP backend of
  llama.cpp for this runtime, in compute/hip/patches. The recipe builds llama.cpp with flash attention on, and
  it keeps each model buffer below the Windows limit in the known issues (BD-117). TinyLlama 1.1B and the dense
  Gemma 4 12B model load and answer on HIP with it.
• llama.cpp for this runtime: extract llama.cpp-hip-gfx1013-b86d2f07-tester.27.zip from the assets and run
  llama-server.exe -m <model.gguf> -ngl 99 -fa on --jinja (more in its README.txt).
• We compared the output of the whole TinyLlama model on HIP, with flash attention on, with CUDA on an RTX 4090.
  The mean KL divergence was 0.003, so the two give almost the same results.

Known issues

• The Board memory card cannot change the GPU memory size on this build (BD-116). Before the driver offers
  a change, it checks its route to the board's settings memory. On our test board that check fails, so the card
  offers no size, writes nothing and says that a change is not available. The board keeps the size that it has.
  The fix comes in the next release. Until then, only Linux can change the size.
• A Vulkan program cannot yet use a GPU lock that it gets from another program (BD-105). The program that
  gets the Windows handle of a lock receives VK_ERROR_INVALID_EXTERNAL_HANDLE when it opens the handle, and
  also when it opens the lock by its name. The lock stays usable in the program that gave it. Two programs that
  share their GPU work through such a lock do not work together on this release.
• A HIP program cannot get one GPU memory block of more than about 4 GiB (BD-117). On this driver, Windows
  refuses one GPU allocation of more than 0xFFFF0000 bytes, and CreateAllocation2 returns C000000D. The
  llama.cpp recipe in compute/hip/patches therefore limits one buffer to 0xFFFC0000 bytes. llama.cpp then puts
  the model weights in more than one buffer, and a dense model of 12 billion parameters (Gemma 4 12B) loads and
  answers on HIP. A program that asks HIP for one block of more than about 4 GiB still gets the error.
• Windows gets less memory when the GPU gets more. At 12 GB the GPU keeps four more gigabytes, and Windows
  has that much less. On a 16 GB board Windows is left with about 4 GB, which is enough for the desktop and a
  language model, and not enough for comfortable work. Choose 12 GB for a program that needs the GPU memory, and
  8 GB for everything else.
• The real GPU memory size is reported by the 64-bit Vulkan driver only. The 32-bit Vulkan driver of this
  release is the same build as in 0.7.216.100-tester.26, and it still reports the old measured size. The same is
  true of the shared-lock fix above.
• Windows itself reports the GPU memory as before. The size that the Task Manager and a Direct3D program
  read comes from Windows, not from this part of the driver, and it counts memory that no program can use for
  its own data. A number there that is larger than the Vulkan number is not a fault.
• The 64-bit Vulkan driver of this release is a new build, so the shader cache it wrote for an earlier release
  is not read any more. The first start of a Vulkan game takes longer than it did, once.
• The catalog file of the kernel driver (bc250kmd.cat) is still different in every build, because every build
  signs a new one. The driver image is the same in every build.
• After a stop with code 0x116 the driver's automatic clock control is left switched off. Check the Tuner page
  of amdgpu-wddm Control...

amdgpu-wddm 0.7.216.100-tester.26

amdgpu-wddm 0.7.216.100-tester.26

A tester release of amdgpu-wddm, an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and amdgpu-wddm Control of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes a record that
only this installer and this control program read.

The release before this one is 0.7.216.100-tester.25. This release replaces it. The notes of 0.7.216.100-tester.25
list the changes since 0.7.216.100-tester.24, and they apply to this release too, with the changes below.

New

• The driver's own limit for one piece of GPU work now follows the Windows timeout. Windows gives a piece of
  GPU work 10 seconds in this release. The driver had a second, private limit of its own of half a second, which
  was much shorter, and a long piece of honest work ran into it. That limit is now the Windows timeout plus two
  seconds, 12 seconds as this release installs it, and the driver starts it again whenever the work makes
  progress. You can set it yourself with SubmitWatchdogMs, below.
• The kernel-mode driver is version 0.7.216.27.
• The 64-bit Vulkan driver is a new build, with the three Vulkan fixes below.

Fixed

• A large language model no longer stops Windows with stop code 0x116 (issue #36). Dense models stopped
  Windows on their first big piece of work at llama.cpp's own default batch of 512 tokens, and the notes of
  0.7.216.100-tester.25 asked you to use -ub 128 instead. The cause was the driver's private half-second limit
  above: the work was healthy, it simply took longer than half a second, and the recovery that followed failed.
  On the lab machine the model that stopped Windows twice that morning (a 12-billion-parameter dense model,
  -ub 512 -p 512 -n 128, three repeats) now runs to the end: 207 tokens a second reading the prompt, 33 tokens
  a second writing, no timeout, no recovery and no stop. You no longer need -ub 128 for that model. Please tell
  us what your own models do.
• A long wait in a Vulkan program no longer ends with a lost graphics device after ten seconds. The 64-bit
  Vulkan driver waited for the GPU in one piece of ten seconds, and a piece of work that honestly took longer
  was reported to the program as a lost device. It now waits in one-second steps for up to two minutes, and it
  checks the graphics device between the steps, so a device that has really gone away ends the wait at the next
  step instead of holding the program for the whole two minutes.
• The Vulkan driver keeps the right answer while it makes memory resident. When it put memory in place for
  the GPU it used an answer that Windows does not promise for that call, and it could then go on while an
  earlier piece of work was not finished. It now keeps the newest answer it was promised and waits for that
  one. Nobody reported a wrong picture from this.
• A monitor whose description the driver cannot read is written in the log again. One answer of the driver,
  which is the designed answer of the sound part of a DisplayPort monitor, was taken as "not worth logging"
  everywhere in the driver instead of in that one place. A monitor that serves no description gives the same
  answer for a real fault, and such a monitor appeared in the log 6 times instead of 64. Log lines only: no
  behaviour changes, and nothing you can see on the screen.

Known issues

• The fix above is measured on one dense model. The lab machine ran a 12-billion-parameter dense model at
  the default batch to the end, three repeats. The 27-billion-parameter model that also stopped Windows has not
  been run again on this release, and the driver's longer limit does not promise that every long piece of work
  ends well: Windows still owns its own 10-second timeout, and a real hang still ends in stop code 0x116. If a
  model stops Windows on your machine, send us the support report and the exact llama.cpp command (issue #36).
• After a stop with code 0x116 the driver's automatic clock control is left switched off. Check the Tuner page
  of amdgpu-wddm Control after such a stop.
• The three Vulkan fixes above are in the 64-bit Vulkan driver only. The 32-bit Vulkan driver of this
  release is the same build as in 0.7.216.100-tester.25, so a 32-bit Vulkan program still reports a lost
  graphics device after ten seconds of one wait. We know of no 32-bit Vulkan program that waits that long.
• The two-minute wait of the Vulkan driver is a chosen bound, not a measured one. No program of ours needed
  more than a second. If a Vulkan program seems to hang for about two minutes and then reports a lost device,
  that is this bound, and we want to hear about it.
• The fan's work under load is measured on one load, on one machine. On the lab machine, under a path tracer
  that held the graphics at full clock for 165 seconds, the fan was at full speed within 15 seconds of the
  start with the default of 0.7.216.100-tester.25, and after 102 seconds with the switch off: about a minute
  and a half earlier. Your case and your fan are not ours, and a language model, a compile or a game is not a
  path tracer. If your fan is loud when it should be quiet, or quiet when the machine is hot, tell us, and say
  what the Case fan card shows.
• A program that the router sends to the processor path gets Direct3D feature level 10_0 only. With the release
  setting gpu-default this affects programs whose image the router cannot resolve. Keep the router at gpu-default
  (issue #24).
• Without administrator rights, bc250kmd_cli clock read gives no clock and no temperature. Use
  bc250kmd_cli dpm in its place (issue #7).
• The desktop compositor composes a full-screen game again while another window covers part of it, for example a
  notification. The driver has no overlay path for such a window yet.
• A screenshot or a screen recording of a full-screen Direct3D 12 game can be black. The game puts its own
  picture on the screen, and the compositor does not get the frames. To record such a game, set
  AMDGPU_WDDM_D3D12_EXPERIMENT=scanout-flip-off for it.
• The 64-bit Vulkan driver of this release is a new build, so the shader cache it wrote for an earlier release
  is not read any more. The first start of a Vulkan game takes longer than it did, once.
• The catalog file of the kernel driver (bc250kmd.cat) is still different in every build, because every build
  signs a new one. The driver image is the same in every build.
• The known issues of 0.7.216.100-tester.25 apply, except the stop with code 0x116 at the default batch, which
  is the first item of Fixed above.

Settings affected

• The installation keeps the settings that you changed. A setting that you did not change gets the new default of
  this release.
• The driver's private limit for one piece of GPU work is SubmitWatchdogMs (REG_DWORD, milliseconds) under
  the Parameters key of the driver. Leave it absent, which is the default, and the driver uses TdrDelay
  plus two seconds. A value you write is held to five minutes at the most and is never shorter than TdrDelay.
  The driver reads it when it starts, so a change needs a restart of Windows.
• The fan's full speed under heavy load is FanLoadBoost (REG_DWORD) under the Parameters key of the driver.
  The driver reads it when it starts, so a change needs a restart of Windows. On is the default and leaves the
  value absent. The switch in amdgpu-wddm Control writes 0 when you turn it off. Use the switch rather than the
  registry: the page knows when a restart is needed.
• The safe order of the encoder's block filter is the default and needs no setting. BC250_MFT_DEBLOCK=rows in
  the environment of a program asks for the fast order, which can give a wrong picture, and is for measurements
  only.
• EnableDpAudioContainerId, EnableRingVmFlush, TdrDelay and the shader cache of the 64-bit Vulkan driver
  stay as 0.7.216.100-tester.25 set them. TdrDelay is 10 seconds, written by the installation, and the
  uninstaller puts your earlier value back.
• The graphics settings are REG_DWORD values under HKLM\SOFTWARE\amdgpu-wddm\Graphics for all games and under
  HKLM\SOFTWARE\amdgpu-wddm\Graphics\Applications\<program file name> for one game. No value is set after the
  installation, so each game keeps its own settings until you change one.
• The AMD-format driver version on the Graphics page stays off after the installation, and no installation of
  this package writes it. Windows asks a driver not to change that number after it is installed, and changing it
  can stop Windows Update from working properly on the adapter. Turn it on only for a game that refuses to
  start with the real number, and turn it off again afterwards.

If something goes wrong

• If Windows stops with stop code 0x116 while a language model or another long GPU job runs, send us the support
  report with the exact command you ran, the model and its batch size. Then check the Tuner page of amdgpu-wddm
  Control, because the automatic clock control is left switched off after such a stop.
• If a Vulkan program hangs for about two minutes and then says that the graphics device was lost, send us the
  support report and say what the program was doing.
• If the fan is too loud, turn off "Full fan speed under heavy load" in the Case fan card of the Performance
  page and restart Windows. Then tell us what the machine was doing.
• If a recording made with the BC-250 encoder looks wrong, send us the recording and say whether
  BC250_MFT_DEBLOCK was set for the recording program.
• If the sound device of your monitor disappears or stops after this release, set EnableDpAudioContainerId to 0
  and restart Windows. Then tell us what happen...

amdgpu-wddm 0.7.216.100-tester.25

Package: amdgpu-wddm-tester-0.7.216.100-tester.25.zip, SHA-256 1E721971E366D4FBBE63117090BBB6E9CBBDFA48B76DF1686F3371B67F4B70A7. Report problems in the Issues of this repository.

A tester release of amdgpu-wddm, an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and amdgpu-wddm Control of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes a record that
only this installer and this control program read.

The release before this one is 0.7.216.100-tester.24. This release replaces it. The notes of 0.7.216.100-tester.24
list the changes since 0.7.216.100-tester.23, and they apply to this release too, with the changes below.

New

• The fan goes to full speed while the machine works hard. Until now the fan followed the temperature: it sped
  up after the board had already become hot. The driver can see the work itself, so it no longer waits. Work counts
  as heavy while the GPU is busy above its idle clock, or the chip draws more than 85 watts (processor and graphics
  together), or the temperature climbs by more than three degrees in three seconds. When any one of those holds for
  about two seconds, the fan goes straight to full speed. It stays there for half a minute after the
  work stops, and then slows down the gentle way it always did. A single busy second, a menu or a short compile,
  does not start it. The fan is never made quieter by this: where the temperature asks for more, the temperature
  wins.
• A switch for it in amdgpu-wddm Control, in the Case fan card of the Performance page: "Full fan speed under
  heavy load". It is on after the installation. Turn it off if you would rather have a quiet machine than a cool
  one, and the driver then follows the temperature alone. The switch takes effect at the next restart of Windows,
  and the card says so and offers the restart. The switch works with every fan choice in that card, the board's
  own setting included.
• The kernel-mode driver is version 0.7.216.26.

Fixed

• A game could stop drawing and never start again. Each graphics device has one alarm clock that the driver
  uses for short waits. Two pictures of one game, on two queues or two windows, could both wait for that one
  alarm. The alarm wakes one of them, and the other waited for ever: the game was alive, used no processor and
  drew nothing. Both of these waits are now short, and the driver decides what to do next by looking at the work
  itself, so a missed alarm costs a millisecond instead of the rest of the game. This affects the frame rate
  limiter of the graphics settings and the Direct3D 12 frame latency wait.
• Video recording with the BC-250 encoder keeps the right picture. The encoder smooths the edges between the
  blocks of a picture, and the fast way of doing it needed every part of the work to run at the same time, which
  Direct3D does not promise. When it did not, the encoder smoothed the blocks in the wrong order, said nothing,
  and the picture drifted further off in every frame that followed. The safe order is the default again. The fast
  one is still there for measurements, as BC250_MFT_DEBLOCK=rows.
• The encoder answers for the lock on your program's graphics device. It asked the Media Foundation device
  manager for the lock and then went on with the work whether it got it or not, so its own work and your
  program's own drawing could reach one device at the same time. It now stops with an error instead, and takes
  the lock back correctly when it is done.
• The driver no longer promises an instant change of the picture format. When a program asks whether it may
  put its own picture on the screen and change the colour format in the same breath, with no wait for the
  screen's own refresh, the answer is now no. The hardware of this chip changes that format only at the refresh.
  Nobody reported a wrong picture from it. This is the answer the rule asks for, and the right answer keeps the
  path honest. Programs that keep one format, which is all of them we test, are not affected.
• An installation or an uninstallation can no longer hang for ever on the sound device. Both restart the
  sound part of the adapter. That restart had no time limit, so a stuck restart held the whole install. It
  now has one, and the installer tells you when the limit is reached and that it stopped nothing.
• The fan hand-back no longer runs in a time-critical part of the driver. When the fan watchdog gives the fan
  back to the board, the handshake with the board's own chip can take milliseconds. That work now runs in a
  normal part of the driver where a wait is allowed. The fan behaves as before. What changes is that the
  hand-back can no longer hold up the rest of the system while it runs.
• The processor's top speed is read properly. The driver measures the highest clock the processor reaches
  under load once per start, and it used to stop at the first reading it liked. It now finishes its measurement
  and keeps the highest reading. That number is what the driver puts back when it restores the processor, so it
  was too low before on some starts.

Known issues

• A large dense language model can stop Windows with stop code 0x116. On the lab machine two dense models
  (about 12 and 27 billion parameters) stopped Windows on their first big piece of work, both times at
  llama.cpp's default batch of 512 tokens. The mixture-of-experts models finish at 512. The cause is in our
  driver: it has its own limit of 500 ms for one piece of GPU work, much shorter than the 10 seconds that Windows
  allows. A long but healthy piece of compute work passes that limit, and the recovery that follows fails. Until
  the fix ships, use -ub 128 for a dense model. On the lab machine it finished every run, also with three
  repeats and with a 4096-token context, and it was faster than -ub 256. -ub 256 finished once, with no
  repeated run, so we do not recommend it yet (issue BD-114). After such a stop the driver's automatic clock
  control is left switched off, so check the Tuner page of amdgpu-wddm Control.
• The fan's work under load is measured on one load, on one machine. On the lab machine, under a path tracer
  that held the graphics at full clock for 165 seconds, the fan was at full speed within 15 seconds of the
  start with this release's default, and after 102 seconds with the switch off: about a minute and a half
  earlier. The two runs ended within two degrees of each other, at the same frame rate, and the fan held full
  speed for 33 to 35 seconds after the load stopped. Your case and your fan are not ours, and a language
  model, a compile or a game is not a path tracer. If your fan is loud when it should be quiet, or quiet when
  the machine is hot, tell us, and say what the Case fan card shows.
• A program that the router sends to the processor path gets Direct3D feature level 10_0 only. With the release
  setting gpu-default this affects programs whose image the router cannot resolve. Keep the router at gpu-default
  (issue #24).
• Without administrator rights, bc250kmd_cli clock read gives no clock and no temperature. Use
  bc250kmd_cli dpm in its place (issue #7).
• The desktop compositor composes a full-screen game again while another window covers part of it, for example a
  notification. The driver has no overlay path for such a window yet.
• A screenshot or a screen recording of a full-screen Direct3D 12 game can be black. The game puts its own
  picture on the screen, and the compositor does not get the frames. To record such a game, set
  AMDGPU_WDDM_D3D12_EXPERIMENT=scanout-flip-off for it.
• The catalog file of the kernel driver (bc250kmd.cat) is still different in every build, because every build
  signs a new one. The driver image is the same in every build.
• The known issues of 0.7.216.100-tester.24 apply.

Settings affected

• The installation keeps the settings that you changed. A setting that you did not change gets the new default of
  this release.
• The fan's full speed under heavy load is FanLoadBoost (REG_DWORD) under the Parameters key of the driver.
  The driver reads it when it starts, so a change needs a restart of Windows. On is the default and leaves the
  value absent. The switch in amdgpu-wddm Control writes 0 when you turn it off. Use the switch rather than the
  registry: the page knows when a restart is needed.
• The safe order of the encoder's block filter is the default and needs no setting. BC250_MFT_DEBLOCK=rows in
  the environment of a program asks for the fast order, which can give a wrong picture, and is for measurements
  only.
• EnableDpAudioContainerId, EnableRingVmFlush, TdrDelay and the shader cache of the 64-bit Vulkan driver
  stay as 0.7.216.100-tester.24 set them. TdrDelay is 10 seconds, written by the installation, and the
  uninstaller puts your earlier value back.
• The graphics settings are REG_DWORD values under HKLM\SOFTWARE\amdgpu-wddm\Graphics for all games and under
  HKLM\SOFTWARE\amdgpu-wddm\Graphics\Applications\<program file name> for one game. No value is set after the
  installation, so each game keeps its own settings until you change one.
• The AMD-format driver version on the Graphics page stays off after the installation, and no installation of
  this package writes it. Windows asks a driver not to change that number after it is installed, and changing it
  can stop Windows Update from working properly on the adapter. Turn it on only for a game that refuses to
  start with the real number, and turn it off again afterwards.

If something goes wrong

• If the fan is too loud, turn off "Full fan speed under heavy load" in the Case fan card of the...

amdgpu-wddm 0.7.216.100-tester.24

Package: amdgpu-wddm-tester-0.7.216.100-tester.24.zip, SHA-256 D4B3F9A3EE14F8C48DEFE83CBBA0E8D0B76F0E35DF77637AC1AF5701883AE55A. Report problems in the Issues of this repository.

A tester release of amdgpu-wddm, an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and amdgpu-wddm Control of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes a record that
only this installer and this control program read.

The release before this one is 0.7.216.100-tester.23. This release replaces it. The notes of 0.7.216.100-tester.23
list the changes since 0.7.216.100-tester.22, and they apply to this release too, with the changes below.

New

• The manifest.json of the package names the source revision of each component and the hash of every file it
  installs. The file tools/release/release-sources.json of the repository, at the tag
  v0.7.216.100-tester.24, gives every installed file its exact source revision and build recipe. Where a second
  build of that revision gives the same file byte for byte, that file says so. Where it does not, it says why in
  one sentence, so a support report can state what the installed file is without a guess.
• The kernel-mode driver is version 0.7.216.25.

Fixed

• The driver log keeps the history of a quiet desktop. A support report from a machine that stood idle for an
  hour held about the last 50 minutes of it and not the start, because the driver wrote its regular status block
  every minute. While the GPU is idle the block now comes every two minutes, so the log holds more than an hour
  of a desktop that nobody uses. Under load the block comes every five seconds as before, and the first block
  after the GPU wakes up comes within five seconds. Each change of the GPU clock state still writes its own line
  at the moment it happens.
• Windows puts the speakers of your monitor together with the monitor itself. Before this release the sound
  device of the monitor stood apart from the monitor, because the driver gave the audio part of the card a fixed
  port number. The driver now tells it which port the picture goes out of, so the two belong to one device in the
  Windows sound settings and in a program that lists the devices. The sound itself does not change.

Known issues

• A program that the router sends to the processor path gets Direct3D feature level 10_0 only. With the release
  setting gpu-default this affects programs whose image the router cannot resolve. Keep the router at gpu-default
  (issue #24).
• Without administrator rights, bc250kmd_cli clock read gives no clock and no temperature. Use
  bc250kmd_cli dpm in its place (issue #7).
• The desktop compositor composes a full-screen game again while another window covers part of it, for example a
  notification. The driver has no overlay path for such a window yet.
• A screenshot or a screen recording of a full-screen Direct3D 12 game can be black. The game puts its own
  picture on the screen, and the compositor does not get the frames. To record such a game, set
  AMDGPU_WDDM_D3D12_EXPERIMENT=scanout-flip-off for it.
• A later release can give a file a new hash although the code inside it did not change. The build recipes of
  this project now make the same bytes from the same source code in any build folder, and the name of the folder
  a file was built in no longer reaches the file itself. This release does not rebuild a file for that reason
  alone. Of the 86 files of this package, 75 are the files of 0.7.216.100-tester.23 byte for byte, and each file
  with a new hash holds new code, a new version or new text.
• The catalog file of the kernel driver (bc250kmd.cat) is still different in every build, because every build
  signs a new one. The driver image is the same in every build.
• The known issues of 0.7.216.100-tester.23 apply.

Settings affected

• The installation keeps the settings that you changed. A setting that you did not change gets the new default of
  this release.
• The port of the monitor in the sound device of the monitor is EnableDpAudioContainerId (REG_DWORD) under the
  Parameters key of the driver. 1, the default of this release, writes the port. 0 keeps the fixed values of
  earlier releases. The value takes effect at the next start of the graphics driver, which means a Windows
  restart.
• EnableRingVmFlush (REG_DWORD) under the Parameters key of the driver is an experiment of this release and
  is off. It gives the graphics engine a second way to receive the page tables of the program that is drawing. The
  installer does not write the value, and with it absent or 0 the driver sends the very same commands as version
  0.7.216.24. On the lab machine it ran for about 81 minutes, three ray-traced game sessions among them, with no
  freeze and no lost picture, and a ray tracing test gave 18.74 to 18.81 pictures a second with the value on
  against 18.73 to 18.85 with it off, which is a difference of 0.6 % and inside the spread of repeated runs. So
  it costs nothing that we can measure, and it gains nothing either. If you try it, keep TdrDelay at 10
  seconds, and set the value back to 0 and restart after any freeze of the picture.
• TdrDelay stays as 0.7.216.100-tester.23 set it: this release writes 10 seconds, keeps a waiting time that you
  set yourself, and the uninstaller puts the earlier value back.
• The shader cache of the 64-bit Vulkan driver is on, as in 0.7.216.100-tester.23.
  MESA_SHADER_CACHE_DISABLE=true in the environment of a program turns it off for that program, and
  MESA_SHADER_CACHE_DIR puts the cache somewhere else.
• The graphics settings are REG_DWORD values under HKLM\SOFTWARE\amdgpu-wddm\Graphics for all games and under
  HKLM\SOFTWARE\amdgpu-wddm\Graphics\Applications\<program file name> for one game. No value is set after the
  installation, so each game keeps its own settings until you change one.

If something goes wrong

• If the sound device of your monitor disappears or stops after this release, set EnableDpAudioContainerId to 0
  and restart Windows. Then tell us what happened.
• If a Vulkan game starts badly or draws wrongly, delete %LOCALAPPDATA%\mesa_shader_cache and start it again. If
  that helps, set MESA_SHADER_CACHE_DISABLE=true for the game and tell us.
• If Quake II RTX or another ray tracing program loses its graphics device, send us the support report with the
  name of the program and the mode you ran.
• If a game has a black screen or a wrong picture in full screen, set
  AMDGPU_WDDM_D3D12_EXPERIMENT=scanout-flip-off for that game and start it again. Then tell us what happened.
• If a game fails after you change a graphics setting, set the setting back to "Application decides" on the page
  where you changed it.
• If a game warns about an old graphics driver, turn on the AMD-format driver version on the Graphics page of
  amdgpu-wddm Control and restart Windows.
• If Windows stops with stop code 0x116 after a GPU job stops, send us the support report. It holds the driver
  log and the result of each recovery.
• Send us the support report from amdgpu-wddm Control. It holds the driver log and the stored graphics settings.

amdgpu-wddm 0.7.216.100-tester.23

Package: amdgpu-wddm-tester-0.7.216.100-tester.23.zip, SHA-256 1C9E8DB9D194D41BAF3E5BAF2012F7F9A00625E79C4B4A53C7F863F54E6D6D97. Report problems in the Issues of this repository.

A tester release of amdgpu-wddm, an experimental Windows 11 x64 driver for the GPU of the ASRock BC-250. It is for
people who want to test the driver on their own BC-250 and report what happens. It is not ready for daily use.

The kernel-mode driver, the installer and amdgpu-wddm Control of this release belong together. Install the three of
them from this package, and do not mix them with the files of another release. The kernel driver writes a record that
only this installer and this control program read.

The release before this one is 0.7.216.100-tester.22. This release replaces it. The notes of 0.7.216.100-tester.22
list the changes since 0.7.216.100-tester.21, and they apply to this release too, with the changes below.

New

• The 64-bit Vulkan driver now keeps its shaders on disk. A Vulkan game compiled every shader again at each start.
  From this release the second start of the same game reuses what the first start compiled (issue #10). The cache
  lives in %LOCALAPPDATA%\mesa_shader_cache and grows as you play. A program that runs under a system account,
  such as the desktop itself, gets no cache directory and no cache. On the lab, Quake II RTX started with an
  empty cache needed about six seconds longer to reach its timedemo than the next start, and ran that timedemo at
  57.5 frames a second against 59.3 to 61.2 on the starts after it. The first start left 134 files (2.5 MB) in the
  cache directory and three starts brought it to 541 files (2.8 MB). A further start added nothing to it, because
  every shader it needed was already there.
• Ray tracing in a 64-bit Vulkan game gets two corrections that the Direct3D driver of this project already had.
  A ray that an any-hit shader rejects on a procedural shape no longer leaves the rejected hit's data behind. A game
  that builds its ray tracing shaders in pieces finds them in its own shader cache again at the next start, instead
  of compiling them anew.
• The kernel-mode driver is version 0.7.216.24.

Fixed

• The driver log keeps a useful history again. One line for each memory move that the driver makes for a program
  filled the log in minutes, so a support report could miss what happened a few minutes ago. The driver now writes
  the first of those lines and then one summary line with a count, and the status block that amdgpu-wddm Control
  asks for no longer pushes the log out of the way (issue #29).
• The processor boost comes back after a trial of the Tuner. The boost could stay at 3.2 GHz until the next Windows
  restart, because the driver read the clock of the moment and an idle processor runs at 3.2 GHz. The driver now
  measures the boost ceiling of your processor and restores that. While the ceiling is unknown the driver refuses a
  clock limit instead of taking one it could not give back, and a refused clock limit no longer costs the undervolt
  that you saved (issue #26).
• The setting of amdgpu-wddm Control that reports the driver version in the AMD format works. The driver wrote the
  version to a key that Windows had not made yet at that moment, so the setting had no effect and a game could
  still warn about an old graphics driver. The driver now writes the adapter's own software key, which is the key
  Windows tells a graphics driver to write. Turning the setting off puts the installed version number back, as
  before.
• A 64-bit Vulkan game no longer ends without a message when an internal check of the driver fails. The Vulkan
  driver of every release up to 0.7.216.100-tester.22 shipped with its development-time checks switched on, and
  such a check ends the game process on the spot. This release switches them off, as the Direct3D driver of this
  project always did.

Known issues

• A program that the router sends to the processor path gets Direct3D feature level 10_0 only. With the release
  setting gpu-default this affects programs whose image the router cannot resolve. Keep the router at gpu-default
  (issue #24).
• Without administrator rights, bc250kmd_cli clock read gives no clock and no temperature. Use
  bc250kmd_cli dpm in its place (issue #7).
• The desktop compositor composes a full-screen game again while another window covers part of it, for example a
  notification. The driver has no overlay path for such a window yet.
• A screenshot or a screen recording of a full-screen Direct3D 12 game can be black. The game puts its own
  picture on the screen, and the compositor does not get the frames. To record such a game, set
  AMDGPU_WDDM_D3D12_EXPERIMENT=scanout-flip-off for it.
• The known issues of 0.7.216.100-tester.22 apply, except the ones this release answers: the driver log (issue
  #29), the processor boost after a Tuner trial (issue #26), the shader cache of the 64-bit Vulkan driver (issue
  #10) and the setting that reports the driver version in the AMD format.

Settings affected

• The installation keeps the settings that you changed. A setting that you did not change gets the new default of
  this release.
• The shader cache of the 64-bit Vulkan driver is on. MESA_SHADER_CACHE_DISABLE=true in the environment of a
  program turns it off for that program, and MESA_SHADER_CACHE_DIR puts the cache somewhere else. Deleting
  %LOCALAPPDATA%\mesa_shader_cache is safe at any time: the next start compiles again and fills it.
• The setting that reports the driver version in the AMD format is ReportAmdDriverVersion (REG_DWORD) under
  HKLM\SOFTWARE\amdgpu-wddm\Graphics. 1 reports the AMD-format version, 0 or no value reports the installed
  version number of this release. The value takes effect at the next start of the graphics driver, which means a
  Windows restart. amdgpu-wddm Control owns the setting.
• TdrDelay stays as 0.7.216.100-tester.22 set it: this release writes 10 seconds, keeps a waiting time that you
  set yourself, and the uninstaller puts the earlier value back.
• The graphics settings are REG_DWORD values under HKLM\SOFTWARE\amdgpu-wddm\Graphics for all games and under
  HKLM\SOFTWARE\amdgpu-wddm\Graphics\Applications\<program file name> for one game. No value is set after the
  installation, so each game keeps its own settings until you change one.

If something goes wrong

• If a Vulkan game starts badly or draws wrongly after this release, delete %LOCALAPPDATA%\mesa_shader_cache and
  start it again. If that helps, set MESA_SHADER_CACHE_DISABLE=true for the game and tell us: the shader cache is
  new in this release for the 64-bit Vulkan driver.
• If Quake II RTX or another ray tracing program loses its graphics device, send us the support report with the
  name of the program and the mode you ran.
• If a game has a black screen or a wrong picture in full screen, set
  AMDGPU_WDDM_D3D12_EXPERIMENT=scanout-flip-off for that game and start it again. Then tell us what happened.
• If a Direct3D 11 program is worse than in 0.7.216.100-tester.22, set
  AMDGPU_WDDM_D3D11_EXPERIMENT=wddm22-ddi-off for that program and start it again. Then tell us what happened.
• If a game fails after you change a graphics setting, set the setting back to "Application decides" on the page
  where you changed it.
• If a game warns about an old graphics driver, turn on the AMD-format driver version on the Graphics page of
  amdgpu-wddm Control and restart Windows.
• If Windows stops with stop code 0x116 after a GPU job stops, send us the support report. It holds the driver
  log and the result of each recovery.
• Send us the support report from amdgpu-wddm Control. It holds the driver log and the stored graphics settings.