-
Notifications
You must be signed in to change notification settings - Fork 27
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 #185
Comments
Thanks @LeviPesin for filing a proposal! This is the first investigation effort proposal we've gotten, and I want to make sure it's clear what to expect. For an investigation effort, we'll ask for a list of tasks to be completed, in order to bring the spec and tests into a good enough shape to do a regular focus area proposal in the coming year. Given the state of WebGPU, I suspect you intended to file a regular focus area proposal? If that's the case, we can just edit the description and change the label. |
I've filed this as an investigation effect proposal mainly because there are currently no tests and the specification constantly changes. If it is better to change this issue to a focus area proposal I wouldn't oppose. |
@LeviPesin I see. What would be the goal of the investigation, is to write a test suite? |
Yes, and to finalize the API (it changes constantly). |
The work of finalizing the API should happen in the appropriate working group. Neither WPT nor its Interop project are a place to write web standards. Perhaps writing tests could be an investigation project. Although, any area that needs tests could be a project. What needs investigating? I think this needs a more compelling case. What work is needed and why is Interop 2023 the right place to do that work? |
From the investigation efforts description:
At least issues in V1 milestone should be fixed and WPT tests should be added. I think that Interop is the right place to do this work because WebGPU is a really needed feature and definitely should appear and become stable in all browsers. |
@LeviPesin the interop effort is perhaps best thought of as a planning or project management tool, not a pool of resources that we can deploy to help. The people who would do work on WebGPU testing would most likely be the same people who are currently involved with WebGPU spec or implementation work, like @kainino0x @toji @litherum. When evaluating this proposal we'll go and ask them if they think that tracking their work with a public benchmark helps or not. I don't want to presume the conclusion, but I will say that WebGPU would be unlike the investigation efforts in Interop 2022. There, we had existing features that had been shipped long ago, where there was still evidence of web developer pain points, and where it wasn't just a matter of passing existing tests to solve the problem. #201 is another example of a more typical investigation effort, where we need to do some work on our testing infrastructure itself in order to properly test mobile browsers. Some mechanism for joint prioritization of new important features that are early in the specification/implementation/test lifecycle would be super valuable, but it's not what we're trying to do with Interop 2023, as our Focus Areas are grounded in test results, and the precedent for Investigation Efforts is existing features and infrastructure. All that being said, I think we should handle this with the proposal review process in https://github.com/web-platform-tests/interop/tree/main/2023#after-a-proposal-is-accepted. |
To provide some more data, WebGPU does has a work in progress test suite that's already large, but still incomplete (the API is large). It is being developed at https://github.com/gpuweb/cts and targets being buildable in a way that integrates with WPT if needed by implementers. The set of issues @LeviPesin linked is mostly editorial, we are tracking non-editorial V1 issues closely and there are about 10 for the API and 10 for the language (trending down slowly). Editorial issues numbers have been going down significantly thanks to efforts from editors and others. |
WebGPU is a P4 for Google's closure library "This is probably relevant to goog.graphics?" |
I don't think goog.graphics uses WebGPU or even WebGL? |
Thank you for proposing WebGPU for inclusion in Interop 2023. We wanted to let you know that this proposal was not selected to be part of Interop this year. As mentioned in the comments, WebGPU conformance test suite is being actively developed in the WebGPU community group and is deemed to be outside the scope of Interop 2023 investigation efforts. For an overview of our process, see the proposal selection summary. Thank you again for contributing to Interop 2023! Posted on behalf of the Interop team. |
Description
WebGPU is a new low-level GPU API to access platforms such as Vulkan, similarly as how WebGL allows to access OpenGL.
Rationale
WebGPU is extremely useful for 3D developers and 3D libraries developers, because it is much faster than WebGL, because it allows low-level GPU access.
It is not enabled in any browser currently by default, but is behind a flag in all major five browsers.
Investigation Roadmap
Draft specification: https://gpuweb.github.io/gpuweb/
No tests in WPT yet: https://wpt.fyi/results/?label=master&label=experimental&aligned&view=subtest&q=webgpu
The text was updated successfully, but these errors were encountered: