-
Notifications
You must be signed in to change notification settings - Fork 12
/
cg-charter.html
431 lines (410 loc) · 17.5 KB
/
cg-charter.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
<!DOCTYPE html>
<html lang="en">
<head>
<title>
GPU for the Web Community Group Charter
</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/base">
<style>
body {
max-width: 60em;
margin: auto;
}
*:target {
background-color: yellow;
}
li {
margin-bottom: 9pt;
}
.note {
background-color: yellow;
padding: 10px;
}
.remove {
background-color: yellow;
}
</style>
</head>
<body>
<h1>
[DRAFT] GPU for the Web Community Group Charter
</h1>
<p>
This Charter is work in progress. To submit feedback,
please use <a href="https://github.com/gpuweb/admin/issues">GPU for the Web Github</a> Issues
where this charter is being developed.
</p>
<ul>
<li>This Charter: 2017-03-29
</li>
<li>Start Date: TODO
</li>
<li>Last Modified: TODO
</li>
</ul>
<h2 id="goals">
Goals
</h2>
<p>
The mission of the <a href="https://www.w3.org/community/gpu/">GPU for
the Web Community Group</a> is to provide an interface between the Web
Platform and modern 3D graphics and computation capabilities present on
native system platforms.
</p>
<p>
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:
</p>
<ul>
<li>An API that maps nicely to modern Web platform design patterns;</li>
<li>A lower-level API that allows greater performance in applications;</li>
<li>An API that exposes the GPU computation functionality provided by more
modern APIs and available on many devices;
</li>
<li>A technology that can be reasonably implemented on all platforms
that have a modern, low-level graphics API;
</li>
<li>An API designed to provide a efficient bindings for both JavaScript and
<a href="https://github.com/WebAssembly">WebAssembly</a>, possibly
requiring separate interfaces for each.
</li>
</ul>
<p>
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 <a
href="https://www.w3.org/community/about/agreements/final/"> Final
Specification Agreement</a>.
</p>
<h2 id="scope-of-work">
Scope of Work
</h2>
<p>
This Community Group will recommend a Web programming interface for
graphics and computation that:
</p>
<ol>
<li>enables rendering of modern graphics to both onscreen and offscreen drawing surfaces</li>
<li>enables computation tasks to be performed, and the results of such tasks to be retrieved</li>
<li>This group will also recommend a companion Shading Language that describes the graphics and
computation tasks in a format
that can be translated or compiled into platform-specific instructions</li>
</ol>
<p>
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.
</p>
<h3 id="target-audience">Target Audiences</h3>
<p>
The <a href="#deliverables">deliverables</a> of this Community Group are
primarily addressed, either directly or indirectly, to the following audiences:
</p>
<ul>
<li>
Developers of 3D and game engines/tools that are producing Web
content via transpilation. For example, <a
href="https://unity3d.com/">Unity</a> and the <a
href="https://www.unrealengine.com">Unreal Engine</a> use <a
href="https://en.wikipedia.org/wiki/Emscripten">emscripten</a> to
compile content for the Web.
</li>
<li>
JavaScript framework developers who are building GPU libraries,
intended to be used in Web content, but providing a higher-level
API and hiding much of the low-level graphics and compute details
from their users. For example, <a
href="https://threejs.org">three.js</a>.
</li>
<li>
Web developers who are competent in GPU technologies, and will want to
use the GPU for the Web API directly to create content, rather than
a higher-level framework.
</li>
</ul>
<p>
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 <a href="#deliverables">Community Group's non-normative deliverables</a>
are addressed to them.
</p>
<h3 id="out-of-scope">Out of Scope</h3>
<p>
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.
</p>
<h3 id="defnitions">
Definitions
</h3>
<dl>
<dt>GPU</dt>
<dd>Graphics Processing Unit. Typically a piece of hardware dedicated to
efficiently processing graphics and related features.</dd>
<dt>Shading Language</dt>
<dd>A restricted programming language that can be used to perform graphics
or computation tasks, and can usually be compiled into a more efficient
format for direct execution on GPUs.</dd>
</dl>
<h2 id="deliverables">
Deliverables
</h2>
<h3 id="specifications">
Specifications
</h3>
<dl>
<dt>GPU for the Web Specification</dt>
<dd>An API as described above.</dd>
<dt>WebGPU Shading Language</dt>
<dd>A Shading Language specification that defines the programmable
interface to the GPU for the Web graphics and computation
pipeline, and that can be translated into the shading languages
of the system APIs WebGPU is implemented upon.</dd>
</dl>
<h3 id="non-normative-reports">
Non-Normative Reports
</h3>
<p>The group may produce a draft Charter for a GPU for the Web Working
Group at W3C.</p>
</p>
<p>
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.
</p>
<h3 id="tutorials">
Tutorials
</h3>
<p>
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.
</p>
<h3 id="test-suites">
Test Suites and Other Software
</h3>
<p>
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.
</p>
<p>
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 <a href=
"http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document">
W3C Software and Document License</a>.
</p>
<p>
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 <a href=
"http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document">
W3C Software and Document License</a>.
</p>
<h2 id="process">
Community and Business Group Process
</h2>
<p>
The group operates under the <a href=
"https://www.w3.org/community/about/agreements/">Community and Business
Group Process</a>. Terms in this Charter that conflict with those of the
Community and Business Group Process are void.
</p>
<p>
As with other Community Groups, W3C seeks organizational licensing
commitments under the <a href=
'http://www.w3.org/community/about/agreements/cla/'>W3C Community
Contributor License Agreement (CLA)</a>. 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 <a href="#deliverables">Deliverable</a>.
The section on <a href="#contrib">Contribution Mechanics</a> describes
how W3C expects to monitor these contribution requests.
</p>
<h2 id="worklimit">
Work Limited to Charter Scope
</h2>
<p>
The group will not publish Specifications on topics other than those
listed under <a href="#specifications">Specifications</a> above. See
below for <a href="#charter-change">how to modify the charter</a>.
</p>
<h2 id="contrib">
Contribution Mechanics
</h2>
<p>
Substantive Contributions to Specifications can only be made by Community
Group Participants who have agreed to the <a href=
"http://www.w3.org/community/about/agreements/cla/">W3C Community
Contributor License Agreement (CLA)</a>.
</p>
<p>
Specifications created in the Community Group must use the <a href=
"http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document">
W3C Software and Document License</a>. All other documents produced by
the group should use that License where possible.
</p>
<p>
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.
</p>
<p id="githublicense">
All Github repositories attached to the Community Group must contain a
copy of the <a href=
"https://github.com/w3c/licenses/blob/master/CG-CONTRIBUTING.md">CONTRIBUTING</a>
and <a href=
"https://github.com/w3c/licenses/blob/master/CG-LICENSE.md">LICENSE</a>
files.
</p>
<h2 id="transparency">
Transparency
</h2>
<p>
The group will conduct all of its technical work in public. All technical work
will occur in the <a href="https://github.com/gpuweb/">GitHub repositories</a>
(and not in mailing list discussions). This is to ensure contributions
can be tracked through a software tool.
</p>
<p>
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.
</p>
<h2 id="decision">
Decision Process
</h2>
<p>
This group will seek to make decisions where there is consensus. Consensus
will be assessed by one of:
</p>
<ul>
<li>Participants who have earned Committer status for a history of useful contributions</li>
<li>The Chair</li>
</ul>
<p>
Where consensus is not
clear there is a Call for Consensus [CfC] to allow multi-day online
feedback for a proposed course of action.
</p>
<p>
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).
</p>
<p>
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.
</p>
<p>
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 <a href="#decision">decision process</a>.
</p>
<p>
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.
</p>
<h2 id="chairs">
Chair Selection
</h2>
<p>
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 <a href=
"https://tools.ietf.org/html/rfc2777">RFC 2777</a>).
</p>
<ol>
<li>Participants announce their candidacies. Participants have 14 days to
announce their candidacies, but this period ends as soon as all
participants have announced their intentions. If there is only one
candidate, that person becomes the Chair. If there are two or more
candidates, there is a vote. Otherwise, nothing changes.
</li>
<li>Participants vote. Participants have 21 days to vote for a single
candidate, but this period ends as soon as all participants have voted.
The individual who receives the most votes, no two from the same
organisation, is elected chair. In case of a tie, RFC2777 is used to
break the tie. An elected Chair may appoint co-Chairs.
</li>
</ol>
<p>
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.
</p>
<h2 id="initial-members">
Initial Chair and Committers
</h2>
<p>
As of the date of this document, the initial co-Chairs for the Community
Group are Dean Jackson (Apple) and Corentin Wallez (Google).
</p>
<p>
The initial Committers are:
</p>
<ul>
<li>Corentin Wallez (Google)</li>
<li>Dean Jackson (Apple)</li>
<li>Dzmitry Malyshau (Mozilla)</li>
<li>Jeff Gilbert (Mozilla)</li>
<li>Jon Lee (Apple)</li>
<li>Kai Ninomiya (Google)</li>
<li>Ken Russell (Google)</li>
<li>Milan Sreckovic (Mozilla)</li>
<li>Myles Maxfield (Apple)</li>
<li>Theresa O'Connor (Apple)</li>
</ul>
<h2 id="charter-change">
Amendments to this Charter
</h2>
<p>
The group can decide to work on a proposed amended charter, editing the
text using the <a href="#decision">Decision Process</a> 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.
</p>
</body>
</html>