DLSS 5 Autopilot 1.8.0

The release is about the two questions the tool could not answer: why did
nothing happen, and what setting should I use. Both are answered from
what was recorded - the logs, Windows' own event record, other people's
reports - rather than from advice.

The 32-bit Vulkan layer was being thrown away

Every 32-bit game that goes through DXVK - DirectX 9 titles, which is the
whole reason DXVK is there - registered ReShade's Vulkan layer correctly and
then never loaded it. Call of Juarez: Gunslinger (#31) collected four rounds
of wrong answers over this, and Bayonetta (#2) is the same fault.

Both of ReShade's layer manifests call themselves VK_LAYER_reshade, and the
Vulkan loader accepts a layer name once. The registry key the tool uses,
HKCU\Software\Khronos\Vulkan\ImplicitLayers, is not split per architecture
the way HKLM\Software is, so a 32-bit game saw both manifests, kept the
64-bit one and then refused it. The loader's own trace, in a 32-bit process:

Removing layer VK_LAYER_reshade (...ReShade32.json) because it is a
  duplicate of VK_LAYER_reshade (...ReShade64.json)
Requested layer "VK_LAYER_reshade" was wrong bit-type.

The 32-bit layer is registered under its own name now, and an install made
by an older version is rewritten rather than reused.

Aim for a frame rate

The work area is the dial that costs frames - model resolution, in the
OptiScaler ini - and everyone set it by feel. The add-ons were already
writing down what a session cost: the feeder logs the frame rate, the
OptiScaler forks log the model's own time per frame. The tool threw that
away.

Say what you want in aim for _ fps, beside the work-area slider on the
install page - so wherever that slider is live, which is the optiscaler
route and the feeder's 64-bit D3D11 path. Then play, and press
did it work?:

=== aiming for 60 fps ===
> 47 fps at 100% (3600 frames, from the feed's frame-rate line).
> Two sessions at different work areas are enough to split the frame:
  10.1 ms the model does not touch, 11.2 ms of model at full size.
> 77% should land on 60 fps.

Frame time splits into a part the dial does not touch and a part that scales
with the area: frame_ms = base + k * r². Two sessions at two resolutions
solve both unknowns exactly. One session cannot, so the first suggestion is a
bounded step and says so. Applying it is a separate press, and it takes
effect the next time the game starts - both add-ons read their configuration
once, at startup.

What Windows recorded

A game that closes before ReShade loads writes no log at all, which is the
largest group of reports here. Windows writes an Application Error event with
the faulting module, and the tool now reads it for the game in question:
a module this tool installed is named as ours, the game's own executable as
the game's, and anything else as what it is. When the faulting module has
the same name as the proxy we wrote and as a Windows system DLL, the event
cannot tell the two copies apart, and it says so rather than guessing. The
line goes into the bug report as well.

The record also outranks the logs when the two disagree. A log is written
while the game runs, so a healthy last line is not evidence that the session
ended well: in #98 the model dispatched, the game died after the logos, and
the tool answered "Working." to somebody who had just watched it close. A
fault Windows recorded turns that verdict into "It ran, and then the game
crashed - Windows recorded the fault", with the module named.

The driver, before the install

Driver 616.64 is named in more reports than any other single cause, and a
driver older than 616.56 carries no neural-rendering runtime at all - DOOM on
475.14 (#16) was told to go and run the game again, and the video player on
610.60 (#75) was told the result was inconclusive. Both ends are now on the
install page, per route, and the add-on error that proves the old-driver
case is a verdict of its own.

Reports that can be answered

Four of the nine reports on the day 1.7.3 shipped arrived with the template's
own "yes / no / it closed itself" line untouched and nothing written under
"what happened". The report button asks those two questions in the tool now
and will not open a report without them.

And what other people found goes in before the install, with no server
anywhere: press did it work? after playing and then share the result,
and a pre-filled issue opens in your browser carrying the game's name and
executable, the route and build, the graphics API, your card and driver, this
tool's version, whether it worked, and the one-line verdict the diagnosis
reached. No paths, no user name, nothing else - and nothing is sent unless you
post it. A workflow adds those up into one file the tool reads:

=== what other people found ===
> 34 reports for this game. The feeder route worked in 22 of them and failed in 3.
> The route chosen here (optiscaler) failed in all 9 of its reports.
> 9 of the 12 failures reported here were on driver 616.64.

Fewer than five reports and it says nothing.

The runtimes come from NVIDIA

nvngx_dlss.dll and nvngx_dlssg.dll were fetched from a community mirror.
NVIDIA publishes both in its own repository, so that is where they come
from - read at the release tag, so the label says which SDK release the file
came out of. Neural rendering is not among them: NVIDIA's SDK carries super
resolution, ray reconstruction and frame generation only, and
nvngx_dlssnr.dll still comes from the community build that matches your
card.

Ray reconstruction can be swapped too, for a game that already ships it -
the dropdown appears only then, and only on the routes whose install can
act on it - every route but optiscaler and remix. It is a swap and never an
addition: the game's own file is backed up and comes back on uninstall, the
download is checked for being a 64-bit Windows DLL before anything is
overwritten, and the tool says what a swap means the moment you choose a
build, long before anything is written - a launcher that verifies its files
puts its own copy back, and an online game's anti-cheat can treat a changed
file as tampering.

The library is where it opens

The tool opened on the architecture question every time, and the games were
not read until you pressed past it - so coming back to a game you had set up
meant walking the whole wizard again. #67 asked for exactly this and the
1.7.3 answer only got half of it: the cache was built, but nothing opened on
it. With scan library at start on - which is the default - a library from
last time is the first thing on screen, with no disks walked; the
architecture filter is one click away on the rail. Untick it and the tool
opens where it always did.

Also

• The library shows games, not leftovers. Steam deletes a game's
  manifest when it is uninstalled and leaves the folder: on the machine this
  was written on, 46 of 63 entries across three libraries were saves and
  shader caches - 29 of the 32 folders in one of them. A folder
  keeps its place when the manifest says the game is fully installed, when an
  executable is there, or when this tool has installed into it.
• The overlay key can be changed (#88). ReShade opens on Home and
  OptiScaler on Insert; a keyboard with neither had no way to switch neural
  rendering on. Both are written from one setting.
• An HDR display is warned about an old feeder build. The feeder's own
  0.15.1 notes say the neural pass was wrecking HDR highlights before it.
• An AMD card gets an answer (#53) instead of "no nvidia card detected":
  what exists, why none of it can be installed from here, and what would
  change that.
• OptiScaler that never engages is answered from disk instead of with
  "press Insert and tick it": the ini's own Enabled line, the two files
  (the runtime and the forwarder), the game's own upscaler, and the driver.
• The wilsjo2 fork's own cost line counts as running (#81): a
  thirteen-minute session with the model dispatching every frame was
  reported as inconclusive.
• Files the install wrote and that have since gone are the answer, in
  the right order: restore them from quarantine and exclude the folder
  before installing again (#84 installed three times).
• Paths out of an archive or an install record cannot leave the folder
  they belong to (#79).
• The optiscaler route says on Vulkan what it only used to say
  afterwards (#66, #70): in the reports received, the model has had
  nothing to attach to there - so the install page says so, and points at
  DirectX 12 or the feeder route.
• A publisher's server having a bad minute is no longer a traceback
  (#103). A 5xx from a publisher's server is asked again, with a growing
  wait, and then explained in plain words - which server it was, that it is
  not your connection, and that anything already downloaded stays in the
  cache.
• The wilsjo2 fork is installed for what it is for (#81). Its "before
  super resolution" placement is off by default in the fork, so choosing
  that build now writes RunBeforeSR on with it, and the install says so.
• A .7z opens even where Windows' own tar cannot open it (#93).
  Microsoft's bsdtar is not consistently built with LZMA, and where it is
  not, an OptiScaler fork published as a .7z unpacked nothing. 7-Zip is
  used first when the machine has it, and when neither can do the job the
  message says which one is missing and why.
• build.bat builds again (#93). It passed --specpath into %TEMP%
  while naming version_info.txt by a relative path, and PyInstaller
  resolves that against the spec directory - so building from the script
  ended in a FileNotFoundError. The CI workflow was never affected because
  it does not pass --specpath. A .gitattributes now pins *.bat to
  CRLF as well, so the script cannot break on a clone made with
  core.autocrlf=input either.
• "Motion vectors: not installed" is checked against the folder first
  (#101). With the shader sitting in reshade-shaders\Shaders the answer is
  that the technique is switched off, or another one is on in its place -
  not that a file is missing.

Under the hood

• _tools/walkthrough.py drives the real window through every route, the
  diagnosis, the auto-tuner and the report dialog.
• _tools/detect_check.py records what every game in a library detects as
  and reports what a change moved.