A named GPU with no WebGPU: why a site reads it as fake

The first question is simple: a page asks the browser for the graphics card name.

The second answer never reaches the page: the browser keeps that survey to itself. What gets out is the consequence, and loudest of all is WebGPU.

1. 1

   The name you picked

   The vendor and the renderer: a site reads that pair straight off the page.

2. 2

   The state the browser keeps

   One row for each capability, and the row holds a state rather than a name.

3. 3

   What a site puts together

   A named card with no WebGPU behind it is worth a second look.

Profiles often live on a rented Windows server, and a server like that has no graphics card of its own. That is exactly what makes its answer worth reading in full.

Every row of the capability table comes back switched off. Some of the work goes to software rendering, and behind the rest there is nothing at all.

Out of fourteen feature rows the server handed five to software rendering: the canvas, page compositing, rasterisation, video decoding and video encoding. The processor does all of it, slowly and honestly, and the drawing speed shows it too.

The other nine are switched off outright, and among them the two a platform notices most: WebGL and WebGPU. A page asking to draw a triangle gets a refusal rather than a picture.

Next to the feature table the browser leaves a line about who does the drawing: «Microsoft Basic Render Driver» through ANGLE over Direct3D 11. That is the standard software renderer of Windows, and it signs with its own name.

A platform reads that same line and draws its own conclusion: a server, not a laptop. The profile is powerless here, because the line is not written by it.

So on a rented server a pair forms that a platform sees whole: the card name comes from the profile and sounds like a laptop, while the state comes from the machine and sounds like a server with no card. Each half alone is ordinary; together they argue, and the argument shows in a single request.

Hence one piece of advice: pick the card name to fit the machine the profile lives on. For a profile on a cardless server, a laptop card name only does harm: the platform adds the two answers up and gets a machine that does not exist.

WebGPU is a second road to the same hardware. On a machine like that it is not narrow but absent: there is nothing there to ask in the first place.

Run without a window or with a real window on screen, the card answers the same way: three ways of starting, each of them twice, all 6 attempts alike.

• Started as it ships

  No entry point at all.

• A software adapter on request

  No entry point, and the request had nothing to attach itself to.

• Software rendering throughout

  No entry point, on a run without a window and on one with a window alike.

A launch flag chooses which adapter serves WebGPU. Against a capability already switched off it is powerless: the browser marked it before any adapter came into the question.

That mark sits a layer underneath the thing flags control. No combination of them moved it, and adding more flags to a profile changes nothing here.

The card name arrives at a site as a pair: the vendor and the renderer move together. Every platform has its own pool of such pairs.

Pick another pair in the WebGL field (Fingerprint > Change values) and the processor architecture the profile reports is redrawn along with it. A card from one family beside a processor from another describes a machine nobody sells.

1. 1

   The pair moves together

   A vendor without its matching renderer is a mismatch any check can see.

2. 2

   The platform picks the pool

   A Windows renderer line looks nothing like the one a Linux machine produces.

3. 3

   The processor follows the card

   Choosing another renderer redraws the architecture the profile reports.

The list of cards belongs to the platform: a Windows desktop profile has seven of them, macOS ten. The draw from that list falls to a profile by its seed, so two of your profiles usually get different cards.

The name arrives as a pair: the vendor and the renderer travel together and do not change apart. A pair made of foreign halves would stand out more than any single line.

The core count of an Apple chip is fixed by the chip: M1 is eight, M2 Max twelve, M3 Max fourteen or sixteen. A profile takes its number from the set belonging to that very card.

One shared set across all chips would hand an M2 ten cores, which does not exist. So every class of card has its own set, and the harmonising runs when edits are saved.

A rented machine with no card answers that way because of the machine, not because the profile broke. It cannot be changed from the profile: the page reads the state from the browser, and the browser from the system.

If live rendering matters to you, take a machine with a card. On such a machine those same feature rows come alive, and the profile no longer answers with emptiness.

A WebGPU snapshot could not be taken on that machine, because there was nothing to take one from. A line that never ran we count as failed rather than skipped, and a build like that we do not accept.

So what you hear from us about WebGPU on Windows stops where the measurement stopped. A road nobody has driven is not a road we call open.