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

Error reporting for unbalanced compute/render passes does not match implementations #5207

@andyleiserson

Description

@andyleiserson

I believe the error reporting for unbalanced compute/render passes by implementations (and expected by the CTS) does not match the description in the spec.

Consider the following sequence of operations (I'll use compute passes -- but could also be render passes):

  1. Create a command encoder
  2. Begin a compute pass
  3. Begin another compute pass
  4. End both compute passes
  5. Call finish on the command encoder

(I believe this is done by the encoder_state:pass_end_invalid_order CTS test -- see here)

At step 3, the encoder is already locked, so it will be invalidated, and the second compute pass will be invalid.

The pass end process requires that the parent encoder is locked, but it doesn't require that it was locked by the pass being ended. (Although in the case of valid usage, it must have been.) So I think that whichever of the two passes is ended first, will unlock the encoder. Whichever of the two passes is ended second, should fail the check that parentEncoder.[[state]] must be "locked", and generate a validation error.

Currently, the CTS expects a validation error when encoder.finish() is called in step 5, but does not expect a validation error when the second pass is ended in step 4. Neither Chrome nor Safari produces a validation error in step 4. Firefox has enough issues in this area that I'm not sure it's meaningful to try and assess the current behavior.

As far as what behavior is desirable here, the difference between generating a validation error at step 4, or not, doesn't seem important as long as an error gets raised somewhere, but the behavior of implementations should align with the spec. Since multiple implementations and the CTS agree on behavior and I don't see a clear reason why that behavior is undesirable, I chose to report this as a spec issue.

If this is resolved with a spec change, it might be as simple as saying parentEncoder.state must not be "ended" rather than parentEncode.state must be "locked", but I think the correctness of that relies on an argument that it is not possible to be in a state where a pass is open, the parent encoder is open, and neither the pass nor the encoder is invalid.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions