├── CONTRIBUTING.md ├── README.md ├── SourceCodeLicense └── LICENSE.txt ├── cg-charter.html └── wg-charter.html /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # GPU for the Web 2 | 3 | This repository is being used for work in the [W3C GPU for the Web Community 4 | Group](https://www.w3.org/community/gpu/), governed by the [W3C Community 5 | License Agreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To 6 | make substantive contributions, you must join the CG. 7 | 8 | Contributions to the source code repository are subject to the terms of the 9 | [3-Clause BSD License](https://github.com/gpuweb/admin/blob/SourceCodeLicense/LICENSE.txt). 10 | 11 | If you are not the sole contributor to a contribution (pull request), please identify all 12 | contributors in the pull request comment. 13 | 14 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 15 | 16 | ``` 17 | +@github_username 18 | ``` 19 | 20 | If you added a contributor by mistake, you can remove them in a comment with: 21 | 22 | ``` 23 | -@github_username 24 | ``` 25 | 26 | If you are making a pull request on behalf of someone else but you had no part in designing the 27 | feature, you can remove yourself with the above syntax. 28 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Administrative documents for the GPU on the Web group. 2 | -------------------------------------------------------------------------------- /SourceCodeLicense/LICENSE.txt: -------------------------------------------------------------------------------- 1 | Copyright 2 | 3 | Redistribution and use in source and binary forms, with or without 4 | modification, are permitted provided that the following conditions are met: 5 | 6 | 1. Redistributions of source code must retain the above copyright notice, 7 | this list of conditions and the following disclaimer. 8 | 9 | 2. Redistributions in binary form must reproduce the above copyright notice, 10 | this list of conditions and the following disclaimer in the documentation 11 | and/or other materials provided with the distribution. 12 | 13 | 3. Neither the name of the copyright holder nor the names of its 14 | contributors may be used to endorse or promote products derived from this 15 | software without specific prior written permission. 16 | 17 | THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 18 | AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 19 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 20 | DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 21 | FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 22 | DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 23 | SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 24 | CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 25 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 26 | OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 27 | -------------------------------------------------------------------------------- /cg-charter.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | GPU for the Web Community Group Charter 6 | 7 | 8 | 9 | 10 | 29 | 30 | 31 |

32 | [DRAFT] GPU for the Web Community Group Charter 33 |

34 |

35 | This Charter is work in progress. To submit feedback, 36 | please use GPU for the Web Github Issues 37 | where this charter is being developed. 38 |

39 | 47 |

48 | Goals 49 |

50 |

51 | The mission of the GPU for 52 | the Web Community Group is to provide an interface between the Web 53 | Platform and modern 3D graphics and computation capabilities present on 54 | native system platforms. 55 |

56 |

57 | The current practice in accelerated graphics for the Web Platform is to 58 | use WebGL (as of early 2017). This Community Group aims to produce a 59 | more advanced technology with the following features: 60 |

61 | 75 | 76 |

77 | If successful, the output from this Community Group will establish a 78 | new programming layer for the Web Platform that is more modern, more 79 | efficient, more functional, better integrated with other aspects of 80 | the Web Platform, and designed to be implemented on a wide variety of 81 | modern graphics platform or, in a worst case scenario, in a software 82 | fallback. We expect most participants of this Community Group to 83 | commit to a Final 85 | Specification Agreement. 86 |

87 | 88 |

89 | Scope of Work 90 |

91 | 92 |

93 | This Community Group will recommend a Web programming interface for 94 | graphics and computation that: 95 |

96 | 97 |
    98 |
  1. enables rendering of modern graphics to both onscreen and offscreen drawing surfaces
  2. 99 |
  3. enables computation tasks to be performed, and the results of such tasks to be retrieved
  4. 100 |
  5. This group will also recommend a companion Shading Language that describes the graphics and 101 | computation tasks in a format 102 | that can be translated or compiled into platform-specific instructions
  6. 103 |
104 | 105 |

106 | The API will not be restricted to any particular platform technology. Instead, it will 107 | be generic enough to be implemented on top of modern GPU libraries, such as 108 | Microsoft's Direct3D 12, Apple's Metal, and Khronos's Vulkan. 109 |

110 | 111 |

Target Audiences

112 | 113 |

114 | The deliverables of this Community Group are 115 | primarily addressed, either directly or indirectly, to the following audiences: 116 |

117 | 141 | 142 |

143 | The typical Web, or even non-Web, developers are a secondary audience, since 144 | they often prefer using a higher-level framework rather than the low-level 145 | technology. Such developers are an important part of the community, and some 146 | of the Community Group's non-normative deliverables 147 | are addressed to them. 148 |

149 | 150 |

Out of Scope

151 | 152 |

153 | The scope of work is restricted to the development of a programming 154 | interface between the Web Platform and modern 3D graphics and 155 | computation capabilities present on native system platforms. The work 156 | will not define hardware features or algorithms, and the interface it 157 | defines is not intended to be directly exposed by a GPU driver. 158 |

159 | 160 |

161 | Definitions 162 |

163 |
164 |
GPU
165 | 166 |
Graphics Processing Unit. Typically a piece of hardware dedicated to 167 | efficiently processing graphics and related features.
168 | 169 |
Shading Language
170 | 171 |
A restricted programming language that can be used to perform graphics 172 | or computation tasks, and can usually be compiled into a more efficient 173 | format for direct execution on GPUs.
174 |
175 | 176 |

177 | Deliverables 178 |

179 |

180 | Specifications 181 |

182 |
183 |
GPU for the Web Specification
184 | 185 |
An API as described above.
186 | 187 |
WebGPU Shading Language
188 | 189 |
A Shading Language specification that defines the programmable 190 | interface to the GPU for the Web graphics and computation 191 | pipeline, and that can be translated into the shading languages 192 | of the system APIs WebGPU is implemented upon.
193 |
194 |

195 | Non-Normative Reports 196 |

197 |

The group may produce a draft Charter for a GPU for the Web Working 198 | Group at W3C.

199 |

200 |

201 | The group may also produce other Community Group Reports within the scope of 202 | this charter but that are not Specifications, for instance use cases, 203 | requirements, or white papers. 204 |

205 |

206 | Tutorials 207 |

208 |

209 | The group may produce tutorial or explanatory content designed 210 | to help people learn the technical material. For example, an interactive 211 | tutorial could introduce the graphics pipeline or shader programming. 212 |

213 |

214 | Test Suites and Other Software 215 |

216 |

217 | The Community Group will develop a test suite that exercises the GPU for the Web API. 218 | Please see the GitHub LICENSE file for test suite contribution licensing 219 | information. 220 |

221 |

222 | The Community Group may develop a software library that implements the GPU for the 223 | Web work across multiple platforms using existing native APIs. For example, a 224 | C++ library that exposes GPU for the Web using Direct3D, Metal or Vulkan. Such software 225 | will be developed using the 227 | W3C Software and Document License. 228 |

229 |

230 | The Community Group may develop a continuous integration mechanism to validate the 231 | grammar of WebGPU Shading Language against syntactic ambiguities and potential 232 | mechanical issues with primary reliance on an open-source, commercially-permissive 233 | license tool that can report ambiguity and generate playgrounds that can run on the Web 234 | so that community can leverage and extend easily to enhance the ecosystem. Such software 235 | will be developed using the 237 | W3C Software and Document License. 238 |

239 |

240 | Community and Business Group Process 241 |

242 |

243 | The group operates under the Community and Business 245 | Group Process. Terms in this Charter that conflict with those of the 246 | Community and Business Group Process are void. 247 |

248 |

249 | As with other Community Groups, W3C seeks organizational licensing 250 | commitments under the W3C Community 252 | Contributor License Agreement (CLA). When people request to 253 | participate without representing their organization's legal interests, 254 | W3C will in general approve those requests for this group with the 255 | following understanding: W3C will seek and expect an organizational 256 | commitment under the CLA starting with the individual's first request to 257 | make a contribution to a group Deliverable. 258 | The section on Contribution Mechanics describes 259 | how W3C expects to monitor these contribution requests. 260 |

261 |

262 | Work Limited to Charter Scope 263 |

264 |

265 | The group will not publish Specifications on topics other than those 266 | listed under Specifications above. See 267 | below for how to modify the charter. 268 |

269 |

270 | Contribution Mechanics 271 |

272 |

273 | Substantive Contributions to Specifications can only be made by Community 274 | Group Participants who have agreed to the W3C Community 276 | Contributor License Agreement (CLA). 277 |

278 |

279 | Specifications created in the Community Group must use the 281 | W3C Software and Document License. All other documents produced by 282 | the group should use that License where possible. 283 |

284 |

285 | Community Group participants agree to make all contributions in the 286 | GitHub repository the group is using for the particular document. This may be 287 | in the form of a pull request (preferred), by raising an issue, or by 288 | adding a comment to an existing issue. 289 |

290 |

291 | All Github repositories attached to the Community Group must contain a 292 | copy of the CONTRIBUTING 294 | and LICENSE 296 | files. 297 |

298 |

299 | Transparency 300 |

301 |

302 | The group will conduct all of its technical work in public. All technical work 303 | will occur in the GitHub repositories 304 | (and not in mailing list discussions). This is to ensure contributions 305 | can be tracked through a software tool. 306 |

307 |

308 | Meetings may be restricted to Community Group participants, but a public 309 | summary or minutes must be posted to the group's public mailing list, or 310 | to a GitHub issue. 311 |

312 |

313 | Decision Process 314 |

315 |

316 | This group will seek to make decisions where there is consensus. Consensus 317 | will be assessed by one of: 318 |

319 | 323 |

324 | Where consensus is not 325 | clear there is a Call for Consensus [CfC] to allow multi-day online 326 | feedback for a proposed course of action. 327 |

328 |

329 | Participants can earn Committer status through a history of valuable 330 | contributions as is common in open source projects. After discussion and 331 | due consideration of different opinions, a decision should be publicly 332 | recorded (where GitHub is used as the resolution of an Issue). 333 |

334 |

335 | If substantial disagreement remains (e.g. the group is divided) and the 336 | group needs to decide an Issue in order to continue to make progress, the 337 | Committers will choose an alternative that had substantial support (with 338 | a vote of Committers if necessary). Individuals who disagree with the 339 | choice are strongly encouraged to take ownership of their objection by 340 | taking ownership of an alternative fork. This is explicitly allowed (and 341 | preferred to blocking progress) with a goal of letting implementation 342 | experience inform which specification is ultimately chosen by the group to move 343 | ahead with. 344 |

345 |

346 | Any decisions reached at any meeting are tentative and should be recorded 347 | in a GitHub Issue for groups that use GitHub and otherwise on the group's 348 | public mail list. Any group participant may object to a decision reached 349 | at an online or in-person meeting within 7 days of publication of the 350 | decision provided that they include clear technical reasons for their 351 | objection. The Chairs will facilitate discussion to try to resolve the 352 | objection according to the decision process. 353 |

354 |

355 | It is the Chairs' responsibility to ensure that the decision process is 356 | fair, respects the consensus of the CG, and does not unreasonably favour 357 | or discriminate against any group participant or their employer. 358 |

359 |

360 | Chair Selection 361 |

362 |

363 | Participants in this group choose their Chair(s) and can replace their 364 | Chair(s) at any time using whatever means they prefer. However, if 5 365 | Committers, no two from the same organisation, call for an election, 366 | the group must use the following process to replace any current Chair(s) 367 | with a new Chair, consulting the Community Development Lead on election 368 | operations (e.g., voting infrastructure and using RFC 2777). 370 |

371 |
    372 |
  1. Participants announce their candidacies. Participants have 14 days to 373 | announce their candidacies, but this period ends as soon as all 374 | participants have announced their intentions. If there is only one 375 | candidate, that person becomes the Chair. If there are two or more 376 | candidates, there is a vote. Otherwise, nothing changes. 377 |
  2. 378 |
  3. Participants vote. Participants have 21 days to vote for a single 379 | candidate, but this period ends as soon as all participants have voted. 380 | The individual who receives the most votes, no two from the same 381 | organisation, is elected chair. In case of a tie, RFC2777 is used to 382 | break the tie. An elected Chair may appoint co-Chairs. 383 |
  4. 384 |
385 |

386 | Participants dissatisfied with the outcome of an election may ask the 387 | Community Development Lead to intervene. The Community Development Lead, 388 | after evaluating the election, may take any action including no action. 389 |

390 |

391 | Initial Chair and Committers 392 |

393 |

394 | As of the date of this document, the initial co-Chairs for the Community 395 | Group are Dean Jackson (Apple) and Corentin Wallez (Google). 396 |

397 |

398 | The initial Committers are: 399 |

400 | 412 |

413 | Amendments to this Charter 414 |

415 |

416 | The group can decide to work on a proposed amended charter, editing the 417 | text using the Decision Process described above. 418 | The decision on whether to adopt the amended charter is made by 419 | conducting a 30-day vote on the proposed new charter. The new charter, if 420 | approved, takes effect on either the proposed date in the charter itself, 421 | or 7 days after the result of the election is announced, whichever is 422 | later. A new charter must receive 2/3 of the votes cast in the approval 423 | vote to pass. The group may make simple corrections to the charter such 424 | as deliverable dates by the simpler group decision process rather than 425 | this charter amendment process. The group will use the amendment process 426 | for any substantive changes to the goals, scope, deliverables, decision 427 | process or rules for amending the charter. 428 |

429 | 430 | 431 | 432 | -------------------------------------------------------------------------------- /wg-charter.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | GPU for the Web Working Group Charter 7 | 8 | 9 | 10 | 11 | 50 | 51 | 52 | 73 | 74 |
75 |

PROPOSED GPU for the Web Working Group Charter

76 | 77 |

Warning: This document has no official status. It is a draft charter for discussion within the GPU for the Web groups and the W3C Advisory Committee.

78 | 79 |

The mission of the GPU for the Web Working Group is to 81 | provide an interface between the Web Platform and modern 3D graphics and 82 | computation capabilities present on native system platforms.

83 | 84 | 87 | 88 |
89 | 90 | 91 | 94 | 97 | 98 | 99 | 102 | 105 | 106 | 107 | 110 | 113 | 114 | 115 | 116 | 119 | 123 | 124 | 125 | 128 | 131 | 132 | 133 | 136 | 142 | 143 |
92 | Charter Status 93 | 95 | See the group status page and detailed change history. 96 |
100 | Start date 101 | 103 | [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) 104 |
108 | End date 109 | 111 | [dd monthname yyyy] (Start date + 2 years) 112 |
117 | Chairs 118 | 120 | Kelsey Gilbert (Mozilla)
121 | Corentin Wallez (Google) 122 |
126 | Team Contacts 127 | 129 | François Daoust (0.05 FTE) 130 |
134 | Meeting Schedule 135 | 137 | Teleconferences: weekly or bi-weekly calls, as necessary. 138 |
139 | Face-to-face: 3 times per year as necessary, 140 | including during W3C's annual Technical Plenary week. 141 |
144 |
145 | 146 |
147 |

Motivation and Background

148 |

149 | In this document, the term GPU stands for Graphics Processing Unit, typically a piece of hardware dedicated to efficiently processing graphics and related features. 150 |

151 |

152 | GPUs have become essential for drawing complex images efficiently, including for rendering virtual reality and augmented reality scenes in real-time as needed by the WebXR Device API. GPUs are also at the heart of computations that leverage parallelism, such as machine learning inference. 153 |

154 |

155 | Web applications may leverage GPUs through the WebGL family of APIs, but WebGL does not enable access to more advanced features of GPUs, focuses on drawing images and does not provide first-class support for performing general computations, and is not agnostic of the GPU system API exposed by the underlying operating system. 156 |

157 |

158 | The overall goal of the GPU for the Web Working Group is to provide a foundation that can be implemented on top of modern GPU system APIs to expose modern GPU functionality on the Web, both for computation and for image rendering. 159 |

160 |

161 | See also the WebGPU Explainer, maintained by the GPU for the Web Community Group, for additional background, use cases, and design considerations. 162 |

163 |
164 | 165 |
166 |

Scope

167 |

168 | This Working Group will recommend a Web programming interface for 169 | graphics and computation that: 170 |

171 | 172 |
    173 |
  1. enables rendering of modern graphics to both onscreen and offscreen drawing surfaces
  2. 174 |
  3. enables computation tasks to be performed, and the results of such tasks to be retrieved
  4. 175 |
  5. This group will also recommend a companion Shading Language that describes the graphics and computation tasks in a format 176 | that can be translated or compiled into platform-specific instructions
  6. 177 |
178 | 179 |

180 | The API will not be restricted to any particular platform technology. Instead, it will 181 | be generic enough to be implemented on top of modern GPU system APIs, such as 182 | Microsoft's Direct3D 12, Apple's Metal, and Khronos's Vulkan. 183 |

184 | 185 |

186 | This Working Group will investigate and document threat mitigation 187 | strategies for the API, notably to address fingerprinting issues 188 | and to prevent unauthorized use of computational resources. 189 |

190 | 191 |

Out of Scope

192 |

193 | The scope of work is restricted to the development of a programming 194 | interface between the Web Platform and modern 3D graphics and 195 | computation capabilities present on native system platforms. The work 196 | will not define hardware features or algorithms, and the interface it 197 | defines is not intended to be directly exposed by a GPU driver. 198 |

199 | 200 |
201 | 202 | 203 | 204 |
205 |

206 | Deliverables 207 |

208 | 209 |

Updated document status is available on the group publication status page.

210 | 211 |

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to reach a stable state. The Working Group intends to publish the latest state of their work as Candidate Recommendation (with Snapshots) and does not intend to advance their documents to Recommendation.

212 | 213 |
214 |

215 | Normative Specifications 216 |

217 |
218 |
WebGPU API
219 | 220 |
221 | An API for performing operations, such as rendering and 222 | computation, on a Graphics Processing Unit (GPU). 223 |

Draft state: Working Draft

224 |

Adopted Draft: 31 August 2022

225 |

Exclusion Draft: WebGPU 18 May 2021; 226 |
associated Call for Exclusion on 2021-05-18 ended on 2021-10-15; 227 |
produced under Working Group charter: https://www.w3.org/2020/12/gpu-wg-charter.html

228 |

Expected completion: Q2 2025

229 |
230 | 231 |
WebGPU Shading Language
232 | 233 |
234 | A Shading Language specification that defines the programmable 235 | interface to the GPU for the Web graphics and computation 236 | pipeline, and that can be translated into the shading languages 237 | of the system APIs WebGPU is implemented upon. 238 |

Draft State: Working Draft

239 |

Adopted Draft: 31 August 2022

240 |

Exclusion Draft: WebGPU Shading Language 18 May 2021; 241 |
associated Call for Exclusion on 2021-05-18 ended on 2021-10-15; 242 |
produced under Working Group charter: https://www.w3.org/2020/12/gpu-wg-charter.html

243 |

Expected completion: Q2 2025

244 |
245 |
246 |
247 | 248 |
249 |

250 | Other Deliverables 251 |

252 |

253 | This Working Group will produce conformance test suites and 254 | implementation reports for its normative deliverables. 255 |

256 |

257 | Other non-normative documents may be created, including: 258 |

259 |
    260 |
  • Reference implementations of the group's deliverables
  • 261 |
  • Use case and requirement documents
  • 262 |
  • Explainers, primers and best-practice documents
  • 263 |
264 |
265 |
266 | 267 | 268 |
269 |

Success Criteria

270 |

There should be testing plans for each specification, starting from the earliest drafts. Normative specification changes are generally expected to have a corresponding set of tests, either in the form of new tests or modifications to existing tests, or must include the rationale for why test updates are not required for the proposed update.

271 |

Each specification should contain sections detailing all known security and privacy —including fingerprinting— implications, and suggested mitigation strategies for implementers, web authors, and end users. The group should not publish a specification if acceptable mitigation strategies cannot be found.

272 |

Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

273 |

This Working Group expects to follow the TAG Web Platform Design Principles.

274 |

All new features should have expressions of interest from at least two potential implementors before being incorporated in the specification.

275 |
276 | 277 | 278 |
279 |

Coordination

280 |

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

281 | 282 |

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

283 | 284 |
285 |

W3C Groups

286 |
287 |
GPU for the Web Community Group
288 |
The GPU for the Web Community Group developed the specifications adopted by this Working Group. It is expected that the Community Group will continue to work on test suites, tools, white papers and other non normative reports associated with the deliverables of this Working Group.
289 | 290 |
Immersive Web Working Group
291 |
The Immersive Web Working Group produces specifications to interact with Virtual Reality (VR) and Augmented Reality (AR) devices and sensors, and may add a 3D rendering layer based on the WebGPU API.
292 |
Web Applications Working Group
293 |
The Web Applications Working Group (WebApps WG) produces specifications that facilitate the development of client-side web applications.
294 | 295 |
Web Application Security Working Group
296 |
This Working Group develops security and policy mechanisms to improve the security of Web Applications, and enable secure cross-site communication.
297 | 298 |
Web Assembly Working Group
299 |
This Working Group develops a size- and load-time-efficient format and execution environment, allowing compilation to the web with consistent behavior across a variety of implementations.
300 | 301 |
Web Machine Learning Working Group
302 |
This Working Group develops a dedicated low-level Web API for enabling efficient machine learning inference in the browser.
303 |
304 |

External Organizations

305 |
306 |
Web Hypertext Application Technology Working Group (WHATWG)
307 |
The Web Hypertext Application Technology Working Group (WHATWG) is a community of people interested in evolving the web through standards and tests.
308 |
Khronos
309 |
The Khronos Organization is a standards body that develops many graphics-related technologies, including OpenGL, Vulkan and SPIR-V.
310 |
Unicode Technical Committee (UTC)
311 |
The Unicode Technical Committee is responsible for the development and maintenance of the Unicode Standard, including the Unicode Character Database. This Working Group will coordinate with the UTC where appropriate, notably with regards to supporting Unicode identifiers in the WebGPU Shading Language specification.
312 |
313 |
314 |
315 | 316 | 317 | 318 |
319 |

320 | Participation 321 |

322 |

323 | To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants. 324 |

325 |

326 | The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication. 327 |

328 |

329 | The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy. 330 |

331 |

332 | Participants in the group are required 333 | (by the W3C Process) 334 | to follow the W3C 335 | Code of Conduct. 336 |

337 |
338 | 339 | 340 | 341 |
342 |

343 | Communication 344 |

345 |

346 | Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however. 347 |

348 |

349 | Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the GPU for the Web Working Group home page. 350 |

351 |

352 | Most GPU for the Web Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis. 353 |

354 |

355 | This group primarily conducts its technical work in its public repositories. There is also a public mailing list public-gpu@w3.org (archive). The public is invited to contribute to the github repositories and post messages to the list. Regular activity summaries around the github repositories will be provided. 356 |

357 |

358 | The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion. 359 |

360 |
361 | 362 | 363 | 364 |
365 |

366 | Decision Policy 367 |

368 |

369 | This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

370 |

371 | However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections. 372 |

373 |

374 | To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. 375 | 376 | A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from 10 working days, depending on the chair's evaluation of the group consensus on the issue. 377 | 378 | If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group. 379 |

380 |

381 | All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs. 382 |

383 |

384 | This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote), and includes no voting procedures beyond what the Process Document requires. 385 |

386 |
387 | 388 | 389 | 390 |
391 |

392 | Patent Policy 393 |

394 |

395 | This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis. 396 | 397 | For more information about disclosure obligations for this group, please see the licensing information. 398 |

399 |
400 | 401 |
402 |

Licensing

403 |

This Working Group will use the W3C Software and Document license for all its deliverables.

404 |
405 | 406 |
407 |

408 | About this Charter 409 |

410 |

411 | This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. 412 |

413 | 414 |
415 |

416 | Charter History 417 |

418 | 419 |

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):

420 | 421 | 422 | 423 | 424 | 427 | 430 | 433 | 436 | 437 | 438 | 441 | 444 | 447 | 450 | 451 | 452 | 453 | 454 | 455 | 456 | 457 | 458 | 459 | 460 | 461 | 462 | 463 | 464 | 465 | 466 | 467 | 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | 477 | 478 | 479 | 485 | 486 | 487 | 488 | 489 | 490 | 497 | 498 | 499 |
425 | Charter Period 426 | 428 | Start Date 429 | 431 | End Date 432 | 434 | Changes 435 |
439 | Initial Charter 440 | 442 | 20 August 2020 443 | 445 | 31 August 2022 446 | 448 | Initial charter 449 |
Rechartered15 December 202031 August 2022New Patent Policy
New co-chair07 April 202131 August 2022Jeff Gilbert replaces Dean Jackson as co-chair
Co-chair update17 February 202231 August 2022Reflect change of firstname for Kelsey Gilbert
Charter Extension07 September 202230 November 2022None
Rechartered6 December 202230 November 2024
    480 |
  • Align text with charter template
  • 481 |
  • Refresh deliverables drafts info
  • 482 |
  • Replace Web Machine Learning Community Group with Working Group in coordination section
  • 483 |
  • Add Unicode Technical Committee to coordination section
  • 484 |
RecharteredWhen approved30 November 2026
    491 |
  • Align text with charter template, refresh links
  • 492 |
  • Add link to Conformance Test Suite
  • 493 |
  • Switch to CR with Snapshots (no intent to advance to Recommendation) mode
  • 494 |
  • Clarify that technical discussions on the deliverables are now driven by this Working Group
  • 495 |
  • Add a Motivation and Background section
  • 496 |
500 |
501 |
502 |
503 | 504 |
505 | 506 | 517 | 518 | 519 | 520 | --------------------------------------------------------------------------------