Pith. sign in

REVIEW 3 major objections 3 minor 1 cited by

Global Pass Barriers Without Per-Resource RHI Tracking: A Cross-Vendor Study with Blade

T0 review · 3 major / 3 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Global pass barriers without per-resource tracking can match a tracked graphics API on GPU time — and beat it on host cost.

desk verdict A serious empirical study of barrier placement in a tracking-free RHI; the main placement results are robust, the scope-axis claims rest on a post-hoc floor, and a log-storage contradiction needs fixing. read the letter →

arxiv 2607.26506 v1 pith:MGXVZGMB submitted 2026-07-29 cs.GR cs.PF

Dzmitry Malyshau This is my paper
classification cs.GRcs.PF
keywords globalbarriersper-resourcetrackingrendergraphVulkanwgpubarrierscopeGPUspanRHIdesign
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that a low-level graphics API can drop per-resource state tracking entirely and still be competitive on GPU time, as long as an engine-level graph (or the application itself) supplies the places where dependencies actually exist. It compares Blade, a tracking-free RHI that issues global pass-boundary barriers, with wgpu, a tracked RHI, on matched workloads across five Vulkan devices plus an Apple/Metal case study. Removing fifteen redundant barriers from sixteen independent compute passes cuts GPU span by 29.3% on an RTX 5070 and 32.3% on an RX 7900 XT; independent render passes recover 32.4% and 7.3% on the same discrete parts, while a Radeon 780M integrated GPU loses about 42% at high pass counts. Deriving a barrier's stage/access scope from the kinds of the surrounding passes—without tracking any resource—saves 5.0% on an NVIDIA graphics chain and 6.7% on an AMD compute chain. The tracked baseline costs more host record-and-submit time in every measured cell, though the paper is explicit that this end-to-end gap cannot be attributed to tracking alone.

What carries the argument

The load-bearing mechanism is a global memory barrier whose stage/access scope is computed from an encoder-wide pass-kind bitmask, not from any resource. The encoder accumulates the pass kinds recorded since the previous barrier (the source scope is the union, which stays safe when some boundaries are suppressed) and reads the kind of the pass being opened for the destination scope; an explicitly placed barrier can derive only its source, since the consumer is not yet known. A second mechanism is the `manual_barriers` encoder flag that suppresses automatic pass-boundary barriers, letting an application place identical global barriers only where its dependency graph requires them. The paper's

What would settle it

Run the staggered partial-DAG microbenchmark the paper itself calls for — two interleaved independent chains sharing one real dependency edge — on the RTX 5070 and RX 7900 XT. If a single required global cut forfeits most of the 29–32% overlap saving measured on fully independent workloads, then the claim that engine-level graphs can lower arbitrary dependency graphs to global cuts without losing scheduling freedom is false. A weaker but direct check: repeat the B-exp-all control on the RX 7900 XT compute-chain cell with fifty process-level repetitions instead of ten; if the control floor wide

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that a rendering-hardware interface that deliberately tracks no per-resource state can still be competitive on device time, because a global memory barrier placed at pass boundaries is a sufficient synchronization primitive for many workloads. Removing fifteen redundant such barriers from sixteen independent compute passes reduces GPU span by 29.3% on an RTX 5070 and 32.3% on an RX 7900 XT, and by 32.4% and 7.3% for independent render passes on the same discrete parts; the same removal hurts on a Radeon 780M integrated GPU at high pass counts, beyond that cell's stability floor. When the barrier's stage/access scope is derived from the kinds

Load-bearing premise

The whole directional edifice rests on the post-hoc stability floor: two configurations that issue the same timed global barrier calls are assumed to bracket every non-focal source of measurement noise, and if that floor understates launch-to-launch or driver-state variation in a cell, the small credited effects (5.0%, 6.7%, 7.3%) and even the large ones are only as trustworthy as that floor.

Editorial extensions

If this is right

  • An engine that already has a render graph can keep that graph as the source of truth and give a tracking-free RHI only dependency cuts; the graph need not be duplicated as per-resource state inside the abstraction.
  • Pass-kind-derived barrier scope is a cheap internal change — no API surface, no resource declarations — and should be taken before manual placement, since explicit barriers cannot narrow their destination scope.
  • Removing redundant barriers is not always a win: on the Radeon 780M it costs roughly 42% of GPU span at 32 and 64 passes, so manual placement must be a profiler-guided option, not a default.
  • A tracked RHI like wgpu has higher record-and-submit host cost in every measured cell (1.3–5.9× on the fixed matrix), but this gap cannot be quoted as 'the cost of tracking' because it bundles validation, lifetime management, and command translation.
  • Metal's framework-managed hazard tracking should stay enabled: opting out costs 8.5–11× for dependent passes in the measured harness, so the tracking-free design is specific to explicit APIs like Vulkan.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the per-cell control floors are taken at face value, the paper's strongest implicit conclusion is that barrier cost cannot be predicted from command counts or driver source at all — mechanism explains measurements after the fact but does not replace them; the practical consequence is that engine teams should profile their own frames rather than adopt a vendor policy.
  • The destination-scope dependence suggests a concrete API redesign the paper measured but did not recommend: holding an explicit barrier until the next pass opens would recover the 5–6.7% scope saving for application-placed barriers, at the cost of moving the barrier's position in the command stream.
  • The most important untested case named in the paper is a staggered partial DAG — two interleaved chains whose dependency edges cross different global cuts. A testable prediction is that a single required global cut forfeits most of the 29–32% overlap saving; this would bound the engine-level-graph claim.
  • Because the study contains no mobile tile-based GPU, the design's largest risk (a pass-boundary barrier forcing a tile flush and reload) is entirely unmeasured; if the mechanism is as costly as vendor guidance suggests, the tracking-free policy would need a different default on that class.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 3 minor

Summary. Blade, a tracking-free RHI that keeps Vulkan images in GENERAL and issues global pass-boundary barriers, is compared with matched wgpu programs across six GPUs. In within-Blade experiments, removing redundant barriers on independent compute passes shortens GPU span by 29.3% on an RTX 5070 and 32.3% on an RX 7900 XT; independent-render effects are 32.4% and 7.3% on the same discrete parts, while the Radeon 780M shows a resolved regression at some pass counts. Chain workloads show no placement effect. Deriving barrier scope from surrounding pass kinds, without per-resource tracking, is reported to save 5.0% on an NVIDIA graphics chain and 6.7% on an AMD compute chain, with no AMD render-involving scope cell resolving. wgpu's record-and-submit host cost is higher in every measured cell, though the paper does not attribute this to tracking alone. A RADV source reading addresses driver-side barrier expansion and elision, and an Apple/Metal case study is included.

Significance. If the results hold, the paper provides a substantial empirical data point for the architectural claim that an engine-level render graph can supply dependency cuts without per-resource state inside the RHI. The strengths are real: raw data and a table-builder are public and content-addressed; output hashes agree across thousands of runs; captured barrier tables are byte-identical; the placement headline is far above its control floor; and the 0/15 chain nulls form a useful same-request negative control. The paper also separates driver-source reading from measurement and reports two-sided mispredictions. The scope-axis evidence is weaker, as discussed below, and should not carry the design conclusion until the stability control is matched.

major comments (3)
  1. [§5.5, §6.3, §8] The scope-axis and Intel placement claims are gated by a post-hoc floor that is not a same-request control for scoped requests. B-exp-all issues the broad unscoped barrier; no scoped policy can be paired as an identical-request control because an explicitly placed barrier cannot narrow its destination (§3.1). The closest credited cells clear by only ~2×: RX 7900 XT c-chain 6.7% vs 2.3%; Intel c-ind 6.5% vs 2.4%; Intel m-ind 8.2% vs 4.0%. With ten process blocks, exchangeable inner resampling, and no second-day run (§8), an understated floor at that level would overturn these cells while leaving the placement headline intact. The §11 'lightweight aggregate pass-kind state' design conclusion depends on these cells; please add a matched test-retest/alternate-day control and sensitivity analysis, or explicitly re-label the scope and Intel cells as descriptive/hypotheses.
  2. [§3.1, §5.2, §10] The archival status of the scoped-barrier validation is inconsistent. §3.1 says the development-time synchronization-validation logs are not retained and the validation result 'is therefore not yet archival evidence and must be repeated and published before submission'; §5.2 and §10 say every Vulkan machine's round begins with a retained synchronization-validation matrix and that the ancillary files contain retained validation logs. Because the pass-kind scope table's correctness rests on validation plus a source-level argument, please reconcile which claim is true for the submitted artifact.
  3. [§8, §6.3] The robustness limitations named in §8 are not addressed for the cells that matter most. Ten process-level blocks estimate tails coarsely, the inner bootstrap treats time-ordered observations as exchangeable, and there is no second-day or in-process-alternation run. This is especially consequential for the B-hazard-scoped/B-auto-scoped comparison used to localize the scope saving to the destination side and for cells whose full interval is only ~2× its floor. Please perform the process-median-only or moving-block re-analysis the paper itself suggests, or weaken the directional wording for these cells.
minor comments (3)
  1. [Table 3, §6.2] The Radeon 780M mixed-independent regression +25.7% [24.8,57.4] clears its 23.9% floor by less than one percentage point at the lower endpoint. Given the admitted launch-to-launch dispersion in §5.5, this cell is threshold-edge and should be labeled as such rather than described simply as resolved.
  2. [§2.2, Table 2] The RADV source reading cites Mesa main revision d18d598e275d, while Table 2 lists RADV 25.2.8 and 26.0.3. Please state whether the quoted predicates, especially the radv_dst_access_flush coherence check, were verified to exist in the measured driver versions, or explicitly treat the source account as version-specific.
  3. [§6.4, Table 4] The host-cost linear-regime averages are restricted to 1–8 passes, with the 16-pass values falling in a steeper regime. The table makes this clear, but the text in §6.4 could state it more prominently so readers do not interpolate the reported per-pass increments to the 16-pass matrix.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity detected: central claims are direct measurements against external baselines and explicit controls, not derivations from fitted or self-cited inputs.

full rationale

The paper's load-bearing numbers—29.3%/32.3% placement effects, 5.0%/6.7% scope effects, the chain nulls, and the wgpu host gaps—are all empirically measured against external baselines or within-Blade controls; none is obtained by fitting a parameter and then declaring it a prediction. The pass-kind scope table in Section 3.1 is fixed by API semantics and explicitly not fitted to the measured cells. The by-construction controls (B-exp-all and the chain nulls) are clearly labeled as controls: the paper says 'their timed barrier calls are the same by construction' and uses them only as stability diagnostics, not as evidence for an effect, even noting that the floor is 'a conservative stability diagnostic, not a confidence bound' (§5.5). Self-citations refer to the author's implementation PR, fork, and field report; they identify the code and motivating bug but are not the proof of the performance claims, which rest on raw timing collections, output hashes, and a content-addressed artifact. The post-hoc RADV explanation is openly labeled as arriving after the measurements and is presented as a mechanism reading, not as a predicted result; the paper explicitly records where its own a-priori prediction failed. No load-bearing derivation reduces to an equation equal to its input, a fitted parameter renamed as a prediction, or a self-citation chain; therefore the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

The paper fits no model and introduces no free parameter: every effect is a direct measurement with paired bootstrap intervals. Its claims rest instead on domain assumptions about Vulkan semantics and timestamp validity, a statistical-inference premise (the post-hoc per-cell floor), and the applicability of RADV source at Mesa main d18d598e275d to the installed radv 26.0.3/25.2.8 drivers. The DCC/FMASK layout claims are explicitly labeled source readings, not controlled layout experiments. No invented entities are postulated: the proposed 'lightweight aggregate pass-kind state' is implemented, pinned, measurable code, not an unexplained postulate.

assumptions (6)
  • domain assumption Vulkan barrier semantics and TOP_OF_PIPE timestamps correctly encode the intended execution/memory dependencies and measure GPU span as claimed.
    Invoked throughout §3, §5.4, §6: the entire timing methodology assumes barriers order work as specified and that per-pass timestamp differences telescope into a meaningful span, including Blade's final barrier inside the window versus wgpu's two-timestamp window.
  • ad hoc to paper The per-cell identical-request control (B-exp-all) bounds all non-focal measurement instability at the same cell/pass count, so effects are credited only when their interval clears that floor.
    Sections 5.5 and 6.1; explicitly post-hoc ('This post-hoc floor is a conservative stability diagnostic, not a confidence bound or a preregistered equivalence test'). This is the gate for every directional claim in the paper.
  • domain assumption Hierarchical bootstrap percentile intervals with 10 process-level repetitions and exchangeable inner samples give trustworthy coverage for the reported effect sizes.
    Section 5.4; the paper admits 'Ten blocks still estimate tails coarsely' and that inner resampling treats time-ordered observations as exchangeable (§8), with no second-day or alternation sensitivity run.
  • domain assumption RADV source read at Mesa main revision d18d598e275d describes the behavior of the installed radv 26.0.3 and 25.2.8 drivers in the measured set.
    Section 2.2 pins the reading to 'Mesa main at revision d18d598e275d' (25 July 2026), while Table 2 lists radv 26.0.3-1ubuntu1 and 25.2.8-0ubuntu; the source revision is not the measured driver revision. The mechanism explanations in §2.2.1 and §6.3 depend on this.
  • domain assumption Matching output hashes across policies and implementations implies correct synchronization in the measured workloads.
    Section 5.2: FNV-1a hashes of output rows plus the retained synchronization-validation runs. A subtly wrong schedule that produced identical bytes would evade the hash check; the archival status of the validation logs is internally contradicted (§3.1 vs §5.2/§10).
  • domain assumption The measured workload set (16 equal microsecond passes, two dependency endpoints, compute/render/mixed) is adequate for the claims as scoped.
    Sections 5.2 and 8: the paper explicitly bounds claims to these workloads and states that application frames and partially dependent DAGs are not established. Still, the boundary proposed in §7 is a hypothesis supported by microbenchmarks and one field report.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Global Pass Barriers Without Per-Resource RHI Tracking: A Cross-Vendor Study with Blade." pith.science (2026). https://pith.science/paper/MGXVZGMB

@misc{pith2026260726506,
  author       = {Pith},
  title        = {Pith review of: Global Pass Barriers Without Per-Resource RHI Tracking: A Cross-Vendor Study with Blade},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MGXVZGMB}},
  note         = {Machine review of arXiv:2607.26506}
}
read the original abstract

Explicit graphics APIs expose memory dependencies, per-resource accesses, and image layouts. wgpu reconstructs and validates this state; Blade keeps Vulkan images in GENERAL, tracks no per-resource state, and issues global pass-boundary barriers. We isolate barrier placement and stage/access scope within Blade, compare matched wgpu programs end-to-end, and measure six GPUs from four vendors, including exploratory Apple/Metal results. Removing fifteen redundant barriers from sixteen independent compute passes reduces GPU span by 29.3% on an RTX 5070 and 32.3% on an RX 7900 XT. It reduces independent-render span by 32.4% and 7.3% on the same discrete parts, but increases Radeon 780M span by 42.4% at 32 passes, beyond a 12.3% count-specific stability floor. No dependent-chain placement effect clears the study's cell-specific stability criterion. Deriving global barrier scope from the pass kinds around each boundary, without tracking any resource, saves 5.0% on an NVIDIA graphics chain and 6.7% on an AMD compute chain; no AMD render-involving scope cell resolves. wgpu's record-and-submit cost is higher in every measured cell, but this end-to-end difference cannot be attributed to tracking alone. RADV source shows why command counts do not predict these costs: broad global dependencies expand to several flush and invalidate requests that the driver may partly elide. It also shows that persistent GENERAL retains DCC under the measured RDNA conditions but disables FMASK. The resulting Blade direction is lightweight aggregate pass-kind state in a tracking-free RHI: an upstream render graph selects global dependency cuts, while aliasing, cross-queue use, exceptional layouts, and arbitrary per-resource DAG edges remain resource-aware engine responsibilities.

Figures

Figures reproduced from arXiv: 2607.26506 by the authors.

Figure 1
Figure 1. The field report’s frame, as Blade emitted it and as it was restructured. The figure shows what the barriers permit, not what the hardware achieved. Two of the eight barriers separate work with no resource in common — ray tracing from the reflection view, and the reflection view from the main one — and on RADV each requests both compute and pixel partial flushes without regard to whether the passes share a resource … view at source ↗
Figure 2
Figure 2. GPU-span effect of removing the redundant barriers ( [PITH_FULL_IMAGE:figures/full_fig_p011_2.png] view at source ↗
Figure 3
Figure 3. Barrier placement: percent difference in GPU span between [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Barrier scope at fixed placement: percent difference in GPU span between [PITH_FULL_IMAGE:figures/full_fig_p014_4.png]
Figure 5
Figure 5. Figure 5: Average cost of one additional pass on the [PITH_FULL_IMAGE:figures/full_fig_p014_5.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Meganeura: Portable GPU Training and Inference through Vulkan and Metal

    cs.LG 2026-08 conditional novelty 6.0 of 10

    One compact Rust stack using Vulkan/Metal can train and deploy neural networks at useful, sometimes vendor-competitive performance on consumer GPUs.

Reference graph

Works this paper leans on

28 extracted references · cited by 1 Pith paper

  1. [1]

    RDNA performance guide.https:// gpuopen.com/learn/rdna-performance-guide/,

    AMD. RDNA performance guide.https:// gpuopen.com/learn/rdna-performance-guide/,

  2. [2]

    Resource synchronization.https: //developer.apple.com/documentation/metal/ resource-synchronization, 2026

    Apple. Resource synchronization.https: //developer.apple.com/documentation/metal/ resource-synchronization, 2026. Includes pre-Metal-4 hazard tracking and Metal 4 queue synchronization; accessed 2026-07-28

    2026

  3. [3]

    Task graph renderer at Activision.https: //enginearchitecture.org/downloads/ reac2023_task_graph_renderer.pdf, 2023

    Charlie Birtwistle and François Durand. Task graph renderer at Activision.https: //enginearchitecture.org/downloads/ reac2023_task_graph_renderer.pdf, 2023. Rendering Engine Architecture Conference 2023; accessed 2026-07-28

    2023

  4. [4]

    Vulkan barriers ex- plained.https://gpuopen.com/learn/ vulkan-barriers-explained/, 2016

    Matthäus Chajdas. Vulkan barriers ex- plained.https://gpuopen.com/learn/ vulkan-barriers-explained/, 2016. AMD GPUOpen; accessed 2026-07-24

    2016

  5. [5]

    A. C. Davison and D. V. Hinkley.Bootstrap Methods and their Application. Cambridge Uni- versity Press, 1997.https://doi.org/10.1017/ CBO9780511802843

    1997

  6. [6]

    Render dependency graph in Unreal Engine.https://dev.epicgames

    Epic Games. Render dependency graph in Unreal Engine.https://dev.epicgames. com/documentation/en-us/unreal-engine/ render-dependency-graph-in-unreal-engine,

  7. [7]

    Proposal: groups of commands with a shared barrier in- stead of forced always? Or manual barri- ers?https://github.com/kvark/blade/issues/ 343, 2026

    EriKWDev and Dzmitry Malyshau. Proposal: groups of commands with a shared barrier in- stead of forced always? Or manual barri- ers?https://github.com/kvark/blade/issues/ 343, 2026. Blade issue 343, opened 16 April 2026, closed 10 June 2026

    2026

  8. [8]

    Vulkan specifi- cation.https://registry.khronos.org/vulkan/ specs/latest/html/vkspec.html, 2026

    Khronos Vulkan Working Group. Vulkan specifi- cation.https://registry.khronos.org/vulkan/ specs/latest/html/vkspec.html, 2026. Accessed 2026-07-24

    2026

Show all 28 references
  1. [9]

    D3D12 enhanced barriers preview

    Bill Kristiansen. D3D12 enhanced barriers preview. https://devblogs.microsoft.com/directx/ d3d12-enhanced-barriers-preview/, 2021. Microsoft DirectX Developer Blog; accessed 2026- 07-28

    2021

  2. [10]

    Bootstrapping clus- tered data in R using lmeresampler.The R Journal, 14(4):103–120, 2023.https://doi.org/10.32614/ RJ-2023-015

    Adam Loy and Jenna Korobova. Bootstrapping clus- tered data in R using lmeresampler.The R Journal, 14(4):103–120, 2023.https://doi.org/10.32614/ RJ-2023-015

    2023

  3. [11]

    Addmanual_barriersflag tocommandencoderdesc.https://github.com/ kvark/blade/pull/355, 2026

    Dzmitry Malyshau. Addmanual_barriersflag tocommandencoderdesc.https://github.com/ kvark/blade/pull/355, 2026. Blade pull request 355, merged 10 June 2026

    2026

  4. [12]

    Metal untracked hazard mode on Apple M3.https: //github.com/kvark/blade/blob/ 87ed06750877f336ad1c54fa5005a0b799f488d7/ docs/metal-hazard-tracking.md, 2026

    Dzmitry Malyshau. Metal untracked hazard mode on Apple M3.https: //github.com/kvark/blade/blob/ 87ed06750877f336ad1c54fa5005a0b799f488d7/ docs/metal-hazard-tracking.md, 2026. Investi- gation of 24 July 2026 at Blade revision ba0fb5a; note frozen at study revision 87ed06750877

    2026

  5. [13]

    Dzmitry Malyshau and contributors. Blade. https://github.com/kvark/blade/tree/ blade-sync-study, 2026. Study branch; the study-code snapshot is taggedsync-study-v1, and every collection manifest in the ancillary data records the exact measured revision

    2026

  6. [14]

    wgpu synchronization-study benchmark fork

    Dzmitry Malyshau et al. wgpu synchronization-study benchmark fork. https://github.com/kvark/wgpu/tree/ blade-sync-study, 2026. Benchmark at revi- sion 7d37a77c086f3d3b8a9dbda6b476cd7ac195fcfc, taggedblade-sync-study-v1

    2026

  7. [15]

    RADV:radv_cmd_buffer.cand radv_image.c.https://gitlab.freedesktop

    Mesa contributors. RADV:radv_cmd_buffer.cand radv_image.c.https://gitlab.freedesktop. org/mesa/mesa/-/tree/d18d598e275d/src/ amd/vulkan, 2026. Read at Mesamainrevision d18d598e275d, 25 July 2026

    2026

  8. [16]

    Vulkan runtime: vk_synchronization.c.https://gitlab

    Mesa contributors. Vulkan runtime: vk_synchronization.c.https://gitlab. freedesktop.org/mesa/mesa/-/blob/ d18d598e275d/src/vulkan/runtime/vk_ synchronization.c, 2026. Read at Mesamain revision d18d598e275d, 25 July 2026

    2026

  9. [17]

    FrameGraph: Extensiblerendering architecture in Frostbite.https://www.gdcvault

    YuriyO’Donnell. FrameGraph: Extensiblerendering architecture in Frostbite.https://www.gdcvault. com/play/1024612/FrameGraph-, 2017. Game De- velopers Conference 2017; accessed 2026-07-27

    2017

  10. [18]

    Writing portable rendering code with NVRHI.https: //developer.nvidia.com/blog/ writing-portable-rendering-code-with-nvrhi/,

    Alexey Panteleev. Writing portable rendering code with NVRHI.https: //developer.nvidia.com/blog/ writing-portable-rendering-code-with-nvrhi/,

  11. [19]

    Tips and tricks: Vulkan dos and don’ts.https://developer.nvidia.com/blog/ vulkan-dos-donts/, 2019

    Nuno Subtil, Matthew Rusch, and Ivan Fe- dorov. Tips and tricks: Vulkan dos and don’ts.https://developer.nvidia.com/blog/ vulkan-dos-donts/, 2019. Updated 14 January 2025; accessed 2026-07-24

    2019

  12. [20]

    We- bGPU.https://gpuweb.github.io/gpuweb/,

    W3C GPU for the Web Working Group. We- bGPU.https://gpuweb.github.io/gpuweb/,

  13. [21]

    Resource state and lifetime trackers.https://docs.rs/wgpu-core/30.0.0/ src/wgpu_core/track/mod.rs.html, 2026

    wgpu contributors. Resource state and lifetime trackers.https://docs.rs/wgpu-core/30.0.0/ src/wgpu_core/track/mod.rs.html, 2026. wgpu- core 30.0.0 source documentation; accessed 2026-07- 24

    2026

  14. [22]

    Campbell

    Jinyuan Yang, Soumyabrata Dev, and Abraham G. Campbell. RenderKernel: High-level programming for real-time rendering systems.Visual Informat- ics, 8:82–95, 2024.https://doi.org/10.1016/j. visinf.2024.09.004

    2024 doi

  15. [23]

    VK_KHR_unified_image_layouts extension proposal.https://docs.vulkan.org/features/ latest/features/proposals/VK_KHR_unified_ image_layouts.html, 2024

    Shahbaz Youssefi et al. VK_KHR_unified_image_layouts extension proposal.https://docs.vulkan.org/features/ latest/features/proposals/VK_KHR_unified_ image_layouts.html, 2024. Revision 1; accessed 2026-07-24

    2024

  16. [24]

    Editor’s Draft, 27 July 2026, source revi- sion d390da5f80f18e82d9535a40c6f2f1f65e6884ae; accessed 2026-07-28

    2026

  17. [28]

    LuisaRender: A high-performance ren- dering framework with layered and unified in- terfaces on stream architectures.ACM Trans- actions on Graphics, 41(6):1–19, 2022

    Shaokun Zheng, Zhiqian Zhou, Xin Chen, Difei Yan, Chuyan Zhang, Yuefeng Geng, Yan Gu, and Kun Xu. LuisaRender: A high-performance ren- dering framework with layered and unified in- terfaces on stream architectures.ACM Trans- actions on Graphics, 41(6):1–19, 2022. Au- thor manu...

    2022

  18. [2021]

    NVIDIA Technical Blog; accessed 2026-07-28. 25

    2026

  19. [2023]

    Updated for RDNA 3; accessed 2026-07-24

    2026

  20. [2026]

    Unreal Engine 5.8 documentation; accessed 2026-07-28

    2026

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.