LGTM1 On Wednesday, August 26, 2026 at 10:02:53 AM UTC+2 [email protected] wrote:
> FWIW as developers of the browser game engine Construct ( > https://www.construct.net/) we want this to be able to optimize 3D > rendering in WebGPU. We already use EXT_conservative_depth in the WebGL > renderer where available, and this brings the same feature to WebGPU. > > Ashley > > > On Tue, 25 Aug 2026 at 04:14, 'dan sinclair' via blink-dev < > [email protected]> wrote: > >> There are signals, but indirectly. Developers have requested having >> access to early-z-test ( >> https://github.com/gpuweb/gpuweb/issues/4891#issuecomment-3341897141). >> But, if you write to the `frag_depth` it will disable the early-z test. >> Adding the `less` or `greater` attribute allows the fragment shader to >> write to the fragment depth, while maintaining the early-z optimization >> because the shader knows you're only writing in the depth in a given >> direction. >> >> So, while developers did not specifically comment on this, it is a >> component of providing a comprehensive early-z feature in the future. >> >> dan >> >> >> On Mon, Aug 24, 2026 at 2:54 PM Alex Russell <[email protected]> >> wrote: >> >>> Are there really no signals from developers? Is nobody asking for this? >>> >>> On Monday, August 24, 2026 at 9:03:33 AM UTC-7 Chromestatus wrote: >>> >>>> *Contact emails* >>>> [email protected] >>>> >>>> *Explainer* >>>> https://github.com/gpuweb/gpuweb/blob/main/proposals/fragment-depth.md >>>> >>>> *Specification* >>>> https://github.com/gpuweb/gpuweb/pull/6299 >>>> >>>> *Summary* >>>> Adds the ability to provide a `less` or `greater` modifier to the >>>> `@builtin(frag_depth)` in WGSL. The current `@builtin(frag_depth)` can >>>> potentially introduce a performance penalty due to disabling the early-Z >>>> optimizations on a draw call. The new modifiers allow the explicit setting >>>> of the buffer mode and allow the early-Z optimizations to be applied. >>>> >>>> *Blink component* >>>> Blink>WebGPU >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebGPU%22> >>>> >>>> *Web Feature ID* >>>> webgpu <https://webstatus.dev/features/webgpu> >>>> >>>> *Motivation* >>>> In the current WGSL specification, the mere act of writing to >>>> @builtin(frag_depth) often incurs a significant performance penalty >>>> because >>>> driver heuristics cannot guarantee that the fragment shader output will >>>> adhere to the depth written by the rasterizer's interpolated depth. >>>> Consequently, writing to frag_depth typically forces the GPU to disable >>>> crucial early-Z optimizations for the entire draw call. The introduction >>>> of >>>> a new depth_mode built-in parameter for the @builtin(frag_depth) with >>>> modes >>>> less, and greater directly addressing this performance limitation by >>>> letting the developer express their intent to the hardware. >>>> >>>> *Initial public proposal* >>>> https://github.com/gpuweb/gpuweb/blob/main/proposals/fragment-depth.md >>>> >>>> *TAG review* >>>> *No information provided* >>>> >>>> *TAG review status* >>>> Pending >>>> >>>> *Goals for experimentation* >>>> None >>>> >>>> *Risks* >>>> >>>> >>>> *Interoperability and Compatibility* >>>> This feature has been approved in W3C GPU for the Web WG meetings >>>> including participants from Safari and Firefox. >>>> >>>> *Gecko*: No signal (https://github.com/gpuweb/gpuweb/pull/6299) Feedback >>>> indicated via WebGPU standardization process. >>>> >>>> *WebKit*: Positive (https://github.com/gpuweb/gpuweb/pull/6299) >>>> Specification >>>> approval constitutes a positive signal, per >>>> https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933 >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> *WebView application risks* >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> *No information provided* >>>> >>>> >>>> *Debuggability* >>>> *No information provided* >>>> >>>> *Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>> Yes >>>> All platforms will eventually have support. Will immediately be >>>> available on Android, Android WebView, ChromeOS, Mac, and Windows, where >>>> hardware support is available. Linux is planned to have WebGPU support in >>>> the future, so this feature will become available when WebGPU does. >>>> >>>> *Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>> Yes >>>> WebGPU/WGSL have a conformance test suite ( >>>> https://github.com/gpuweb/cts) that is regularly pulled into Chromium >>>> and part of the testing of Dawn/Tint in Chromium. While the CTS can be >>>> embedded in WPT, the WebGPU team opted to keep it separate in Chromium >>>> testing to use a customized harness for robustness and performance. * >>>> https://github.com/gpuweb/cts/pull/4679 * >>>> https://github.com/gpuweb/cts/pull/4689 >>>> >>>> *Flag name on about://flags* >>>> *No information provided* >>>> >>>> *Finch feature name* >>>> WebGPU >>>> >>>> *Rollout plan* >>>> Will ship enabled for all users >>>> >>>> *Requires code in //chrome?* >>>> False >>>> >>>> *Tracking bug* >>>> https://crbug.com/457993779 >>>> >>>> *Estimated milestones* >>>> >>>> No milestones specified >>>> >>>> >>>> *Anticipated spec changes* >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>> of >>>> the API in a non-backward-compatible way). >>>> *No information provided* >>>> >>>> *Link to entry on the Chrome Platform Status* >>>> https://chromestatus.com/feature/5663304168112128?gate=5657119415205888 >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com>. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMYH%3DOjE5-Yj2G7mX%2B50RANTVgxuCPyon3-yDgEPgskbQddwWQ%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMYH%3DOjE5-Yj2G7mX%2B50RANTVgxuCPyon3-yDgEPgskbQddwWQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f68eb079-aed8-4005-9fa6-6fbc4ebff73cn%40chromium.org.
