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.
