- From: Corentin Wallez <cwallez@google.com>
- Date: Thu, 18 May 2017 14:09:42 +0200
- To: public-gpu@w3.org
- Message-ID: <CAGdfWNOPxi9CUg-ejzYXP4VUbc8cRTnSM0u-fEoUAkRUPVC-Ww@mail.gmail.com>
Hey all,
Please find below the minutes for yesterday's kickoff meeting.
Cheers,
Corentin
Attendance
-
Jason Aftosmis (Apple)
-
Julien Chaintron (Apple)
-
Warren Moore (Apple)
-
Gareth Morgan (Axum Graphics)
-
Ken Russell (Google)
-
Kai Ninomiya (Google)
-
Zhenyao Mo (Google)
-
Corentin Wallez (Google)
-
Aleksandar Stojilijkovic (Intel)
-
Daniel Johnston (Intel)
-
Rafael Cintron (Microsoft)
-
Ben Constable (Microsoft)
-
Chas Boyd (Microsoft)
-
Jeff Gilbert (Mozilla)
-
Dzmitry Malyshau (Mozilla)
-
Daosheng Mu (Mozilla)
-
Doug Twilleager (ZSpace)
-
Joshua Groves
-
Tyler Larson
Administrative stuff, if any
Nothing, yay!
Quick contribution roundtable
-
Apple's WebGPU
<https://github.com/gpuweb/proposals/tree/master/WebGPU-Apple>
-
Recently added compute shaders and more examples
-
Shipped in the Safari technical preview
-
Mozilla's Obsidian
<https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla>
-
Starting from Vulkan moving towards other APIs as needed
-
Rationale is that it can take advantage of the existing spec etc.
-
Didn’t get to push an update yet.
-
Google's NXT <https://github.com/google/nxt-standalone>
-
Starting at barycenter of all APIs, trying to reach equilibrium faster
-
Have a document that covers most features
-
Working on bigger features recently. Have error notifications; Kai
working on render passes.
Discussion of goals and constraints
-
Portability
-
For this to be a successful web API it needs to work everywhere with
little effort
-
Metal, D3D12, Vulkan – maybe with feature levels / extensions
-
How reproducible should things be between different hardware, etc.?
-
This has been a point of contention
-
As more customers used WebGL, we tied up undefined behaviors in the
spec and this made it so more and more content was portable with no
additional effort. We should piggy-back on this.
-
Should minimize UB on everything but the perf critical paths.
-
Obsidian’s approach to UB is a bit more defined because it says you
get value you wrote before.
-
Ken: this is just one aspect of the UB
-
There are many aspects of the API that will have to be analyzed
-
Undefined behavior inside shaders is probably infeasible to eliminate
-
Think: lock-free algorithms with shader atomics
-
OpenGL: dithering not defined for example
-
One concern about the Vulkan API’s design: get a buffer, then get
memory requirements for a buffer, then place it in memory
-
Application has to conform to the behavior of the driver to avoid
undefined behavior
-
Jeff: this is an application bug.
-
Ken: impossible for all developers to test on a large enough range
of devices
-
For at least some of these situations, if the app developer isn’t
up to it, Jeff’s recommendation is to use WebGL 2.0
-
Jeff thinks it’s not as necessary to make this API foolproof as it
was to make WebGL 1.0 and 2.0 reproducible
-
Previous comment from Christophe from Unity: making a Vulkan backend
is easy, but making it work across all devices is hard
-
If we subsume some of the difficulty of porting, it’ll make it
easier for developers
-
D3D9 allowed you to have a texture bound for sampling and rendering;
sampled as black. Tightening up the undefined behavior made code more
portable.
-
Ben C.: there’s a difference between undefined behavior and
non-portability
-
Dzmitry: ok to remove UB cases in Obsidian point by point basis
-
Security
-
Web page should not be able to crash the OS or browser
-
Crashing a tab is “okay-ish”
-
Should not be able to access data it’s not allowed to
-
In particular, uninitialized VRAM and cross-domain data
-
Different levels:
-
DoS, like device reset.
-
Information disclosure, including outside of process
-
WebGL 1.0 and 2.0: can TDR and/or hang the machine
-
Have to be careful about setting goals beyond what we’re achieving
now with other platforms
-
Mozilla: getting information across boundaries is a high severity
vulnerability; but crashing the browser is only security level “DoS”
-
It would for example be possible to cause the whole browser to fall
back to software rasterization, causing a perf penalty to other pages.
-
The Vulkan WG has talked about robustness with a watchdog in the
driver like on Windows
-
Not sure how robustness works on Apple.
-
Some work was done on both macOS and iOS to make the drivers
handle GPU resets more gracefully
-
Microsoft has been working with vendors to make preemption more
granular.
-
Some UB/Repro behavior has led to security issues in the past.
-
Undefined behavior / Reproducibility
-
Obsidian is a little more free-wheeling about undefined behavior and
values
-
Require they are safe
-
If they are undefined, but sources of your previous renderings,
treated as OK
-
Better for the API if we reduce the number of such undefined
behaviors
-
Clarification: not saying all UB is fine, but ok to give driver
choice in implementation and UB is ok if it comes from
previous resources
the page owned.
-
Could we have a principle that any reproducibility / undefined
behavior that’s found to be a security issue on one platform, be
treated as
a security issue from then on?
-
Don’t think we have to automatically say that if there’s one
driver that handles undefined values badly, it should be a
security issue
forever
-
Treat it on a case-by-case basis
-
Performance
-
Fast is good
-
80% of native at least
-
WebAssembly first class
-
Agreement that it is
-
Some multithreaded API usage support is essential, that’s one of the
main selling points of D3D12 and Vulkan
-
Web workers?
-
NXT’s objects are mutable only until constructed, which makes things
easier
-
May be possible to construct command buffers on web workers and
transfer and enqueue them on another thread
-
Resource deallocation becomes tricky
-
Command buffer writing is fairly straightforward to validate
-
BeginCommandBuffer – requires synchronization
-
Then all other threads are locked out
-
Metal has ParallelRenderEncoder
-
Dzmitry: It sounds like ParallelRenderEncoders all encode to the
same encoder but what we want is parallel encoding to
different encoders
-
Will need to investigate
-
Ease of porting
-
One of the big challenges is how to port content
-
Should provide an easy path for applications to target the new API
without too much work (like a full new backend)
-
Jeff: talked to partners that want to minimize number of backend. A
translation layer from one of the explicit APIs to the Web API would make
them happy.
-
It is ok if the translation is not perfect perf-wise and
compatibility-wise
-
Offering a wrapper to an existing native API is strongly desired
-
Microsoft agrees. Nice to have, not a requirement
-
Network-transparency / Serializability
-
API is basically serializable. Important for Chrome at least since
app lives in separate process from GPU.
-
Firefox and Edge are looking at offloading some graphics work to
other threads/processes.
-
There are types of API designs that would be really inefficient in
Chrome
-
Vulkan’s quite a chatty API, for example
-
Every call returns a boolean status “did it succeed” – would be
quite expensive
-
OpenGL’s design is that errors are async, they can defer the checking
and that’s what make WebGL reasonably efficient.
-
Jeff agrees that there are some things in the API that shouldn’t
require a round trip
-
But going fully asynchronous and telling people to always expect 1
ms or more of latency for every synchronous call is not workable
-
Content/shape-wise discussion
-
Would be good to separately discuss:
-
Features of the API
-
Syntax of the API
Setup regular meetings
-
Weekly sounds good to Mozilla and Microsoft
-
Would like to include Dean. 11 AM Pacific is 5 AM Australian time
-
Afternoons Pacific time?
Received on Thursday, 18 May 2017 12:10:40 UTC