On Thu, Jun 5, 2025 at 2:30 AM Mike Taylor <miketa...@chromium.org> wrote:
> On 6/4/25 3:41 AM, 'François Beaufort' via blink-dev wrote: > > Contact emails > > fbeauf...@google.com > > Explainer > > The "texture-compression-bc-sliced-3d" and > "texture-compression-astc-sliced-3d" WebGPU features add respectively > support for 3D textures using Block Compression (BC) and Adaptive Scalable > Texture Compression (ASTC) formats. This lets developers leverage the > efficient compression capabilities of BC and ASTC formats for volumetric > texture data, offering significant reductions in memory footprint and > bandwidth requirements without substantial loss in visual quality. > > This is particularly valuable in fields such as scientific visualization, > medical imaging, and advanced rendering techniques. > > By exposing those capabilities as WebGPU features, developers can > explicitly check for support and provide fallback solutions or alternative > rendering paths when necessary. > > Specification > > https://gpuweb.github.io/gpuweb/#texture-compression-bc-sliced-3d > > https://gpuweb.github.io/gpuweb/#texture-compression-astc-sliced-3d > > At the risk of asking a silly question: the spec talks about "BC > compressed formats" and "ASTC compressed formats", but as a non-expert I > don't know where to go to learn more abut them. Is there some kind of > normative reference for what that means (I don't see any hyperlinks)? Are > there hidden interop challenges here, or does all the tooling that might > produce these things just work™? > That's not a silly question at all. The world of texture compression can be quite opaque to those not deeply embedded in 3D graphics. Both BC (Block Compression) and ASTC (Adaptive Scalable Texture Compression) are types of lossy compression formats specifically designed for use by GPUs. Their primary goal is to reduce the memory footprint and bandwidth required for textures. Historically, BC formats have been the standard on desktop. ASTC on the other hand is the preferred format on most mobile devices. While the formats themselves are standardized at https://registry.khronos.org/DataFormat/specs/1.3/dataformat.1.3.html#_compressed_texture_image_formats, you'll likely need to generate and ship both sets of compressed textures and have your engine select the appropriate one at runtime based on the hardware. See https://github.com/webgpu/webgpu-samples/pull/501/files for instance. For info, ARM's astcenc is considered the reference encoder for ASTC. For BC formats, various tools exist, from those integrated into game engines like Unreal Engine and Unity to standalone utilities like texconv. I've just filed https://github.com/gpuweb/gpuweb/issues/5214 to the WebGPU spec to add normative references for ASTC and BC compressed formats. > > Summary > > Functionality added to the WebGPU spec after its first shipment in a > browser. > > The “texture-compression-bc-sliced-3d” and > “texture-compression-astc-sliced-3d” WebGPU features add respectively 3D > texture support for BC and ASTC compressed formats. > > Blink component > > Blink>WebGPU > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU> > > TAG review > > None > > TAG review status > > Not applicable > > Risks > > Interoperability and Compatibility > > This feature has not yet been implemented in any browser. It has been > approved by the GPU for the Web Community Group, with representatives from > Chrome, Firefox, and Safari. See minutes at > > > https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-07-10#consider-moving-sliced-3d-compressed-bc-texture-to-an-extension-4705 > and > https://github.com/gpuweb/gpuweb/wiki/GPU-Web-2024-07-24#discussapprove-small-details-of-add-texture-compression-bc-sliced-3d-4763 > > > Gecko: No signal (Mozilla members have requested during weekly > standardization meetings that we postpone filing standard positions until > we reach Candidate Recommendation (CR) status in Q4.) > https://github.com/mozilla/standards-positions/issues/1205 > > WebKit: Positive ( > https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933 > ) > > Web developers: Positive (https://github.com/gpuweb/gpuweb/issues/3183) > > 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? > > None > > > Debuggability > > None > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > > No > > All platforms will eventually have support. Will immediately be available > on Android, Android WebView, ChromeOS, Mac, and Windows, since those > platforms already support WebGPU. 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. All the tests about this feature in WebGPU CTS > can be found through https://github.com/gpuweb/cts/issues/3761 and > https://github.com/gpuweb/cts/issues/3967 > > Flag name on chrome://flags > > Enable Unsafe WebGPU > > Finch feature name > > WebGPU.Enabled:UnsafeFeatures > > Requires code in //chrome? > > False > > Tracking bug > > https://issues.chromium.org/issues/342840940 > > Sample links > > https://webgpu.github.io/webgpu-samples/?sample=volumeRenderingTexture3D > > Estimated milestones > > Shipping on desktop > > 139 > > Shipping on Android > > 139 > > 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). > > None > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5080855386783744?gate=6225340422422528 > > 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 blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5LuwN_2tbzyy6W17sn8YZ8oOGYQR-Cfe7P4uka3BQdHuA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5LuwN_2tbzyy6W17sn8YZ8oOGYQR-Cfe7P4uka3BQdHuA%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5JRDAcomrTdf%3DUSeg4KOVoi-5-p21PeXQ2%2BP3n_Ugfjhw%40mail.gmail.com.
