Bug 200852 - [WebGPU] Implement GPUErrors for and relax GPUBuffer validation rules
Summary: [WebGPU] Implement GPUErrors for and relax GPUBuffer validation rules
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGPU (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P1 Normal
Assignee: Justin Fan
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-08-16 21:56 PDT by Justin Fan
Modified: 2019-08-27 17:01 PDT (History)
7 users (show)

See Also:


Attachments
Patch (23.92 KB, patch)
2019-08-27 15:55 PDT, Justin Fan
no flags Details | Formatted Diff | Diff
Patch for landing (23.92 KB, patch)
2019-08-27 16:22 PDT, Justin Fan
justin_fan: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Fan 2019-08-16 21:56:30 PDT
I misunderstood UsageValidationRules.md; resource usages need to be checked at pass encoding time to e.g. ensure that a GPUBuffer is not bound as both a STORAGE and VERTEX buffer within a single render pass. Across separate passes, such a GPUBuffer can be used as either.
Comment 1 Justin Fan 2019-08-16 21:56:53 PDT
Necessary to make compute demos easier to write.
Comment 2 Radar WebKit Bug Importer 2019-08-16 21:57:33 PDT
<rdar://problem/54419993>
Comment 3 Justin Fan 2019-08-27 15:46:38 PDT
This patch requires a couple follow up patches:

1) GPURender/ComputePipeline classes should follow the hierarchy used here. GPUErrorScopes exist for the sake of the WebGPU API, not the internal classes, and are reported at the top level, so the "WebGPU" object should own the reference. Also makes implementing the rest of "GPUObjectBase" easier to match the spec.

2) The same relaxation of usage rules validation should be applied to GPUTexture creation.

3) GPUProgrammablePassEncoder.setBindGroup, GPURenderPassEncoder.setVertexBuffers, and GPURenderPassEncoder.setIndexBuffer need to enforce the validation rules outlined by https://github.com/gpuweb/gpuweb/blob/master/design/UsageValidationRules.md (and soon in the spec).

Will link bugs after they're created.
Comment 4 Justin Fan 2019-08-27 15:55:53 PDT
Created attachment 377394 [details]
Patch
Comment 5 Dean Jackson 2019-08-27 16:06:17 PDT
Comment on attachment 377394 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=377394&action=review

> Source/WebCore/platform/graphics/gpu/GPUBuffer.h:99
> +    void registerMappingCallback(MappingCallback&&, bool, GPUErrorScopes&);
> +    void unmap(GPUErrorScopes*);
> +    void destroy(GPUErrorScopes*);

Why isn't the GPUErrorScope attached to the buffer itself? Or do different map and unmap calls have different scopes?

Also, why are these pointers? I see it is because destroy can be called with a nullptr from the destructor, but maybe we should have a default error scope that always exists.
Comment 6 Justin Fan 2019-08-27 16:20:05 PDT
(In reply to Dean Jackson from comment #5)
> Comment on attachment 377394 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=377394&action=review
> 
> > Source/WebCore/platform/graphics/gpu/GPUBuffer.h:99
> > +    void registerMappingCallback(MappingCallback&&, bool, GPUErrorScopes&);
> > +    void unmap(GPUErrorScopes*);
> > +    void destroy(GPUErrorScopes*);
> 
> Why isn't the GPUErrorScope attached to the buffer itself? Or do different
> map and unmap calls have different scopes?
> 
> Also, why are these pointers? I see it is because destroy can be called with
> a nullptr from the destructor, but maybe we should have a default error
> scope that always exists.

GPUErrorScopes is owned by the WebGPUBuffer via GPUObjectBase. Both WebGPUBuffer and GPUBuffer methods need access to it, but I chose to do this over having both classes Ref it.

My reasoning was influenced by the second point: the destructor should call the same cleanup functions, but shouldn't "throw exceptions" that would expose GC timing to JavaScript, so it isn't necessary for GPUBuffer to own a ref to GPUErrorScopes, since all errors that can happen at this layer happen because a WebGPUBuffer method was called first.
Comment 7 Justin Fan 2019-08-27 16:22:57 PDT
Created attachment 377400 [details]
Patch for landing
Comment 8 Justin Fan 2019-08-27 16:39:47 PDT
Comment on attachment 377400 [details]
Patch for landing

Clearing flags on attachment: 377400

Committed r249183: <https://trac.webkit.org/changeset/249183>
Comment 9 Justin Fan 2019-08-27 16:39:48 PDT
All reviewed patches have been landed.  Closing bug.