majority of our WebGPU examples error with: GPUQueue.copyExternalImageToTexture: Cannot get origin from source
Categories
(Core :: Graphics: WebGPU, defect)
Tracking
()
People
(Reporter: valigursky, Assigned: ErichDonGubler)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
Steps to reproduce:
Load this example: https://playcanvas.vercel.app/#/graphics/model-textured-box
but majority of other examples there behave the same
and in top right corner switch it to use WebGPU
Actual results:
error in the javascript console:
Errors: GPUQueue.copyExternalImageToTexture: Cannot get origin from source
Expected results:
The texture should load and a spinning textured cube should rendered, similarly to WebGL mode.
Both Chrome and Safari can run all examples without any problem.
Example that do not use textures seems to work in WebGPU mode, for example:
https://playcanvas.vercel.app/#/misc/hello-world
Updated•11 months ago
|
Updated•11 months ago
|
| Assignee | ||
Updated•11 months ago
|
| Reporter | ||
Comment 2•6 months ago
|
||
Just pinging this hoping to have this fixed soon. I've noticed Firefox 141 might ship WebGPU on Windows, but pretty much none of our examples work as they all depend on this functionality to load textures.
| Assignee | ||
Comment 3•6 months ago
|
||
As this is only used in the source.origin field for
GPUQueue.copyExternalImageToTexture, we can keep this validation in
the body of this method, for now.
Updated•6 months ago
|
| Assignee | ||
Comment 4•6 months ago
•
|
||
When I open the link in the OP's STR, the error message states:
Uncaught DOMException: GPUQueue.copyExternalImageToTexture: Cannot get origin from source
…which corresponds to dom/webgpu/Queue.cpp:420-423 in current Firefox code:
if (!aSource.mOrigin.IsGPUOrigin2DDict()) {
aRv.ThrowInvalidStateError("Cannot get origin from source");
return;
}
This is happening because the application is providing a sequence (i.e., [0, 0]) instead of a dictionary. It's obvious from the code that the method is designed to handle sequences properly (minus validation for the length of the sequence), but we have this incorrect guard clause that bails early when we provide a sequence. Oops!
I've filed a patch to fix the above problem, and that appears to fix the STR for me locally. So, I think the dependency link I set against bug 1921454 is inaccurate.
Comment 5•6 months ago
|
||
Is this a candidate for beta uplift? We have at least one user saying they're impacted.
| Assignee | ||
Comment 6•6 months ago
|
||
I was actually wondering that. I don't see why not; it's a pretty low-risk patch, IMO!
I'll plan on asking for uplift unless somebody objects. 🙂
| Assignee | ||
Comment 7•6 months ago
|
||
As this is only used in the source.origin field for
GPUQueue.copyExternalImageToTexture, we can keep this validation in
the body of this method, for now.
Original Revision: https://phabricator.services.mozilla.com/D255663
Updated•6 months ago
|
| Assignee | ||
Updated•6 months ago
|
| Assignee | ||
Comment 8•6 months ago
|
||
Comment 10•6 months ago
|
||
| bugherder | ||
Comment 11•6 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined: WebGPU will not have an impactful but low-risk fix that allows certain applications to run
- Code covered by automated testing: no
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: N/A
- Risk associated with taking this patch: Low
- Explanation of risk level: We change validation in a way that it no longer incorrectly blocks certain cases that merge early with existing well-tested paths that have automated test coverage.
- String changes made/needed: None
- Is Android affected?: no
Comment 12•6 months ago
|
||
| Assignee | ||
Updated•6 months ago
|
Comment 14•6 months ago
|
||
| bugherder | ||
Updated•6 months ago
|
Updated•6 months ago
|
Comment 15•6 months ago
|
||
| uplift | ||
Description
•