Skip to content

Minutes 2018 01 10

Jump to bottom
Corentin Wallez edited this page Jan 4, 2022 · 1 revision

GPU Web 2018-01-10

Chair: Corentin

Scribe: Ken

Location: Google Hangout

Minutes from last meeting

TL;DR

  • Spectre/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
    • 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 meeting

Attendance

  • 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 Dmitrenko

Recap 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 papers

Spectre/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 languages

Google’s position document

  • 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.
Clone this wiki locally