WebGPU Compatibility Mode vs. Core: A Browser Game Shipping Framework

WebGPU compatibility mode is a restricted capability tier intended to support older graphics APIs. For browser games, the practical choice between compatibility mode and core WebGPU depends on the renderer's required.

WebGPU Compatibility Mode vs. Core: A Browser Game Shipping Framework

WebGPU compatibility mode is a restricted capability tier intended to support older graphics APIs. For browser games, the practical choice between compatibility mode and core WebGPU depends on the renderer's required capabilities and performance on physical target devices.

Chrome 146 deployment

Chrome 146 introduced opt-in WebGPU compatibility mode on Android through OpenGL ES 3.1. The announcement described support for ChromeOS through OpenGL ES 3.1 and Windows through Direct3D 11 as areas the Chrome team was exploring, rather than shipped support.

See What's New in WebGPU (Chrome 146).

Request the lowest supported feature level

The WebGPU specification defines "core" as the default featureLevel. An application that supports compatibility mode can request it explicitly:

const adapter = await navigator.gpu.requestAdapter({
  featureLevel: "compatibility",
});

The specification recommends making one adapter request at the lowest feature level the application supports, inspecting the returned adapter for optional capabilities, and requesting those capabilities when creating the device. requestAdapter() returns null if the implementation or system cannot supply the requested feature level.

A compatibility-defaulting adapter uses compatibility default limits and excludes core-features-and-limits from its default feature set. If an implementation cannot enforce compatibility-mode validation, the specification permits it to treat the request as a core request.

The following pattern requests core capabilities when the adapter offers them and otherwise creates a compatibility-defaulting device. Checking the resulting device feature set identifies the tier that was enabled:

async function createGameDevice() {
  if (!navigator.gpu) return null;

  const adapter = await navigator.gpu.requestAdapter({
    featureLevel: "compatibility",
  });
  if (!adapter) return null;

  const canEnableCore = adapter.features.has("core-features-and-limits");
  const device = await adapter.requestDevice({
    requiredFeatures: canEnableCore ? ["core-features-and-limits"] : [],
  });

  return {
    adapter,
    device,
    tier: device.features.has("core-features-and-limits")
      ? "core"
      : "compatibility",
  };
}

These rules are defined in the WebGPU Candidate Recommendation Draft.

Audit compatibility limits

The specification defines different core and compatibility defaults for several limits relevant to renderers:

| Limit | Core default | Compatibility default | |---|---:|---:| | maxStorageBuffersInVertexStage | 8 | 0 | | maxStorageBuffersInFragmentStage | 8 | 4 | | maxStorageTexturesInVertexStage | 4 | 0 | | maxUniformBufferBindingSize | 65,536 bytes | 16,384 bytes | | maxInterStageShaderVariables | 16 | 15 | | maxColorAttachments | 8 | 4 |

Use the reported limits to check the renderer's shader-stage bindings, uniform-buffer binding sizes, inter-stage variables and color-attachment counts. A compatibility release requires every production pipeline to remain within the limits of the compatibility device.

Test on physical devices

Roblox's official performance guidance is not WebGPU-specific, but it supports the need for physical-device testing: emulation cannot fully reproduce frame rate, memory pressure, thermal throttling or input latency on real hardware. The guidance identifies frame rate, memory and load time as the three principal areas for hardware performance testing.

Test those measurements on devices representative of the intended audience for each renderer tier.

Shipping gate

Ship compatibility mode only if the complete renderer stays within the compatibility device's reported limits and meets the project's frame-rate, memory and load-time targets on representative hardware. If required pipelines exceed those limits, use core WebGPU or create a deliberately reduced compatibility renderer.