docs(roadmap): order the graphics queue against what the device measured - #867
Merged
Conversation
The previous A -> B -> C is spent: #785 closed, #826 refuted. The new order is four measurements before any code, then the page pool every remaining feature needs, then its consumers, then the additive features. Also corrected here: the '13.89 ms, budget reachable' headline is unverified (unwarmed, unnamed scene, and four features have landed since), the meshlet side is 0.040 ms with VRAM at 817 of 4096 MiB, and shadows total 1.153 ms - which bounds every shadow-side idea including VSM's.
The user's directive decides the architecture rather than a preference: the engine ships for Windows as well as Linux and for NVIDIA and Intel as well as AMD, and it gets its own upscaler. A vendor SDK cannot be the path a build depends on, so the always-there path is ours (#481) and the vendor backends (#536) become optional on top of it — inverting what #536 said, which was that a vendor's ships and ours is the untested fallback. It also happens to be the largest measured lever here. Per-pixel shading dominates the frame (10.969 ms of 24.8), all shadows total 1.153, and rendering at 67 % linear is 44 % of the pixels: roughly -5 ms, and it compounds with every per-pixel cost added later. #866 is demoted to Phase 2 because its payoff is scale and memory, not cost per pixel. Phase 0 item 1 is closed with its numbers, including the finding it was not looking for: motion vectors ran for nobody at 1.994 ms (#868). Auto exposure moves out of Phase 4 and into Phase 1 as a prerequisite: every temporal resolve takes an exposure input and rejects history in a perceptual space, and this engine's radiance is in the hundreds.
Not the licence, which is where the discussion usually stops. FSR 4 is a neural network whose cost model assumes 8-bit matrix hardware, and wgpu 29 exposes no cooperative or subgroup matrix at all -- checked in wgpu-types-29.0.4/src/features.rs, which has SUBGROUP, SUBGROUP_VERTEX and SUBGROUP_BARRIER and nothing else. naga does implement dot4I8Packed, so an INT8 network is implementable on the vector ALUs, which is exactly the configuration AMD ships as the slow variant: on a 300 W RDNA 3 part FSR 4.1 Quality nets 9 % over native where FSR 3.1 nets 29 %. gfx1150 is RDNA 3.5 and has no FP8 either. What survives is a constraint on #481 rather than a dead end: its inputs are FSR 3.1's six, named and meaning the same, because that contract is what drivers and community layers upgrade behind. FSR 4 can arrive through a #536 backend later without this engine vendoring anyone's trained weights.
The previous entry read "no crate covers this, therefore write it" -- the bottom row of this project's own dependency policy, reached by asking the wrong question. The search asked whether a wgpu upscaler crate exists (it does not) instead of whether AMD's C API can be bound (it can). FSR 3.1's FidelityFX API is a stable C ABI and FSR 4 continues to use it, so one bindgen surface covers FSR 3.1 now and whatever ships behind that ABI later. Phase 1 becomes #536 first, gated on a one-day build spike, because three things are cheap to settle and expensive to assume: the SDK's Vulkan backend needs wine for its shader compiler on an atomic distro, bindgen already fails on this machine over three parallel LLVM installs, and the wgpu HAL interop is unsafe and pinned to wgpu 29. If the spike passes, #481's steps 4-6 are cancelled as reimplementations of what the SDK does. Steps 1-3 survive either way: they improve the TAA that ships today and every backend consumes the motion vectors. FSR 4 over this route is Windows-only -- AMD ships it as signed prebuilt DLLs with no .so. FSR 3.1 covers Linux and all three vendors.
…ut it Not a licence limit and not a hardware one: AMD has shipped no Vulkan backend for FSR 4, so it cannot be integrated into a Vulkan application at all. Every earlier note here reasoning about "the Vulkan backend" was about FSR 3.1. That makes FSR 4 a Windows-only feature reachable through wgpu's D3D12 backend, at the price of a second unsafe interop path -- and it buys nothing on the device the budget is about, which runs Linux. Deferred rather than refused; the one fact that collapses this back into a single path is AMD shipping a Vulkan FSR 4. Also recorded so nobody re-derives it: Adrenalin's automatic upgrade of an FSR 3.1 integration to 4.1.1 is DX12-only, and FSR 4 on Linux today runs through VKD3D-Proton with an INT8/FP16 fallback its authors warn costs performance and image quality on RDNA 2/3 -- which requires being a Windows binary under Wine.
The user's decision, and it survives a premise correction worth keeping: FSR 3.1 *is* usable -- MIT source, native Vulkan backend, all three vendors -- so this is a choice rather than a forced move. Only FSR 4 is out of reach, being DirectX 12 only. The reasons that make it the right choice are about this project: wine for the SDK's shader compiler on an atomic distro, an unsafe interop surface pinned to wgpu 29, a signed library to locate and redistribute, and reach that includes WebGPU and Metal. A bug in ours is a bug we can fix. What is given up is quality, and it is written down rather than discovered: the bar is better than today's TAA at a lower render resolution, not as good as FSR. #536 is deferred, not cancelled. Its trait, UpscalerCaps and startup selection are built in Phase 1 with ours as the first backend behind them, because building the seam while there is one implementation is what makes a second one cheap. UpscaleInputs stays FSR 3.1's six. The reference corpus now carries a licence column: FSR's HLSL is MIT and is the primary reference, Bevy's is MIT/Apache, the rest are papers -- and UE5 TSR, the closest existing thing to this category, is under Epic's EULA and must be read rather than copied.
…there Two things were checked in the vendored sources rather than assumed, and both of the ones that would have blocked a direct port of FSR 3.1's passes are present: SHADER_F16 in wgpu-types-29.0.4/src/features.rs:1657, which its FFX_HALF path leans on, and naga's subgroup operations in front/wgsl/parse/conv.rs:379. So the passes can be transliterated to WGSL with FSR's own tuned constants -- the part nobody can guess -- and the MIT licence permits it outright, with attribution. The user chose C: step 1 (jitter) first because both routes need it, then steps 2-3 for a visible improvement to the TAA that ships today, then the transliteration, arriving with the input infrastructure already validated. That is where ports die -- in the inputs, not the shaders. Recorded with the risk: a transliteration has no oracle, so validation is by eye. The way out if it degenerates is to build #536's FFI backend as a reference to diff against -- a debugging tool, not a change of plan. Also recorded so it is not asked again: wgpu ships no render techniques by design and never will, and Bevy is binding vendors rather than building an upscaler, with dynamic resolution scaling explicitly not planned. Nothing below us is going to solve this.
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The user's call: graphics first, the game waits. The previous A → B → C is spent — #785 closed (the profiler was exonerated), #826 refuted and removed.
Phase 0 — four measurements, no code. Each is a settings flag or a capture, and each bounds an item below it. They come first because three graphics ideas in a row died on their own measurement this week.
temporal_aa: falseshading_rate: 1vs2contact_shadow_steps: 0Phase 1 — #866, new: one page pool + clipmap + invalidation by reach. Not three features; one structure with three consumers, and both halves already have measured precedent here (#780, #847).
Phase 2 — the consumers: #450 (the only item that changes the shape of the cost) and #477 (justified by scale and memory, not frame time — shadows total 1.153 ms). #841/#849 superseded if the pool lands.
Phase 3 — post, atmosphere, clouds. All add to a frame 1.8× over budget.
Corrections this PR also makes to the page: