"Promise Ordering" section should mention device lost promise ordering

[teoxoy]

Device loss can cause async pipeline creation to succeed (vacuously) when it would normally have failed. The spec should require a reasonable ordering of device loss and async pipeline promises in this case.

Currently the "Promise Ordering" section says:

WebGPU does not make any guarantees about the order in which these promises settle (resolve or reject), except for the following:

• For some GPUQueue q, if p1 = q.onSubmittedWorkDone() is called before p2 = q.onSubmittedWorkDone(), then p1 must settle before p2.
• For some GPUQueue q and GPUBuffer b on the same GPUDevice, if p1 = b.mapAsync() is called before p2 = q.onSubmittedWorkDone(), then p1 must settle before p2.

Applications must not rely on any other promise settlement ordering.

However the list is not complete because in cases where the device becomes lost, GPUDevice.lost is always guaranteed to settle before any other promise. This is easily observable if device.destroy() is called before any of the other methods that return a promise.

Some relevant CTS tests:
https://gpuweb.github.io/cts/standalone/?q=webgpu:api,validation,state,device_lost,destroy:createComputePipelineAsync:*
https://gpuweb.github.io/cts/standalone/?q=webgpu:api,validation,state,device_lost,destroy:createRenderPipelineAsync:*

[jimblandy]

[edit: Teo persuaded me I was wrong; see below]

I think the committee's conclusion is correct: contrary to this issue's claim, we can't promise anything. But it is a bit surprising to see that:

• when a pipeline promise is resolved to a pipeline due to device loss, this must occur after the device loss promise is resolved

• and yet, we cannot make any ordering guarantee, because we can never know whether the pipeline promise was resolved due to successful completion or device loss

A note would here would have saved me some confusion. I can draw up a PR.

[Kangz]

GPU Web WG meeting 2025-07-16

• KN: I probably didn’t write anything down about this because there are no guarantees about when device loss happens in the first place. Even if you call destroy you’re still racing with other async stuff.
• KN: For onsubmittedworkdone and mapasync, we can’t tell whether the destroy operation will complete before the actual work, so we don’t know. Teo linked to some async pipeline tests, I haven't looked at these. If they are assuming that async pipeline creation will take longer than destroy, I don't think that's valid, and we need to fix the tests.
• JB: When Firefox implemented call buffering, batching up sequences of JS API calls to transmit over IPC, we also ended up batching the promise resolution, and get back a list of promises to resolve. That's probably why Teo was looking at this, had to choose an order. If it turns out we don't want to specify it, then that's an easy requirement for our implementation, but the spec should have a note if it's not ordered.
• CW: I think it’s correct that we can’t specify an order, because there are two things racing to complete on the device timeline: figuring out that the queue / compilation has finished, and on the other hand the “lose the device” algorithm triggered by destroy. Since they’re racing on the device timeline, the spec can’t require an ordering.
• CW: Can we call this editorial?
• JB: I think so.
• RESOLVED: Editorial: make it clear that there are no guarantees here

[jimblandy]

Okay, contrary to my prior comment, @teoxoy persuaded me that there is additional behavior that the spec could require. In particular, when asynchronous pipeline creation would fail, but device loss causes it to "succeed" anyway, the spec could promise that the device loss promise is resolved before the pipeline's promise is resolved "successfully".

Here's the example Teo concocted that shows what should be unexpected:

async function test() {
  const adapter = await navigator.gpu.requestAdapter();
  const device = await adapter.requestDevice();
  
  let isLost = false;
  const lostPromise = device.lost.then(() => { isLost = true; });

  const module = device.createShaderModule({ code: "@compute @workgroup_size(1) fn main() {}" });

  // device.destroy(); // uncomment to try one of the other expected branches
  
  device.createComputePipelineAsync({compute: {module,entryPoint:"missing"},layout:"auto"})
    .then(res => {
      if (isLost) {
        console.log("expected: on device loss, invalid creation requests return valid pipelines")
      } else {
        console.error("unexpected: we shouldn't get a valid pipeline if the device was not lost since the entryPoint doesn't exist")
      }
    })
    .catch(e => {
      if (isLost) {
        console.error("unexpected: on device loss, even invalid creation requests should return valid pipelines")
      } else {
        console.log("expected: error on invalid creation request with a device that was not lost")
      }
    });

  device.destroy();
}
test()

[kainino0x]

Apologies that I didn't look at this until now.

I agree that would be a good thing to guarantee. I think same with popErrorScope(), getCompilationInfo(), and mapAsync() (even though mapAsync() doesn't pretend to succeed).

And I think Teo is correct that the spec actually guarantees this (due to the order of steps here), we just need to document it in that section.