这是indexloc提供的服务,不要输入任何密码
Skip to content

Error Scope Callback Order #430

@austinEng

Description

@austinEng

ErrorHandling.md does not talk about the ordering of error scope callbacks. Error scopes can be used to determine when the enclosed operations are complete. Given that we currently have operations on both the CPU and GPU timeline, and in the future we may support multiple queues, we need to discuss the order that error scope promises can resolve.

There are two main clarifications I'd like to propose:

  • Child scopes must resolve before parent scopes
  • Sibling scopes may resolve in any order

Child scopes must resolve before parent scopes

This point should be mostly non-contentious. Because error scope promises must not resolve until enclosed operations are complete, then naturally if error scope A encloses error scope B, then A must resolve after B. The child scope is inside its parent so the parent should resolve only when the child is complete.

Sibling scopes may resolve in any order

Rationale / Pros
ErrorHandling.md gives an example use case of using a 'none' error scope filter to wait for pipeline compilation to complete. device.createPipeline is enclosed in an error scope. When the scope resolves, the pipeline is swapped with the current pipeline. This can be useful when a cheap rendering pipeline is used at first and then swapped after a pipeline with more expensive shaders compiles.

If there is an imposed ordering on sibling error scope resolution (ex. in the order they were pushed), then an application cannot respond to complete of operations as soon as they occur. There are multiple independent timelines which are unrelated to the order error scopes are pushed / popped. ex.)

  • Synchronous validation and queue.submit
  • Pipeline compilation and GPU memory allocation
  • Submission of commands on multiple queues (if we have it)

If sibling error scopes may resolve in any order, then applications can respond more quickly to completion of the enclosed operations.

Cons
This may be a portability concern if browsers, or even GPU hardware, complete operations in different orders, and an application chooses to rely on the order of Promise resolution.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions