ChromiumRTX

Warning

Unsupported, high-risk GPU-process injection experiment. ChromiumRTX disables the WebView2 GPU sandbox and injects an unsigned native DLL into the Edge GPU subprocess. It can crash WebView2, reset the graphics driver, lose GPU work, or corrupt its dedicated test profile. Run it only on a development machine with work saved, current drivers, and no sensitive browsing session. Do not use it with arbitrary websites, a daily-use browser profile, accounts, anti-cheat software, or untrusted content.

ChromiumRTX demonstrates controlled WebGPU-to-NVIDIA paths for public NGX 1:1 DLAA and an opt-in, experimental Streamline feature-1004 / NGX feature-18 DLSS Neural Rendering adapter. The latter relies on an unpublished private ABI and a guarded, process-local driver mapping change. It does not load the closed RenoDX add-on, and none of this work is supported by Microsoft, NVIDIA, the Chromium/Dawn projects, ReShade, or RenoDX.

ChromiumRTX is a standalone raw Win32 C++ experiment that attaches to the Microsoft Edge WebView2 GPU subprocess, identifies an explicitly registered set of WebGPU textures, and appends native D3D12 work on Dawn's own device and direct queue.

The controlled page-to-native bridge, public NVIDIA NGX 1:1 DLAA provider, and experimental Streamline Neural Rendering adapter are implemented. This is an experiment for the bundled page; it is not an automatic enhancement layer for arbitrary websites.

The page's default workload is a pinned, synthetic CC0 Vitruvian digital-human head. The Smithsonian Abraham Lincoln life-mask scan remains bundled as an explicit fallback and comparison workload.

Exactly what “DLSS 5” means here

The feeder package used as the reference has two materially different layers; ChromiumRTX adds a third, independent experimental path:

Layer	What it does	ChromiumRTX status
Public DLSS5-Feeder source	Supplies color, motion, depth, output, and frame metadata to the NVIDIA NGX Super Sampling feature on one D3D12 device/queue	Implemented independently as a controlled WebGPU bridge and NGX SDK 1:1 DLAA provider
renodx-dlss5.addon64	Closed RenoDX/ReShade interception used by the reference package	Not included, staged, or loaded
Streamline feature 1004 / NGX feature 18	Private NVIDIA Neural Rendering path using sl.dlss_nr.dll and nvngx_dlssnr.dll	Adapted from this user's MIT-licensed ThreeBrowser feature-1004 bridge, independently of RenoDX, behind an explicit local-runtime build gate; experimental and not a public NVIDIA ABI

ChromiumRTX therefore has two distinct NVIDIA evaluation paths: the documented NGX Super Sampling API in 1:1 DLAA mode, and a separate experimental manual Streamline integration for feature 1004. Merely placing a DLL beside the executable does not activate Neural Rendering. The UI may call the feature active only after slEvaluateFeature(1004) succeeds on a controlled frame and the corresponding native submission is enqueued; file presence, successful loading, a support query, or a successful options call is setup evidence only.

The public feeder was studied for behavior; its source was not copied into this project. The bounded Streamline ABI/tag/mapping adapter reuses the already working ThreeBrowser/threepp implementation requested by this repository's owner and adapts it from Vulkan/native-WebGPU use to the existing D3D12 provider. See Third-party notices for attribution.

Safety boundary and intended use

This is unsupported browser-process instrumentation, not a general browser and not production code. The supported experiment boundary is one local executable, its dedicated WebView2 profile, and the bundled cooperative page. Treat a GPU process crash, driver reset, failed injection after a runtime update, or rejection by endpoint security as a foreseeable outcome of the experiment—not as evidence that the safeguards below make injection safe.

• The executable requires the explicit command-line opt-in --unsafe-gpu-hook-experiment.
• WebView2 receives --disable-gpu-sandbox and --allow-third-party-modules so the unsigned local hook can load into the GPU child.
• Renderer, network, and other child sandboxes are not disabled.
• Native navigation policy restricts the WebView to the bundled https://chromiumrtx.local/ virtual host.
• The page CSP permits same-origin reads of bundled assets and denies cross-origin connections and external content.
• A dedicated WebView2 user-data directory is used at %LOCALAPPDATA%\ChromiumRTX\WebView2UserData.
• No hook is installed when the opt-in argument is absent.
• The native provider accepts only the controlled resource contract described below. It does not guess the semantics of textures from an arbitrary page.
• Every frame fails open to the original guide color if registration, provider startup, native submission, or enqueue acknowledgement fails.

The navigation and CSP restrictions reduce accidental exposure; they are not a security boundary equivalent to the GPU sandbox that the experiment disables. Do not modify them to browse external content. See SECURITY.md before running the program or reporting a security issue.

Microsoft recommends removing diagnostic browser flags before shipping and warns that injected DLLs weaken WebView2's process security model. See the WebView2 flags guidance and WebView2 security guidance.

Architecture

ChromiumRTX.exe
  ├─ creates a native Win32 WebView2 controller
  ├─ watches ICoreWebView2Environment8 process snapshots
  ├─ selects COREWEBVIEW2_PROCESS_KIND_GPU
  ├─ creates Local\ChromiumRTX.Feeder.v2.<GPU-PID>
  ├─ injects ChromiumRTX.Hook.dll and calls its explicit initializer
  ├─ serves only the bundled WebGPU page
  └─ brokers bounded registration/frame messages between page and shared state

ChromiumRTX.Hook.dll (msedgewebview2.exe --type=gpu-process)
  ├─ observes D3D12 device, queue, resources, RTV descriptors, and submissions
  ├─ observes OMSetRenderTargets/ClearRenderTargetView or BeginRenderPass
  ├─ authenticates the page's deterministic four-RTV registration pass
  ├─ detects an armed marker that is the final pass in a Dawn submission
  ├─ verifies the active D3D12 adapter is NVIDIA
  └─ appends experimental Streamline Neural Rendering, public NGX DLAA, or a
     same-device color copy on Dawn's own D3D12 device and direct queue

The DLL's DllMain is intentionally inert. The injector calls remote LoadLibraryW, re-enumerates the target's modules to recover the complete 64-bit module base, resolves the initializer by RVA, and calls ChromiumRtxHookInitialize after loader lock has been released. MinHook detours implementation entry points; ChromiumRTX does not overwrite COM vtables.

Deterministic WebGPU feeder contract

The local page creates four same-size, single-sample, single-mip textures:

Slot	WebGPU format	Native contract	Meaning
0	rgba16float	R16G16B16A16_FLOAT RTV	HDR color input
1	rg16float	R16G16_FLOAT RTV	Current-to-previous motion in pixels
2	r32float	R32_FLOAT RTV	Raw non-linear depth, represented as a color target
3	rgba16float	R16G16B16A16_FLOAT RTV/UAV	Native output sampled by the page

Registration is not based on dimensions or formats alone. The host first arms a generation and returns four distinct exactly representable clear values. The page clears the four RTVs in the declared order in one pass. The hook correlates the observed RTV descriptors, validates device, generation, dimensions, formats, mip/sample counts, and output UAV support, and only then retains the resource set.

For each controlled frame:

1. The page asks the host to arm a monotonically increasing frame serial.
2. Its guide pass writes color, pixel motion, and raw depth.
3. A one-attachment output clear with a separate signature is the final pass and final command in that Dawn command buffer.
4. The queue detour submits Dawn's marked list first, then appends one native provider list through the original ExecuteCommandLists trampoline.
5. The provider returns every registered resource to RENDER_TARGET, enqueues its retirement-fence signal, and publishes that the native list was successfully enqueued. The ABI-v2 field retaining this watermark is named frame_completed_serial; it is not itself a CPU wait on that fence.
6. The page waits for its WebGPU submission to settle, confirms the native enqueue watermark, and then submits the output-sampling pass. That later pass uses the same direct queue, so D3D12 queue ordering keeps it behind the provider list. Otherwise the page displays guide color.

This deliberately serializes the proof workload. It prioritizes a checkable ordering contract over throughput and is not a production frame-pacing design.

Digital-human test workloads

Default Vitruvian workload

The bundled page defaults to Agile Lens' Vitruvian digital-human head from VitruvianGodot, pinned to upstream commit bdecdcd537b4031fdd0fb299b7e4f93f084fffa0. It is a stronger Neural Rendering inspection workload than the rigid Lincoln cast because one controlled scene combines several different material and temporal signals:

• the face uses separate 2K skin albedo, tangent-space normal, and roughness maps, exposing fine pore-scale normal response and broad roughness changes;
• the open eyes have separate iris, sclera, eye-back, cornea, tearline, and caruncle surfaces, producing wet-eye highlights and high-contrast layered edges that a solid statue cannot provide;
• textured lips and mouth-interior geometry add thin occlusion boundaries, curved specular transitions, teeth/tongue detail, and newly revealed pixels; and
• deterministic blink and smile morph motion, combined with the turntable, exercises temporal motion around eyelids, lips, cheeks, and their disocclusions instead of moving only a rigid mesh.

This added scene complexity does not change the native feeder contract. The guide still renders the same four authenticated, same-size WebGPU resources: RGBA16F HDR color, RG16F current-to-previous pixel motion, R32F raw non-linear depth, and distinct UAV-capable RGBA16F output. It still uses the same registration pass, marker, Dawn D3D12 device/direct queue, and native copy/DLAA/feature-1004 bridge described above. A separate unregistered depth32float attachment remains responsible for ordinary raster visibility.

The default bundle is deliberately limited to the head GLB and six adjacent texture files. CMake fails configuration if any file has the wrong byte count or SHA-256, and the browser repeats the exact checks at startup before creating GPU resources:

File	Bytes	SHA-256
vitruvian_head.glb	10,189,832	54efb42e9f3dd7e7cf3c3e86ed5298f3ba26e341d5743245cbe2621c547c5f1f
vit_face_bc.png	7,835,475	7f5314694e267a7fb7270eab6159bb4a988220e13060cfabd7194df14a164a6d
vit_face_n.png	5,950,785	4223812ccc96211f6aa3ad61da314d2295ee459e4751081c9e35a45b0c0fd6b3
vit_face_rough.png	10,064,534	f9911cd24f8aa5c81a3fd32ac977d45b36bcf2f7404b11749aca1024fca41400
vit_iris.png	581,172	e46a988b904b49db6343457215353a309dc67c19e03a6d02e00dea8fb5c51e49
vit_sclera.png	965,536	72bcb85327cf67ef0b0b35a8b6822293bc2059f9f11314a9aebffc95f31e08a7
vit_mouth.png	3,018,410	2e4d0f7e5a2f28613ed54bbd07fa2300b62a6c2b98dc7c1f6f0ac5ce5fe8da64

All model and texture uploads finish before the frame loop, preserving the requirement that the authenticated native-output marker is the last command in the guide submission. The raw-JavaScript loader remains intentionally bounded to the audited local assets: it rejects unrecognized layouts, arbitrary external resources, required extensions it does not implement, malformed sparse or out-of-bounds accessors, and integrity mismatches. It is not a general scene framework.

The upstream notice dedicates the head and vit_*.png character textures to CC0 1.0 and traces them to CharMorph's CC0 "Vitruvian" base, relicensed from "Antonia Polygon." The character is synthetic rather than a captured identity: ChromiumRTX loads no webcam, photograph, face scan, or user biometric data, making it a privacy-safe repeatable subject for the local test. Exact provenance and credits are recorded in the asset manifest and third-party notices.

Only the audited head and face/eye/mouth maps are included. The upstream body, hair, source .blend files, Mixamo clips, and Mixamo-derived animations are excluded. In particular, the upstream statement that its Mixamo material is usable under Adobe's license does not make those files CC0 or part of ChromiumRTX.

Lincoln fallback and comparison

The Smithsonian 150,000-triangle Abraham Lincoln life-mask scan remains an explicit fallback and rigid comparison case. It has 86,245 vertices and embedded 4096×4096 base-color, normal, and occlusion maps, with a deterministic turntable of approximately ±20 degrees. Unlike Vitruvian, it has no separate wet-eye, iris/sclera, mouth-interior, or facial-morph workload. That makes it a useful stable control when comparing the additional material and motion complexity of the default scene.

Because the Lincoln source has no tangent accessor, its shader reconstructs a tangent basis from position/UV derivatives and includes finite fallbacks for degenerate UV gradients. The exact GLB is Y-up and faces +Z; its camera is calculated from full indexed-mesh bounds, viewport aspect, and the worst-case depth across the turntable arc. It remains inside an 88% safe frame rather than depending on a hand-tuned camera constant.

The unmodified Lincoln file is also checked by CMake and the browser:

Size:    8,592,364 bytes
SHA-256: 4a40428307bf6908fc5ab603c1884a811355795d2c21c0d92d5a149e9bd265b9

The Smithsonian designates the Lincoln model CC0/public domain. Both scenes are local, offline-reproducible workloads. Their geometry, materials, and motion can reveal different failure modes, but neither scene by itself proves that DLAA or Neural Rendering is active, nor has a Vitruvian-versus-Lincoln quality improvement been measured. Use the native evidence criteria below for feature activation and make any image-quality comparison from captured data, not from the choice of subject.

Native provider

When built with a locally supplied NVIDIA NGX SDK, the provider:

• validates the hooked device's adapter LUID and NVIDIA vendor ID;
• initializes NGX with ChromiumRTX's own project GUID and an optional local feature search path;
• checks NVSDK_NGX_Parameter_SuperSampling_Available;
• creates a same-resolution Super Sampling feature with NVSDK_NGX_PerfQuality_Value_DLAA, low-resolution motion vectors, automatic exposure, and HDR input;
• evaluates with the registered color, output, raw depth, and motion resources, zero jitter, scale 1.0, and the page's reset serial; and
• uses three allocator/list slots plus a fence so the GPU submission detour does not wait for an in-flight native slot.

If the SDK was not compiled in, the adapter is unsupported, NGX initialization fails, or DLSS capability/feature creation fails, the same provider remains useful as a deterministic same-device CopyResource transport. The UI and log report that degraded mode; they do not label it DLAA.

Experimental Streamline feature-1004 adapter

When the feature-1004 build gate is enabled and Neural Rendering is selected, the provider attempts a manual D3D12 Streamline integration on Dawn's existing device, adapter LUID, direct queue, and authenticated resources. It does not inject or load renodx-dlss5.addon64. Initialization is deliberately bounded:

1. Require the four locally supplied runtime files listed in the build section and validate each embedded signature with Windows WinVerifyTrust.
2. Load the installed NVIDIA _nvngx.dll into this GPU process and locate the feature-name table only if all 18 preceding names and the empty feature-18 slot exactly match the expected layout.
3. Temporarily point only that process-local slot at dlssnr, initialize Streamline feature 1004 in D3D12/manual-hook mode, attach Dawn's device, and query support using the actual adapter LUID.
4. Resolve the private slDLSSNRSetOptions entry point, obtain a frame token, set constants and per-frame resource tags, and evaluate feature 1004 on the provider command list.
5. Free feature resources, call slShutdown, and restore the original mapping pointer on normal shutdown or any initialization failure.

The mapping change exists only in the current msedgewebview2.exe GPU process. ChromiumRTX does not patch the NVIDIA driver file on disk, modify a system-wide registry value, or leave the pointer changed after adapter shutdown. The table scan fails closed when an NVIDIA driver changes the verified layout.

The first proof target is intentionally direct and same-resolution: distinct RGBA16F color and UAV-capable RGBA16F output textures of identical extent. The adapter submits this four-tag contract for every evaluated frame:

Streamline tag	Registered resource	Required interpretation
private reserved tag 70	Color	Full-resolution HDR input, distinct from output
private reserved tag 71	Output	Full-resolution writable neural output
kBufferTypeMotionVectors	Motion	Dense current-to-previous RG16F motion in pixels
kBufferTypeDepth	Depth	Raw non-linear R32F depth matching the supplied projection and depthInverted convention

The control deck publishes the complete recovered options block in one revisioned transaction rather than adding a second IPC path:

Control	Accepted range / values	Initial value
Intensity	0.00–1.00	1.00
Local tone	-1.00–+1.00	+1.00
Local structure	-1.00–+1.00	+1.00
Global tone	0.00–1.00	1.00
Skin structure	-1.00–+1.00	-1.00
Style	integer 0–6	2
NR render preset	integer 0–7	0
Automatic mask	off/on; no external tag-72 texture	off
Performance mode	Performance, Balanced, Quality, Ultra Performance, or 1:1 DLAA	1:1 DLAA

The master Native processing switch disables all provider work. The processing-mode selector chooses exactly one of copy, public 1:1 DLAA, or feature-1004 Neural Rendering, so direct NGX DLAA and Streamline NR are never initialized concurrently.

All four resources arrive in the controlled RENDER_TARGET resting state. Motion constants use (1 / width, 1 / height) because the guide already stores pixel displacement. Color and output aliasing, missing motion/depth, mismatched dimensions, or a zero extent are rejected. The optional private control-mask tag is not part of this first proof.

The feature number, reserved tags, slDLSSNRSetOptions name, and 72-byte version-3 options structure are unpublished/private ABI recovered from the specific signed runtime used for this experiment. They are not a compatibility promise from NVIDIA and may change or disappear with any driver, Streamline, or DLSSNR update.

Caution

The manual-hook presentation lifecycle is not complete. A full Streamline integration is expected to route presentation through its upgraded swap-chain/common presentation path exactly once per frame; that path also services Streamline's deferred resource garbage collection. ChromiumRTX does not yet connect that presentation hook inside the WebView2 GPU subprocess. Even if feature-1004 evaluation succeeds, treat long runs and resize cycles as unsafe, monitor GPU-process memory, and do not call this production-ready.

Build

Requirements:

• Windows x64
• Visual Studio 2026 with Desktop C++
• CMake 3.24 or newer
• WebView2 Evergreen Runtime
• For DLAA: an NVIDIA RTX GPU/driver, the NVIDIA NGX SDK headers/import library, and a locally licensed nvngx_dlss.dll
• For experimental Neural Rendering: a lawfully obtained local Streamline feature-1004 SDK/runtime root containing the full headers and the four signed NVIDIA runtime files described below

Configure, build, and test from PowerShell:

# Start in the root of your ChromiumRTX clone.
cmake --preset x64 `
  -DCHROMIUMRTX_ENABLE_NGX=ON `
  -DCHROMIUMRTX_NGX_SDK_ROOT="C:\path\to\your\ngx-sdk" `
  -DCHROMIUMRTX_NGX_RUNTIME_DIR="C:\path\to\your\licensed-runtime" `
  -DCHROMIUMRTX_ENABLE_DLSS_NR=ON `
  -DCHROMIUMRTX_STREAMLINE_SDK_ROOT="C:\path\to\your\streamline-feature-1004-root"
cmake --build --preset release --parallel
ctest --preset release --output-on-failure

Always provide your own explicit NGX paths for a reproducible public build; machine-local paths are not part of the project contract. CHROMIUMRTX_NGX_SDK_ROOT must contain include/nvsdk_ngx.h and lib/Windows_x86_64/nvsdk_ngx_d.lib.

CHROMIUMRTX_STREAMLINE_SDK_ROOT is a source-external SDK/runtime root. Its required layout is:

<root>\include\sl.h
<root>\include\...the remaining Streamline headers...
<root>\bin\x64\sl.interposer.dll
<root>\bin\x64\sl.common.dll
<root>\bin\x64\sl.dlss_nr.dll
<root>\bin\x64\nvngx_dlssnr.dll

The locally exercised package is an ABI hybrid: its sl_version.h reports Streamline SDK 2.12.0, while the signed plug-in/runtime files report 2.13.0.0. ChromiumRTX deliberately compiles against the supplied headers and passes their sl::kSDKVersion to slInit; it does not manufacture a 2.13 version token. Keep the header and binary set from one matching local package. An arbitrary public Streamline checkout is not assumed to contain feature 1004 or its private option structure.

The Neural Rendering adapter is compiled only when CHROMIUMRTX_ENABLE_DLSS_NR=ON and all of the checked root files exist. The option is on by default, but an empty root still produces a build without the adapter; setting it explicitly records the high-risk opt-in in a reproducible configure command. Use -DCHROMIUMRTX_ENABLE_DLSS_NR=OFF to guarantee that the private adapter is omitted.

To build and test only the deterministic bridge/copy transport:

cmake --preset x64 -DCHROMIUMRTX_ENABLE_NGX=OFF
cmake --build --preset release --parallel
ctest --preset release --output-on-failure

The build pins:

• Microsoft.Web.WebView2 SDK 1.0.4129.50
• MinHook v1.3.4
• the seven-file Vitruvian CC0 workload bundle at upstream commit bdecdcd537b4031fdd0fb299b7e4f93f084fffa0, with every exact size and SHA-256 listed in the workload table above
• Smithsonian Lincoln GLB at SHA-256 4a40428307bf6908fc5ab603c1884a811355795d2c21c0d92d5a149e9bd265b9

WebView2 is read from the NuGet cache when present or downloaded with a pinned SHA-256. An extracted SDK can be selected with -DCHROMIUMRTX_WEBVIEW2_ROOT=<path>. Outputs are placed in build\bin\Release beneath the clone.

Every build refreshes the staged web directory, including both pinned workloads, so JavaScript- or asset-only edits do not leave a stale page beside the executable. When configured paths exist, the post-build step also copies the local nvngx_dlss.dll and the NGX SDK license.txt beside the executable. For a feature-1004 build, CMake also stages exactly the four user-supplied files from <root>\bin\x64 beside ChromiumRTX.exe. That output directory is the process-local Streamline plug-in/runtime root consumed by the injected hook. The hook refuses Neural Rendering if any file is missing or fails its embedded Windows signature check. ChromiumRTX never stages or loads renodx-dlss5.addon64.

None of those NVIDIA binaries are part of this repository. Do not commit or redistribute them with the source, a release, a diagnostic bundle, or a public test artifact. A successful Authenticode check establishes only that Windows accepts the embedded signature under the machine's current trust state; it is not a redistribution license. The check is cache-only and does not perform an online revocation lookup.

Public repository and binary policy

The source repository must remain reproducible without checking in local SDKs, runtime DLLs, generated binaries, logs, WebView2 profile data, or game files. In particular, do not commit or attach any of the following unless their owner has separately granted redistribution rights and the maintainers have reviewed that grant:

• nvngx_dlss.dll, nvngx_dlssnr.dll, sl.interposer.dll, sl.common.dll, sl.dlss_nr.dll, or any other NVIDIA SDK/driver payload;
• renodx-dlss5.addon64, ReShade binaries, or files extracted from a game;
• build/, out/, GPU-hook logs, crash dumps, or WebView2 user-data; or
• locally signed, patched, reverse-engineered, or test-only DLLs.

The build accepts local paths so each developer can supply lawfully obtained dependencies without placing them in source control. Review THIRD_PARTY_NOTICES.md and the upstream license terms before distributing any compiled build.

Licensing

No project-wide source-code license has been selected yet. Public visibility alone does not grant permission to copy, modify, or redistribute ChromiumRTX. Choose and add an explicit project license before accepting reusable code or publishing source/binary releases intended for redistribution. The third-party notices apply only to their identified components and are not a license for ChromiumRTX itself.

CTest currently covers injector boundaries, exported hook ABI, the fixed shared-memory/marker protocol contract, the pinned glTF/texture asset contract, and fake-WebGPU loader uploads, mip generation, morph data, and cleanup.

Run

From the clone root, run run-experiment.cmd, or launch the executable explicitly:

& .\build\bin\Release\ChromiumRTX.exe `
  --unsafe-gpu-hook-experiment

The page waits for successful injection before requesting a normal navigator.gpu adapter/device, verifies and uploads the selected workload (Vitruvian by default, Lincoln as the fallback/comparison), and then registers the same four guide resources. Pause workload and Resume workload stop and restart controlled frame production without creating a first-frame motion spike. The native log is written to:

build\bin\Release\logs\gpu-hook.log

For a public DLAA run, look for all of these milestones in order:

FEEDER opened control map Local\ChromiumRTX.Feeder.v2.<pid>
D3D12CreateDevice ... adapter="NVIDIA ..." vendor=0x10DE
FEEDER registration marker captured on command list
FEEDER NGX: Verified NVIDIA adapter for NGX: ...
FEEDER NGX: DLSS feature ready: 1:1 DLAA ...
FEEDER frame submitted serial=... mode=DLSS-1:1-DLAA ... copyFrames=0 ngxResult=1

Feature creation alone proves setup, not frame evaluation. A run is end-to-end DLAA-verified only when at least one FEEDER frame submitted line reports mode=DLSS-1:1-DLAA, the matching native-enqueue watermark advances, the page displays native output, and the WebView2 GPU process remains alive. ngxResult=1 is the NVIDIA NGX SDK's success result. Those ordinary-DLAA messages do not prove Neural Rendering.

For the experimental path, signed DLL presence, mapping success, slIsFeatureSupported(1004), and slDLSSNRSetOptions success are still only setup milestones. Neural Rendering evidence requires all of the following for the same controlled frame sequence:

• slEvaluateFeature(1004) returns sl::Result::eOk on the provider command list, making the native dlss_nr_active state true;
• the feature-1004 evaluation counter and submitted-provider frame counter advance rather than the DLAA or copy counters;
• the Neural Rendering command list is enqueued on Dawn's direct queue and the matching native-enqueue watermark advances;
• the page consumes the registered native output instead of its fail-open guide color; and
• the GPU process remains alive without a provider failure or device-loss record.

Do not label a screenshot, loaded-module list, support badge, or successful initialization line as DLSS 5 evidence without those evaluation and submission conditions.

Verified evidence on this machine

On September 1, 2026, with WebView2 Runtime 151.0.4129.107, an NVIDIA GeForce RTX 5080, and the NVIDIA NGX SDK/runtime, the live GPU-process log verified the following. The 3000-frame evidence was retained at build/bin/Release/logs/gpu-hook.dlss-proof-3000.log as a local validation artifact; logs and binaries are intentionally not committed:

• the shared feeder mapping opened in the selected WebView2 GPU PID;
• the actual Dawn D3D12 device used NVIDIA vendor 0x10DE, with its adapter description and LUID logged rather than inferred from the machine's GPU list;
• the four controlled allocations appeared as R16G16B16A16_FLOAT, R16G16_FLOAT, R32_FLOAT, and UAV-capable R16G16B16A16_FLOAT at the same dimensions;
• the exact registration marker was captured from a submitted command list;
• NGX initialized successfully and reported Super Sampling availability;
• a 1:1 DLAA feature was created successfully for those dimensions;
• evaluated frame serials advanced from 1 through 3000 while the same WebView2 GPU process remained alive;
• every sampled progress record reported mode=DLSS-1:1-DLAA, with dlssFrames equal to providerFrames, copyFrames=0, and ngxResult=1 (success); and
• the post-run failure scan found no provider failure or device-loss record.

The provider has only three allocator/list slots and will skip or fall back rather than reuse a slot whose retirement fence has not completed. Advancing to 3000 consecutive DLSS submissions with copyFrames=0 therefore also proves that provider fence retirement and allocator reuse occurred throughout the run, not merely that 3000 command lists accumulated on the CPU.

That retained run is end-to-end proof of the NVIDIA NGX 1:1 DLAA path through a normal WebView2 WebGPU workload. It predates the opt-in feature-1004 adapter and must not be cited as Neural Rendering evidence.

It also predates the Vitruvian default workload. The asset change does not retroactively turn this bridge evidence into a Vitruvian-specific quality or feature-1004 result; a new captured run must satisfy the evidence criteria above before making either claim.

Lincoln comparison-workload smoke run

After the Lincoln workload was integrated on September 1, 2026, a fresh bounded run on the same RTX 5080 provided additional model-specific evidence:

• Dawn created the expected 2,759,840-byte interleaved vertex payload and 1,800,000-byte 32-bit index payload;
• the base-color texture appeared as a 4096×4096 sRGB resource and the normal and occlusion maps appeared as two 4096×4096 linear resources;
• the unregistered scene depth appeared as D32_FLOAT, alongside the registered RGBA16F, RG16F, R32F, and UAV-capable RGBA16F resources;
• the authenticated registration marker was captured after model upload;
• the NGX 1:1 DLAA feature was created for the guide dimensions; and
• evaluated Lincoln frame serials advanced with mode=DLSS-1:1-DLAA, copyFrames=0, and ngxResult=1 before the bounded test host was closed.

The asynchronous WGSL compilation checks and indexed guide draw must complete before the page posts its started state or submits registration, so reaching those native milestones also verifies that the Lincoln loader and WebGPU pipeline initialized successfully. This smoke run remains evidence of ordinary NGX 1:1 DLAA, not a feature-1004 evaluation.

Scope and limitations

• The bridge works because the bundled page cooperates. Native D3D12 hooks cannot reliably infer which texture is color, motion, depth, or output in an unrelated site.
• It assumes the controlled marker leaves the four registered resources in the documented legacy RENDER_TARGET state. This is not a general Dawn resource state tracker.
• Its public path uses DLAA at 1:1 resolution; its private feature-1004 first proof is also direct 1:1 color-to-output evaluation. It is not a WebGPU upscaling API, does not synthesize missing motion/depth, and does not expose either feature as a browser standard.
• Feature 1004, NGX feature 18, reserved resource tags, and the options layout are unpublished/private ABI. Signature validation does not make that ABI stable, public, licensed for redistribution, or supported.
• Streamline's manual-hook presentation/deferred-GC integration is unresolved; successful evaluation does not establish resize safety or long-run resource hygiene.
• Browser/runtime updates may change GPU process layout, D3D12 entry points, sandbox behavior, or Dawn command recording. The hook is intentionally tied to a lab runtime and guarded by explicit opt-in.
• A Chromium/Dawn fork remains the more maintainable route for arbitrary-page semantics and first-class synchronization.

Relevant upstream interfaces

• DLSS5-Feeder reference
• NVIDIA NGX SDK
• WebView2 ICoreWebView2Environment8
• WebView2 environment arguments
• Chromium WebGPU adapter parsing
• Dawn debugging toggles
• MinHook