-
Notifications
You must be signed in to change notification settings - Fork 329
Description
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):
- Create a command encoder
- Begin a compute pass
- Begin another compute pass
- End both compute passes
- 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.