This Charter is work in progress. To submit feedback, please use GPU for the Web Github Issues where this charter is being developed.
The mission of the GPU for the Web Community Group is to provide an interface between the Web Platform and modern 3D graphics and computation capabilities present on native system platforms.
The current practice in accelerated graphics for the Web Platform is to use WebGL (as of early 2017). This Community Group aims to produce a more advanced technology with the following features:
If successful, the output from this Community Group will establish a new programming layer for the Web Platform that is more modern, more efficient, more functional, better integrated with other aspects of the Web Platform, and designed to be implemented on a wide variety of modern graphics platform or, in a worst case scenario, in a software fallback. We expect most participants of this Community Group to commit to a Final Specification Agreement.
This Community Group will recommend a Web programming interface for graphics and computation that:
The API will not be restricted to any particular platform technology. Instead, it will be generic enough to be implemented on top of modern GPU libraries, such as Microsoft's Direct3D 12, Apple's Metal, and Khronos's Vulkan.
The deliverables of this Community Group are primarily addressed, either directly or indirectly, to the following audiences:
The typical Web, or even non-Web, developers are a secondary audience, since they often prefer using a higher-level framework rather than the low-level technology. Such developers are an important part of the community, and some of the Community Group's non-normative deliverables are addressed to them.
The scope of work is restricted to the development of a programming interface between the Web Platform and modern 3D graphics and computation capabilities present on native system platforms. The work will not define hardware features or algorithms, and the interface it defines is not intended to be directly exposed by a GPU driver.
The group may produce a draft Charter for a GPU for the Web Working Group at W3C.
The group may also produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance use cases, requirements, or white papers.
The group may produce tutorial or explanatory content designed to help people learn the technical material. For example, an interactive tutorial could introduce the graphics pipeline or shader programming.
The Community Group will develop a test suite that exercises the GPU for the Web API. Please see the GitHub LICENSE file for test suite contribution licensing information.
The Community Group may develop a software library that implements the GPU for the Web work across multiple platforms using existing native APIs. For example, a C++ library that exposes GPU for the Web using Direct3D, Metal or Vulkan. Such software will be developed using the W3C Software and Document License.
The Community Group may develop a continuous integration mechanism to validate the grammar of WebGPU Shading Language against syntactic ambiguities and potential mechanical issues with primary reliance on an open-source, commercially-permissive license tool that can report ambiguity and generate playgrounds that can run on the Web so that community can leverage and extend easily to enhance the ecosystem. Such software will be developed using the W3C Software and Document License.
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.
Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.
Community Group participants agree to make all contributions in the GitHub repository the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
The group will conduct all of its technical work in public. All technical work will occur in the GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list, or to a GitHub issue.
This group will seek to make decisions where there is consensus. Consensus will be assessed by one of:
Where consensus is not clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action.
Participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue).
If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which specification is ultimately chosen by the group to move ahead with.
Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group's public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 Committers, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
As of the date of this document, the initial co-Chairs for the Community Group are Dean Jackson (Apple) and Corentin Wallez (Google).
The initial Committers are:
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.