The validation for GPUDevice.createCommandEncoder is mostly missing from the specification https://gpuweb.github.io/gpuweb/#issue-f6026bc8 but there currently seems to be nothing preventing a website from creating 100s of thousands of GPUCommandEncoders, attempting to encode commands, and not calling finish.
There doesn't appear to be any known website or CTS coverage of this, but the default Metal limit for the number of command buffers is documented to be 64. So after the 64th encoder which encodes commands and does not call finish, we would see a hang if the command buffers aren't discarded or complete in some fashion.
An implementation could theoretically store the commands until Queue.submit time to get the correct ordering, but that ends up deferring a lot of work and it would be challenging to predict if the commands need to be buffered or not.
It seems like we should have a limit on the number of open GPUCommandEncoders as most applications are unlikely to run into this issue and attempting to solve it in the implementations for the edge case seems like unnecessary, wasted effort.
It could possibly be a hard coded limit in the validation for https://gpuweb.github.io/gpuweb/#issue-f6026bc8 depending on the other backends.
The validation for
GPUDevice.createCommandEncoderis mostly missing from the specification https://gpuweb.github.io/gpuweb/#issue-f6026bc8 but there currently seems to be nothing preventing a website from creating 100s of thousands of GPUCommandEncoders, attempting to encode commands, and not calling finish.There doesn't appear to be any known website or CTS coverage of this, but the default Metal limit for the number of command buffers is documented to be 64. So after the 64th encoder which encodes commands and does not call finish, we would see a hang if the command buffers aren't discarded or complete in some fashion.
An implementation could theoretically store the commands until Queue.submit time to get the correct ordering, but that ends up deferring a lot of work and it would be challenging to predict if the commands need to be buffered or not.
It seems like we should have a limit on the number of open GPUCommandEncoders as most applications are unlikely to run into this issue and attempting to solve it in the implementations for the edge case seems like unnecessary, wasted effort.
It could possibly be a hard coded limit in the validation for https://gpuweb.github.io/gpuweb/#issue-f6026bc8 depending on the other backends.