gpuweb / admin Goto Github PK

The CG charter seems to be no longer available at https://gpuweb.github.io/admin/cg-charter.html

@grorg @Kangz, I suspect that publication of the repo as GitHub Pages is no longer active, possibly since the repo was switched to main?

In #8, the CG charter ( https://gpuweb.github.io/admin/cg-charter.html ) was updated to avoid being overly restrictive, and the development of an ANGLE-like library was added as a possibility to the section "Test Suites and Other Software".

I am not a lawyer and do not know the consequences of the W3C Software and Document License ( https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document ) as it relates to the "Out of Scope" section.

Could you please add a follow-on paragraph or couple of sentences to the "Test Suites and Other Software" section clarifying any implicit or explicit restrictions on usage of this library?

Thank you.

Currently, applications using OpenGL that are compiled for the Web have to go through emscriptem's OpenGL ES to WebGL shim layer that adds some overhead in addition to the overhead of going through Javascript for every call. For example emscriptem has to emulate the bind-to-create behavior of OpenGL and probably does a map lookup everytime an OpenGL id is used.

In WebGL the shim overhead might be lost in the CPU overhead of WebGL itself, but with a faster API it will become more apparent. WebAssembly is a huge use case for the API, if only for porting game engines to the Web. We should strive to make the emscriptem shim as small as possible.

How about making WebAssembly a first-class target language in the "Goals" section, for example with this wording?

Interoperates well with web runtimes for multiple languages, such as WebAssembly.

The charter mentions "3D on the Web" multiple times, it should be updated to be "GPU on the Web" instead.

I realize that businesses have priorities and needs; but in my opinion the draft charter guards Apple Inc.'s business priorities above the excellence of the standard.

Specifically this passage:

A technology that does not follow a single native API, which reduces the difficulty of implementation on platforms that do not support the chosen native API.

Reads, to me, as:
"A technology that does not follow a single native API," -> A technology which forsakes Vulkan,
"which reduces the difficulty of implementation" -> to support
"platforms that do not support the chosen API" -> Apple Inc.'s lack of interest in implementing Vulkan.

I don't mean to be overly critical, but I don't think technical compromises are a healthy start to a community; and I can almost guarantee that having no standard native API will make the work of every independent implementation much harder. Considering the shading language alone, this is the difference between shipping SPIR-V, and defining yet another abstract shading IR or language, four or more separate implementations of it, a whole new set of codegen tools, and more performance overhead. That's a lot to commit to in one sentence.

If an organisation provides a test suite it should also provide a result with timings showing at what rate and in what order the tests were executed.

This would allow other participants to repeat the test suite in the way the designer organisation planned it to be.

Hi Chairs and editors,
As the Immersive web working group, we think it might be useful for us to meet face to face/online as part of TPAC. We are currently scheduling our meetings for below dates. If you are interested, please let us know if any of the dates below or another time would work for you.

Current time slots for planned meetings:
7-10pm UTC on Monday 2nd of November,
4-8pm on Tuesday 3rd of November
4-8pm on Wednesday 4th of November
6-10pm on Thursday 5th of November
6-10pm on Friday 5th of November

Thank you!

Immersive-web chairs

In #18 (comment), @alan-baker said:

A possible addition might be similar to the API side we make an explicit point about representability in the shading languages of modern APIs. This currently could be read as WGSL will be compiled directly to machine code, but I might be trying to view it too naively for the purpose of reviewing.

(copied from #19)

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.

Wouldn't this prevent the CG from working on the test-suite or the ANGLE-like library?

It will not define an implementation of a graphics and computation system.

Applied to a specification, this sentence makes it sound like we will not be able to specify how things like rasterization and the memory model work, and will force us to link to other specification that do. The only other public specifications I know that specify basic graphic operations are the OpenGL and the Vulkan specification.

Instead, we could make it explicit that the output of this working group should not be used to guide the implementation of hardware features. (but allows a software implementation like Swiftshader)

The interface is not intended for use in native system platforms or in GPU libraries.

It is unclear what this applies to, for example the ANGLE-like library is a "GPU library" but should be possible to use during application development. Likewise I hope the CG will be able to do extension request to native APIs to make backends more efficient. In particular I'm thinking about a Vulkan extension that would make descriptor pools less restrictive on having to define the maximum number of each descriptor type at pool creation. Extension requests are not the "interface" but contributions nonetheless.

Again what we don't want is a GPU driver implementing the API on top of the hardware directly so we should restrict the restriction ;-)

First off, something on the status-quo as I perceive it. My major gripe with WebGL is its horribly slow adoption rate and the fact that WebGL2 will be outdated as soon as it is ratified compared to GLES3.2 and OpenGL 4.5 certainly does not help. I currently find myself implementing an OpenGL 4.5/GLES2 based rendering framework for a special purpose (so Unity and Unreal are currently intentionally out of the picture). While being able to (de-facto) seemlessly transpile the GLES codepath to WebGL, it is very disconcerting having to drop all the goodness we have come to expect from OpenGL 4.5 (including but not limited to the AZDO paradigm). I imagine Unity and Unreal developers feel the same way. Frankly, as a developer mainly dabbling in stuff on the desktop, it is beyond me why exposing desktop OpenGL in a browser and on mobile devices should not be possible today - current hardware certainly should not pose much of a problem (please correct me if I'm wrong there).

Despite that major problem, having a single code base, for instance in C++, which can be compiled for different targets like x86_64 and ARM and (at this time) transpiled to JavaScript is pretty sweet. As a developer working primarily on and for the desktop, I'd like to be able to reuse my C++ code wherever possible. IIUC, the formalization of WebAssembly and the possibility to let your compiler spit out the IR will only make this more convenient - which is also a major step in the right direction. Even though my knowledge of the Web as a platform is limited, step-by-step elimination of hurdles for multi-platform deployment and consistent user experience is what I consider one of the most important mid- or long-term goals.

This also applies to the WebGPU proposal. For example, I'd like to be able to write something on the desktop and deploy it on all relevant platforms - ideally using the same set of features. Having a close or even one-to-one API correspondence currently enables me to do that when I limit myself to GLES2 and WebGL. I urge you to keep that in mind when specifying a WebGPU API - I don't care how this is achieved, but I desperately want it and I think we all need it. Ideally, I imagine a unified approach to all platforms which currently can be (at least to a degree) achieved with the help of Emscripten and frameworks like electron.

This immediately impacts certain choices currently made for the proposal which I find highly debatable, including the choice of shading language. Being forced to deploy shaders written in two different languages unnecessarily increases complexity. Also, why would you demand that developers learn a fringe shading language and why would you define another IR for something that is already in place with e.g. SPIR-V? I can see some of the benefits of the Metal SL (like being able to modularize properly without having to employ a de-factor VFS with GL_ARB_shading_language_include). I also understand that for something that comes out of Apple, it makes sense to advertise in-house technology, but I think we all might be better off if you just turn to your fellow Khronos members and handle this business with all members of the industry participating. Just improve GLSL or define something new as a concerted industry effort (unless you want the Metal SL to be just that, in which case I want you to provide a SPIR-V compiler).

Something on which I'd like to have some clarification is the fact that OpenGL and Vulkan, while usable to achieve the same observable result, they are very different APIs which both exist in their own right. I can see a ton of scenarios where implementing a Vulkan renderer is not necessary. On the other hand, OpenGL carries some historically based design flaws which can be properly handled with Vulkan (e.g. multi-threaded command buffer submission) and, by design and due to resulting implementations, is (supposedly) not able to outmatch Vulkan in regards to performance.

While the WebGPU proposal addresses the necessity to expose something akin to Vulkan in the browser, this does not solve any problems for people wanting to use the latest GPU features through OpenGL - unless someone comes up with an implementation of OpenGL atop WebGPU. I don't want to be forced to use either technology - I want to be enabled to choose the API according to necessity. Do you think this is possible and something to strive for?

One of the big successes of WebGL is that it made it much easier to teach computer graphics as all you really need to get started is a browser and a text-editor. On the contrary D3D12 and Vulkan give developers a lot of control, but are for experts only.

With the new API, there is an opportunity to improve on the teachability of WebGL as we move away from the idiosyncrasy of WebGL. Maybe we could add it to the goals, at least the stretch ones.

Hello!

As far as I could find, there isn't a logo or mark for WebGPU.
We've gotten a request for one from someone who most likely wants to mention WebGPU in a talk.
Logos or Marks are useful for other things.

Has the group thought about creating one?
If you take free advice (<insert grinning emoji>), please consider using the W3C Blue! (#005A9C)

In addition to a test suite, an other extremely valuable software artifact that the CG could produce is a ANGLE-like library implementing the translation of the API to the native APIs. This would allow most of the work to be shared between browser vendors, with only the integration of the library with the JS bindings being specific to each browser. For example in Chromium's prototype only a fraction of the code is backend specific, see this slide.

Another nice advantage of such a library would be that during development, applications could test in native before getting compiled for the Web, making the development workflow much easier.

One of the major improvements of explicit graphics APIs over older ones is that all of them support some sort of concurrency, at least in the recording of command lists / command buffers / encoders. Exposing the same sort of capabilities to the Web would be very beneficial too, so maybe we could add it to the top-level goals, or at least mention it as a stretch goal.