Minutes for the 2017-01-10 meeting

*GPU Web 2018-01-10Chair: CorentinScribe: KenLocation: Google
HangoutMinutes from last meeting
<https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTWaNnuaahtA0VBIvHdA5c>TL;DR
- Specter/Meltdown does it affect Web GPU APIs?- GPU APIs are less at risk
because by nature GPUs go wide in shader instances and not deep with
speculative execution.- Should 1) ensure that GPU drivers are as safe as
possible 2) watch what responses are on the CPU side- Shading languages
Google’s position document <https://github.com/gpuweb/gpuweb/issues/44>-
Consensus to take ownership of the high-level language and pipeline to
bytecode (if needed).- Concern that ingesting SPIR-V is not easier than
ingesting HLSL- Action item to detail in an email- Concern that this
position doesn’t address online compilation well. There would be a blessed
“JS/WASM” HLSL->SPIRV compiler, why not ship it in the browser?- Would have
inconsistent versions between browsers- Consensus to try to go with SPIR-V
at the API level and the HLSL->SPIR-V compiler inside or outside the
browser. Discuss more when we have more experience.Tentative agenda -
Specter/Meltdown interactions- Shading languages- Agenda for next
meetingAttendance - Apple- Dean Jackson- Myles C. Maxfield- Google -
Corentin Wallez- David Neto- James Darpinian- John Kessenich- Kai Ninomiya-
Ken Russell- Microsoft- Ben Constable- Chas Boyd- Rafael Cintron- Mozilla-
Dzmitry Malyshau- Jeff Gilbert- Markus Siglreithmaier- Yandex- Kirill
DmitrenkoRecap of status update - Google: - started prototyping inside
Unreal Engine to see how NXT might work- More work on Vulkan backend- put
together proposal for SPIR-V- No updates from Apple or Microsoft-
Microsoft:- Reviewing official position papersSpectre/Meltdown interactions
- MM: no specific agenda; what do people think about these topics?- Big
security problems that have to do with speculative execution and caching-
GPUs have timing facilities, memory and caches- Concern that some of these
attacks can be launched via GPUs- Many different general pieces- This type
of attack requires high-fidelity timing. Many ways of getting it. One way
is explicitly; scheduling performance queries. Another way is with UAVs.-
Say you draw a triangle that covers two pixels. One of the fragment shader
invocations could write a 1, 2, … into the UAV. Other pixel could read that
value from the UAV and use it to construct a high-res timer, then launch
the attack.- Don’t want to disable UAVs because that would prevent a host
of algorithms from running on this API.- So what’s the right solution? Any
thoughts about this?- CW: UAVs allow counting time in a way like
SharedArrayBuffers do. This is why SABs were disabled in browsers. However
this disabling was temporary. Just disabling them while shielding browsers
against these attacks.- Feels that in a way we might not have a problem
with high-res timing. Need to shield against stuff that might use it.-
Attacks use speculative execution. Think GPUs might not be doing this (at
least as much).- But, WebGL’s thought about this in the context of DRM
content.- JG: usage of resources you don’t have privilege to read back in
WebGL – can think of it like speculative execution – executing with inputs
you might not have access to read from.- Original defense was: disable
readback from screen.- Was demonstrated via timing attacks that it’s
possible to deduce the contents of GPU resources that were accessible to
WebGL. This is why WebGL forbids access to cross-origin resources.- CW:
should try to see if, on GPUs right now, there’s a way to do speculative
execution.- Probably want to spend fewer resources on making a single
instance go faster and more resources on width.- MM: Brought up this topic
because specs last longer then HW.- Would be tricky if we couldn’t run
webgpu on future devices because of the structure of this API.- BC: problem
you’re talking about in the non-web context of these APIs. Probably will be
work done in these spheres that we can lean on.- Like Windows just patched
the CPU side, if MSFT finds a security issue, future HW will probably take
it into account.- KR: We had internal discussion, NVIDIA published a new
driver that’s supposed to guard against one of these attacks by better
isolating stuff with the GPU MMU. There was concern about GPUs and UMA
architectures but it was pointed that this architecture are dumber than
CPUs and only allocate one page ahead. One these architecture there could
be guard pages. Not trying to paper over the issues, but it seems GPU APIs
are less at risk than others.- JG: one major difference with the more
vulnerable APIs: we aren’t actually letting people run whatever code they
want. If we want it to be vulnerable to speculative execution then we’d
have to allow speculative execution in the API.- KR: The PoC Javascript
code is running in a VM that does a bounds check upfront. The pb is that
the CPU is running over the bounds check with speculative execution. GPU
pipelines are built for width and not depth so seems likely to be hit.
Potentially severe problem on GPUs too? Especially with compute shaders.
Need to make sure at the driver, browser and API level we don’t allow for
risky behavior.- CW: we think GPU APIs are slightly less at risk because of
the nature of GPUs. But we should ensure (1) the GPU folks’ drivers be
safer if they can be and (2) we should see what CPUs and browsers do in
response to these attacks.- MM: mainly bringing this up as something we
have to think about in the future.Shading languagesGoogle’s position
document <https://github.com/gpuweb/gpuweb/issues/44> - CW: made a document
with why we think the API should ingest SPIR-V.- Something we didn’t make
clear: we still think it’s useful for the group to spec HLSL, or at least
for the group to take ownership of the high-level to low-level pipeline
(including the test suite), given that the API would ingest the low level.-
We think we get the best of both worlds this way.- Want to solicit feedback
in particular from Myles.- MM:- Apple thinks this is a good step in the
right direction.- Glad Google has officially stated idea of blessing HLSL
and taking ownership of *a* language.- Have some concerns about expecting
every web site in the world to use the compiler we ask them to use.- CW:
goal with the proposal: there’s an easy path with the compilers this group
provides. But emphatically not intending to force everyone to use this
compiler.- Leads us to a tricky situation: we now have gone from one API to
three, if we’re expecting many people to make compilers. API of source
language, API the compiler will emit, and the API the browser will accept.
This makes the fragmentation problem worse, not better.- Think this doesn’t
help with having one shader source run the same everywhere.- JG: ingesting
SPIR-V means we have to take this in at the API level. Emitting SPIR-V from
HLSL compiler means investing in that environment. (..)- JK: not running up
against the portability issues of frontend compiler.- BC: statement from JK
if you’re talking about offline compilation. Questions about online
compilation. The source language ingestion becomes relevant.- KN:
regardless of online or offline compiler, you’re running the same compiler
and it runs deterministically.- JG: might be multiple HLSL compilers.- KN:
idea is that you’d ship it- JG: ship it alongside the browser, possibly
inside the browser- CW: just to clarify, Google is not proposing to ship
the HLSL compiler in the browser- MM: generally feel online compilation is
needed by many frameworks and we should solve it.- JG: you can do that with
SPIR-V. SPIR-V is concatenatable.- BC: Cesium for example wants to do
online compilation. Proposal as it stands, Cesium would bring in a JS
version of an HLSL compiler, and that compiler would be available from the
WebGPU WG, and then generate SPIR-V and put it into the API.- JG:
counter-proposal is that you can use SPIR-V to snip together snippets.- MM:
section 2.4 of SPIR-V defines ordering of various SPIR-V sections.- Type
identifiers in one module won’t match those in another.- Don’t agree with
the statement that they’re concatenatable.- JK: people have written tools
to merge together SPIR-V modules. It’s simple.- CW: point with Cesium: they
have an existing code base and it would be hard to redo by merging SPIR-V
modules- KN: really don’t think Cesium would switch from GLSL to HLSL to
switch which compiler they use. If they switch languages they probably
would be able to switch to an offline compilation model. Existing content
in GLSL (or HLSL): for that use case they would use a GLSL -> SPIR-V
compiler.- BC: looking at Cesium as a pattern of development is more useful
than as a specific customer. Porting from ES 3.0/ D3D11 API to D3D12 API is
non-trivial exercise.- DJ: agree. Early on we said we want to ingest source
language.- KN: don’t think it’s acceptable to force all existing WebGL
frameworks to rewrite in HLSL or something else.- DJ: that’s not what I
said. Apple would like the requirement to do online compilation from a
source language.- CW: online compilation from a source language: Google’s
suggestion is that there is a blessed WebAssembly / JS thing that “just
works”.- DJ: that’s awesome. I then ask the question: why don’t we just
include it in the browser? Wouldn’t have to do as much validation on the
SPIR-V output of it. The compiler won’t be huge, we’re saying that pages
can include it.- JD: there will be different versions, different bugs.
Compatibility issues with different browsers.- DJ: we’re improving the
compiler as we move it forward.- KN: if the app ships a buggy version of
the compiler they can upgrade it when they want.- Moving a bug from the
browser to the application means that they can fix it *if they want/need
to*.- Otherwise applications can more easily break when they switch
browsers, operating systems, etc.- SPIR-V interface is much smaller than an
HLSL interface. It’s much easier to make sure we get that interaction
correct.- DJ: this is another point we disagree with.- CB: Could be that
for typical application that we’ve been talking about right now produces
simple SPIR-V- Perhaps consuming “secure” SPIR-V at the high level will
make it easier to validate- DJ: our experience with JavaScript,
WebAssembly, image formats, binary formats on the web have shown the
opposite. And Java proper.- JG: have you investigated writing a SPIR-V
validator? It’s a month project max.- CB: looking at it.- MM: that’s our
fundamental disagreement. Writing the SPIR-V validator and any sort of
enforcement checks will be difficult enough that we disagree it’s faster or
easier.- RC: what about SPIR-V is difficult? SPIR-V specifically? Binary
vs. text? something else?- MM: one example: SPIR-V uses numeric identifiers
for every operation. Every operation has to look up these identifiers
inside the table, and need bounds checks. If you had an AST inside a text
language you would just do the lookup.- JK: hard to believe that numbers
are harder to deal with than names.- JG: wrote an assembler for this and
just treat the numbers like abstract names. Use them for hash lookups.- CW:
trying to understand why Apple thinks SPIR-V might not be easier to parse
than the high level language.- CB: easier to track the security issues
during parsing when dealing with the high-level language.- DJ: could we
write this up and send it as an email?- CW: OK- DJ: vague suggestion: we’ve
discussed this a lot and are consuming a lot of time. One way forward is to
basically press pause and allow implementations to do one or the other or
both. Get some implementation experience and developer feedback. Think
we’re a fair way away from consensus. Think we’re far - KR: Encourage to
look at the curated list of ANGLE compiler bugs. The bugs we encountered
over the years aren’t because our code is crap, it is because of inherent
properties of text languages. It is because we are using identifiers and
text language for GLSL. SPIR-V eliminates all of these, the validation
occurs at the low-level. If we include a compiler it will still make sense
to say that the compiler will lower to SPIR-V and then validate that.
Preprocessing in the browser is a disaster and we shouldn’t make the same
mistake.- DJ: OK. I don’t think it changes my argument much. There were a
lot of bugs dealing with GLSL. Don’t know whether you disagree- BC: maybe
modifying what Ken said: if we can have an agreement that a high level
language is needed for certain scenarios, and an intermediate language is
useful for a certain set of things, maybe disagreement is where the code
lives. If we can agree on what the high level language is that the group
focuses on, and we can agree on an IL, then maybe we can reduce the
discussion to “where does the HLSL -> IL compiler” go.- KN: agree that
that’s one of the issues but think Apple’s disagreeing on a separate issue-
BC: want to focus on where we have agreement. If we all agree that the
lingua franca of WebGPU is a variant of HLSL and there is an API on the
surface that takes SPIR-V then we can at least have a situation where
implementations have the same API surface and take in the same source code.
Can vary where different pieces live and where they operate. If we could
all agree on this as a framework it would unlock a development.- DJ: think
that this is a good suggestion- CW: agreeing (1) HLSL is the high-level
language and we will shepherd it forward (2) the API will ingest SPIR-V (3)
where the HLSL->SPIR-V compiler lives is still up in the air?- BC: yes.
Want to ask: important to me that a WebGPU example / demo’s source code is
not SPIR-V, it’s HLSL. Think we can make a good step forward on what we
agree on.- MM: agree with everything Ben just said. Want clarification on
point (2)- CW: (2) the API to ingest shaders is SPIR-V. Maybe something
else too. Thought this was what Ben said.- BC: from the point of view of
the JS signature for the WebGPU API, those entry points will take in SPIR-V
in binary form. But the corresponding thing is that if you put up an
example, the example will be written in HLSL. Everyone might have a
different story for how the HLSL is compiled. Some people might have online
or offline support. But we’d have commonality on SPIR-V production and
ingestion, on the high-level language.- MM: paraphrasing: think we can
agree on points (1) and (3) but not (2) -- don’t want the browser to ingest
SPIR-V.- By agreeing on points (1) and (3) think we’re moving the
conversation forward- BC: argument for point (2): lot of experience on the
Apple side you’ve wanted to share on efficiency of binary vs. text, etc.
Having Apple work in the SPIR-V space and gain experience would help
convergence. Microsoft will have to do some work and learning in SPIR-V
too. By trying it you might find it isn’t as bad as you thought.- MM: OK,
we can definitely get experience ingesting SPIR-V. But we don’t want to
agree that the final API will ingest SPIR-V.- BC: not trying to define the
MVP API. Just commonality to agree on at this moment to move the discussion
forward.- MM: sounds great. In addition, we will also work on a native HLSL
-> native platform path that bypasses SPIR-V.- BC: sounds good, will surely
not be throwaway work regardless.- DJ: as Myles as manager, I agree with
this direction- JG: sounds good. One of the things that we asked: was it a
good example for the initial tutorials to be HLSL based. That sounds fine
to me. Pretty much every set of tutorial websites choose the abstraction
level, including their own matrix library, etc. This would be the simplest
way to explain to people how to use the WebGPU API. Do think though that if
we are including a SPIR-V ingestion step, need to explain how the SPIR-V
interface works.- BC: bundle that into the “what pieces go into the
browser” question to be answered later.- JG: sounds like a good way to move
forward.- CW: sounds good. Just concerned that we’re just delaying the
question and we’re going to debate this again later.- BC: if we all go
forward with this then we’ll have multiple groups of people working with
the same framework of all of this, and the conversations won’t be going in
circles. Folks who have issues with SPIR-V will run into and raise those
issues. Can revisit this in a couple of months time. Better than talking in
the abstract.- KN: agree that this is one way to produce data and
experience on the problem. Want to point out that there’s still a vast
source of data still to be tapped, which is the ISVs, who already have this
experience. Want to make sure: if we agree on this, we might receive data
from ISVs that makes us go in a different direction before we’re done with
the implementation.- BC: some of this data is “what do we need to do to
build this” - building it is the best way to learn.Agenda for next meeting
- RC: shape of the API? NXT is strongly typed, builder pattern. Obsidian
has property bags, strings and stuff.- KR: suggest we talk about data
uploads and downloads. Jeff Gilbert gave some good suggestions to the WebGL
working group on how to use synchronous primitives with some magic behind
the scenes to make it async / efficient.*