v0.2.0: the slider works, and two writes are gone

Important

Test build: collect logs from real AMD Radeon cards. This one fixes two fields the driver was writing into places the engine does not read - one of them the Intensity slider, which has never worked on this path. Both were found by taking the runtime apart, not by a report.

Five commits since v0.1.18. Two change what the pass does; the rest make the class of mistake that produced them visible in the suite.

The watchdog counter is not an abort token

The driver ran InterlockedExchange(..., 0) on 0x8d808 after every accepted frame, to clear what its own table called a stale watchdog abort token. It is not one. The engine's watchdog function (0x16260..0x1652d) stores the job id into 0x8d808 and 0x8d80c when a timeout fires and reads them back - so the clear was erasing the engine's own record of which job timed out, on every frame.

The address came from arithmetic rather than a measurement. The port applied the delta that fits the fields around it (0x76c68 + 0x16ba0); the reference that documents the field computes 0x76c68 + 0x16a20 and lands on 0x8d688. The two answers differ by 0x180, and neither could be confirmed without a Radeon - so the write is gone rather than guessed at. Nothing the driver needs depends on it, and the engine resets its real abort flag itself through hipMemcpyAsync.

The header had said so all along, three lines below the constant that contradicted it. That is now a test.

Intensity reached the file, not the network

The menu's Intensity was written to Scale in the runtime's ini, on the reading that this is where the runtime takes its strength from. For this build it is not. The ini is parsed by one function (0x7af0..0x801a) reached through a call_once guard inside the first CreateSwapChain detour (0x97c0), immediately before the engine's Init - it runs once. A value written to the file after that is read by nothing, so the slider moved the host's own composite while the network's strength stayed at whatever the file held when the guard ran.

The field itself is read per frame: 0x140a0..0x15e79 is the recording function, the same one that reads Local Tone, Local Structure and Skin Structure, all of which this driver has always written directly. Intensity is written there now, every frame, with the calibration shared with the ini write through ScaleMax() so the two cannot disagree. The ini is still updated on change, so the next launch starts from the slider.

What makes this class visible next time

• An offset that appears both in the table and in the note that says the host must not write it now fails the suite. 0x8d808 lived in both for a release, and the note was a comment.
• The Scale field write is required, not the ini write alone - the shape of the bug was "wrote something that looked right".
• Checked against mutations: restoring the constant, deleting the note, and removing the field write are each caught and named.

Tests

138 green, plus the static checks: the archive's manifest, the shipped config, README EN/RU agreement, and the working copy.

Still unproven

No Radeon has produced a processed frame with this yet. What is different from v0.1.18 is that the pass no longer runs on values that were never read: the device is chosen by the runtime, the abort token is not touched, and the intensity now lands where the network reads it. The last step is still a machine with an RDNA3/RDNA4 card - and the logs from it will say which of the remaining gates is the one.