New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WebGPU] popErrorScope causes an IPC assertion #9584
[WebGPU] popErrorScope causes an IPC assertion #9584
Conversation
EWS run on previous version of this PR (hash a2fc827) |
Source/WebGPU/WebGPU/Device.mm
Outdated
@@ -287,20 +287,16 @@ static void captureFrame(id<MTLDevice> captureObject) | |||
// https://gpuweb.github.io/gpuweb/#dom-gpudevice-poperrorscope | |||
|
|||
if (!validatePopErrorScope()) { | |||
instance().scheduleWork([callback = WTFMove(callback)]() mutable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto for the other patch. This function philosophically should be async; we should be making it properly async rather than temporarily making it sync.
OK for temporary code, but I think we can do better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should it be async and doesn't scheduleWork() run on the same dispatch queue which the containing function runs? If so, what is the benefit to making it async?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because that's the API contract of promises, you are guaranteed your promise's .then
callback won't run in the middle of your popErrorScope()
call. I'm trying to match the API behavior of the WebGPU IDL as much as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct but we shouldn't impact the web api for due to how the native API is structured. Instead I think we should ensure the contract on the native API in a way that does not impact the web API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused. An app that wants to use WebGPU.framework is going to expect that it behaves the same way as the web API does, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so however native WebGPU still seems under development.
My point is that making the callback asynchronous here negatively impacts users of the web api as now they incur additional latency for the task to return, when it was already asynchronous from the websiteβs perspective.
If we want the native API to appear the same, we should implement that in a way that doesnβt add latency to the web api. This patch doesnβt address that as the web api is priority.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the difference measurable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the answer is "yes", I propose we add a boolean to WGPUInstanceCocoaDescriptor
that represents whether violating the asynchronicity guarantees of the spec is more desirable than upholding them, and set the value of the boolean to true in WebKit and false everywhere else, and then implement both codepaths, and use the boolean to select between them.
If the answer is "no" then we should just use the async codepath everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not measurable especially given the discussion is about popErrorScope
I will try the new IPC sendToStreamWithAsyncReply
to see if we can resolve this issue that way. I'm kind of opposed to using NotStreamEncodableReply as that is a workaround
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@litherum PR updated with sendWithAsyncReply
, I reverted the changes to Device.mm
a2fc827
to
d32cbd7
Compare
EWS run on previous version of this PR (hash d32cbd7) |
d32cbd7
to
2b62217
Compare
EWS run on previous version of this PR (hash 2b62217) |
2b62217
to
8802095
Compare
EWS run on current version of this PR (hash 8802095) |
8802095
to
a60f8cc
Compare
https://bugs.webkit.org/show_bug.cgi?id=251666 <radar://104993240> Reviewed by Myles C. Maxfield. GPUDevice.popErrorScope is supposed to be asynchronous, so use sendWithAsyncReply instead of sendSync. * Source/WebKit/GPUProcess/graphics/WebGPU/RemoteDevice.messages.in: * Source/WebKit/WebProcess/GPU/graphics/WebGPU/RemoteDeviceProxy.cpp: (WebKit::WebGPU::RemoteDeviceProxy::popErrorScope): * Source/WebKit/WebProcess/GPU/graphics/WebGPU/RemoteDeviceProxy.h: Canonical link: https://commits.webkit.org/260413@main
a60f8cc
to
d5a1264
Compare
Committed 260413@main (d5a1264): https://commits.webkit.org/260413@main Reviewed commits have been landed. Closing PR #9584 and removing active labels. |
d5a1264
8802095
π§ͺ ios-wk2π§ͺ api-gtk