Minutes for the 2017-09-06 meeting

GPU Web 2017-09-06

Chair: Corentin

Scribe: Ken

Location: Google Hangout
Minutes from last meeting
<https://docs.google.com/document/d/1TVcnZE9ygVuqzGohG7Yux_kmVv6EXmz7UnO2vwtzr7A/edit#heading=h.hp3f2zbslxr9>
TL;DR

   -

   Apple is prototyping a WebGPU Shading Language
   <https://trac.webkit.org/browser/webkit/trunk/Tools/WebGPUShadingLanguageRI>
   (WSL). Will contribute it to the group under the chosen license.
   -

   Clspv uses SPIRV variable pointers for the “getElementPtr” LLVM
   intrinsic. Adobe workload is OpenCL1.2 2D filtering with disciplined array
   accesses.
   -

   Shading languages /WebGPU target platforms:
   -

      Google wants to run on the majority of devices (including Android)
      shipping Vulkan now. Ready to cut some of the oldest chipsets.
Means SPIRV
      we cannot rely on SPIRV variable pointers.
      -

      Apple want to support all phone and desktops running Metal, on all
      feature levels.
      -

      Microsoft wants to support anything running D3D12. Baseline HLSL
      feature level is 5.1.
      -

   Shading language workloads:
   -

      Developers complains about lack of generic for int8 vs. int16 etc.
      Would like it for a specified high level language. Bytecode
wouldn’t expose
      it.
      -

      AI to make a comparison of available shading language feature
      (builtins, formats, etc). Would probably expose common subset.
      -

   Shading language security
   -

      Need to inforce Javascript “same origin” policy. WebGL is stronger
      than that as each context is its own silo.
      -

      Need to be careful with things like the CSS visited style that you
      could access from the GPU.
      -

      Impossible to add validation protecting against DDOS. Browsers should
      detect GPU resets (TDRs) and can balcklist GPU access on that origin.
      -

   Feedback that we need to better organize our documentation.

Tentative agenda

   -

   Administrative stuff (if any)


   -

   Individual design and prototype status


   -

   Shading languages
   -

   Agenda for next meeting

Attendance

   -

   Dean Jackson (Apple)
   -

   JF Bastien (Apple)
   -

   Myles C. Maxfield (Apple)
   -

   Theresa O'Connor (Apple)
   -

   Keith Miller (Apple)
   -

   Corentin Wallez (Google)
   -

   David Neto (Google)
   -

   Kai Ninomiya (Google)
   -

   Ken Russell (Google)
   -

   Ben Constable (Microsoft)
   -

   Chas Boyd (Microsoft)
   -

   Rafael Cintron (Microsoft)
   -

   Dzmitry Malyshau (Mozilla)
   -

   Jeff Gilbert (Mozilla)
   -

   Kirill Dmitrenko (Yandex)
   -

   Doug Twilleager (ZSpace)
   -

   Elviss Strazdiņš
   -

   Joshua Groves

Administrative items

   -

   Today’s the (somewhat arbitrary) deadline to attend the face-to-face
   meeting in Chicago
   -

   With Dean, been in touch with Dominique from W3C to do a demo of what
   GPU tech might look like for the web for TPAC
   -

      Starting discussions, getting interest. More so than API / IDL

Individual design and prototype status

   -

   Apple
   -

      Doing a lot of work on reference implementation for a potential new
      shading language
      -

      Not yet comfortable bringing this to the group
      -

      Can compile functions, resolution, generics, some amount of checking.
      Getting there
      -

      BC: any details you’re willing to share? LLVM/Clang based? C-like
      language?
      -

      MM: doing all this work in open source. Search for “WSL” - WebGPU
      Shading Language
      -

      Not Clang-LLVM based. CPU side interpreter in JavaScript
      -

      At some point it’ll emit MSL, but right now implementing an
      interpreter
      -

      Language itself is similar to C. Not like Python, not like bytecode.
      Doesn’t have pointers. Does have references.
      -

      CW: Pointer into source code? for minutes
      -


      https://trac.webkit.org/browser/webkit/trunk/Tools/WebGPUShadingLanguageRI
      (start with prepare())
      -

      BC: licenses?
      -

      DJ: it’s in the WebKit tree, so WebKit license. Joint BSD/something
      else. Will contribute it to the group. Will then be W3C license (rather,
      the one MSFT/Apple/GOOG are working on).
      -

      BC/DJ: discussion about legal stuff. Other projects like LLVM doing
      similar things. Trying to do things in a unified way.
      -

   Google
   -

      CW: not much. Studied memory barriers more. Trying to find technical
      reasons to choose implicit/explicit.
      -

      MM: started trying to implement his ideas on Vulkan but found it was
      difficult. :D
      -

      BC: you’re not alone :D
      -

   Microsoft
   -

      RC: no updates
      -

      BC: trying to work through thoughts on barriers. Will try to
      contribute productively today
      -

   Mozilla
   -

      DM: making good progress on prototype in Servo
      -

      Have SwapChain, pipeline barriers, can render stuff with a few FPS
      right now

Shading languages

   -

   CW: let’s center the discussion on what we know for sure what we want,
   and what’s possible vs. not.
   -

      Type of workload
      -

      What’s the low-level definition of security
      -

      What are the hard platform constraints
      -

      For example, since last meeting we found more info about D3D12 and
      Vulkan.


Target platforms

   -

   CW: hard platform constraints
   -

      The set of devices that Google wants to be able to support which run
      Vulkan may not have the variable pointer extension
      -

      The shading language for WebGPU can’t practically have pointer
      arithmetic.
      -

      Want to support the Vulkan that’s out there today.
      -

   DN: variable pointers extension is ratified (the status line on the Web
   site is out of date). Vulkan has ratified it. NVIDIA is shipping production
   drivers containing it. dneto has a code base and compiler which uses it.
   Talked about at Khronos 3D BOF at SIGGRAPH. Worked with Adobe to define a
   subset, and variable pointers fell out of that work.
   -

      Workloads: 2D data accessing some algorithmic filtering. Some uses of
      images as expressed in OpenCL 1.2. Filtering via samplers. 32-bit data.
      Some disciplined use of 8-bit data and 16-bit float data. Very
disciplined
      array access.
      -

      Fairly standard OpenCL 1.2.
      -

      Variable pointers: similar to getElementPtr in LLVM. Vulkan requires
      strong typing. Can’t do bitwise reinterpretation of pointee
types. Instead
      do bitwise reinterpretation after loading the data.
      -

   DJ: does this mean that only NVIDIA devices can run this?
   -

      DN: Vulkan extension VK_KHR_variable_pointers allowing you to use it
      has only been out ~6 weeks or so. Expect that in the fullness of
time it’ll
      be more widespread.
      -

   CW: if we want to support e.g. Galaxy S8 which may not pick up drivers
   that have this extension, then we can’t rely on the presence of this
   extension
   -

   MM: If a phone doesn’t get a driver update, will it get a browser update?
   -

   CW: yes. The driver’s not supplied via the play store. Yet.
   -

   MM / CW: Discussion about Android 8.0 (“Oreo”) and the updatable
   graphics driver model. Browser’s updated via the App Store though.
   -

   DJ: Chrome/Mozilla are continually updated. System browser is never
   these?
   -

      Not necessarily. Samsung may ship their own browser but not
      necessarily every phone vendor will do that. Samsung also updates their
      browser via Play Store.
      -

   CW: should be able to ship on current Vulkan on current devices.
   -

   MM: unreasonable to put a Vulkan driver in the browser?
   -

      CW/JG: not possible.
      -

   DJ: of existing phones: what level of Vulkan support do they have?
   -

      CW: the hope is that they pass conformance and the Android CTS
      requires this. It’s a good question. Hoping that the API we ship
here will
      be a subset of Vulkan so that if it doesn’t use all the knobs,
it gives us
      some leeway to not stress all the corner cases which might have
driver bugs.
      -

   DJ: Android 7 is the previous version. Is that the level of device we’re
   targeting?
   -

      CW: Vulkan became available in Android M. Not required as part of the
      platform, only OpenGL ES 2 required.
      -

      DJ: so even an Android 8 device might not have Vulkan. Also hardware
      dependent.
      -

   MM: do we have a feel for how many planned devices are going to get
   Vulkan support?
   -

      CW: hard to tell for sure. Any of the newer IHVs’ chipsets are going
      to be able to run Vulkan.
      -

   MM: Dean trying to say: verify that the base conformance we’re targeting
   is an Android 8.0 device with Vulkan support?
   -

      JG/CW: not Android 8.0. Android N / 7.1.1.
      -

   CW: what’s Apple’s target?
   -

   MM: all phones and desktops running Metal.
   -

      Target feature levels?
      -

      Even low feature levels. Even baseline Macs from a few years ago.
      -

      JG: sounds like it’s in line with Mozilla’s desire to run anywhere a
      new-gen API is available (Vulkan/D3D12/Metal).
      -

   RC / BC: anything that can run D3D12
   -

   CW: so: need to support anything that runs the current nextgen APIs.
   Can’t rely on the variable pointer extension. Not sure if D3D12 requires
   shader model 6.0, or 5.0?
   -

   MM: would like to know this because it changes the shape of the shading
   language.
   -

   RC: Believe that it is 5 / 5.1
   -

   CB: there’s no difference between 5/ and the current compiler. Just
   switched to the LLVM based IR. But wanted to support D3D12 with the classic
   functionality (5.1). No difference between 5.1 and 6.0 in the feature set.
   -

      MM: voting functions?
      -

      CB: those intrinsics are optional
      -

   CW: this helps us understand what we’re going to go out on.
   -

      Pointer interactions seem hard.
      -

   JG: is the shader model in D3D12 more sophisticated in that regard?
   -

   CB: Not really. Pretty basic.


Kinds of workloads we want to support

   -

   CW: want to be able to run any kind of graphics things (e.g. WebGL 2.0),
   maybe without transform feedback
   -

      People have expressed interest in machine learning and compute
      -

      Voting intrinsics? Shared memory?
      -

   MM: assume you’re talking about threadgroup memory?
   -

      Don’t think that’s supported in rendering operations across all the
      APIs
      -

   JG: yes. graphics / compute different. But the differences are similar
   across the APIs.
   -

   MM: have talked with some teams using Metal. Some teams will write
   duplicate code because of different data types. Shaders that work on floats
   vs. halves. Some sort of generics would be valuable.
   -

   JG: disagree. If it’s not reflected in the APIs we’re targeting then we
   shouldn’t support it.


   -

   DN: Generics seem like a frontend feature, depends on the level of
   abstraction we want to have.
   -

   CB: Historically the languages have been type safe but the data fairly
   polymorphic.
   -

   JG: continuation of the philosophy that you get exactly what you ask
   for. Adding generic types on top of shaders which don’t support them means
   you’re doing dynamic shader recompilation.
   -

   CW: none of the APIs support generics right now. Or MSL, which
   specializes at compilation time.
   -

   MM: should have stated this more clearly. Agree that if we were to
   standardize some bytecode, bytecode with generics doesn’t make sense.
   -

   KR: Instead of language feature, focus on what kind of compute
   operations we want to support. We should choose a minimal compute
   featureset for the MVP, then add things as incremental steps. Choose
   bite-sized things. David your experience with Adobe is the most concrete
   thing we have.
   -

   JG: there’s still a strawman proposal of just subsetting what the 3 APIs
   can do, make it secure, and go with that. Rather than hand-picking what
   operations we want to support.
   -

   KN: any language feature that we could add which isn’t part of one of
   the representations in the underlying APIs is something we shouldn’t talk
   about now. Any feature we can add that we’re going to convert down to the
   backing API isn’t something we have to figure out now.
   -

   CW: that sounds correct. Also: there’s a bunch of compute related
   features that go together. For example, SSBOs go hand-in-hand with
   read-write images.
   -

   MM: why’s that the case?
   -

   CW: As soon as you want to do compute workloads you want to output data.
   Either into buffers or images. But when you have compute shaders you want
   to write to both buffers and images: this is most basic functionality. But
   most compute features are basic functionality that you can’t do without.
   For example, if you don’t have threadgroup storage, or don’t have
   arrays-of-arrays, etc., not useful.
   -

   JG: I can take an AI to go through what Vulkan offers, and then go
   through and see what isn’t supported by the other APIs and strike what
   isn’t supported.
   -

   MM: When you talk about feature, do you mean per-builtin, or large
   groups of operations.
   -

   JG: talking about e.g. SPIR-V opcodes
   -

   MM: e.g. every function in the standard library?
   -

   JG: The standard library is rather small.
   -

   DN: what sort of resources can you access. Can you have samplers on
   images. Etc.
   -

   JG: figuring out what is the common compute functionality among the
   various APIs.
   -

   CW: then we’ll have the maximum and minimum subsets.


Security

   -

   CW: been a lot of discussions. Difficult to define properly.
   -

   JG: the rules we have for WebGL: can’t access anything you’re not
   supposed to: data from another process, etc. Can only access your data,
   both read/write. There’s a little leeway about whether we should require
   repeatability / portability / testability. Those are contentious and not
   absolute concerns. It’s required that you can’t read/write data you don’t
   have access to.
   -

      Also: you can cause TDRs, but we recover from them.
      -

   CB: there was discussion about what you should be allowed to have access
   to.
   -

   TOC: same-origin policy of the web. Have to obey that.
   -

   JG: that’s a good way to think of it. In WebGL each context is its own
   castle. But in WebGPU we could say that different pages on the same origin
   can see each others’ content.
   -

   KN: basically, anything you can access from JavaScript you can access
   from the GPU. (see, CSS visited links).
   -

   CW: Basically have requirements. how do we move forward?
   -

   JG: have to detail what aspects of the shading language are considered
   unsafe. SL might not care as much to let you see previous data from the
   same process. In the Web we might be rendering multiple pages in the same
   process. Logical addressing mode is more constrained and helps make sure …
   Need to find all the things in SL that aren’t safe we need to make safe.
   -

   MM: one other case about security: on some devices and some OSs there is
   hardware protection (dereferencing null pointers in shaders, etc.) but the
   response is to do a total device reset. No web page should be able to do
   that.
   -

   CW: ideally yes. But on Windows for example we use the “reset the GPU”
   functionality (TDR) as a way to recover. For example, you can write
   infinite loops in shaders. Basically any system might lock up and require
   the GPU to be reset.
   -

   MM: as a preprocessing step for shaders you could insert counters that
   have back-references.
   -

   JG: that doesn’t solve it. For example, pessimistic texture cache
   thrashing. Possible to easily hit timeouts.
   -

   RC: Even simple shaders across huge amounts of triangles can cause TDRs.
   -

   KR: Experience from WebGL is that in cases it is necessary to base DDOS
   defense on GPU resets. Examples in the WebGL repo, bunch of alpha blended
   triangles, etc. Not possible to defend against these cooperatively in the
   shader. Have to admit that GPUs will be reset. We can guard against nullptr
   dereferences and clamp buffer access. That might be enough for WebGPU’s
   security.
   -

   JG: Shouldn’t target a more restrictive security model than WebGL.
   -

   CW: on some systems like Linux, DoS does take out your machine. (Maybe
   not. NVIDIA supports KHR_robustness. Think AMD does too.)
   -

   KR: Try to push vendors to implement GPU watchdogs but wasn’t specified
   fully in the first KHR robustness extension
   -

   MM: When you say Linux do you mean Android too?
   -

   CW: No data but would be surprised if it were better.
   -

   RC: one mitigation on Edge/IE on Windows: if we do see a TDR, we restart
   WebGL in software mode. So malicious code only affects the current page.
   Not the entire desktop.
   -

   KR: Chrome has a similar mechanism, on recurrent TDR Chrome will prevent
   that origin from using WebGL.
   -

   JG: Some extensions tell you if you are an “innocent” or “guilty”
   context.
   -

   KR: unfortunately that’s not reliably supported anywhere.


Conclusion

   -

   CW: AIs from today:
   -

      Make a list of features supported in different compute and shading
      language APIs
      -

      Need more samples of workloads we want to run
      -

   KR: Not enough links in the wiki / gpuweb repo. Need to do an effort on
   the documentation.
   -

   MM: the thing I made is on the front page…
   -

      https://github.com/gpuweb/gpuweb/wiki/Roadmap
      -

   CW: started making tl;drs of minutes.
   -

   DJ: Will take an AI to address what Ken wants.
   -

   CW: for shading languages, let’s do writeups and gather samples.
   -

      Next week: roadmap document Myles made to have consensus on consensus.
      -

   Meeting in Chicago in two weeks. CW: AI: make proper agenda. Can CB
   attend remotely? Yes.
   -

   So: let’s discuss shading languages at the F2F.

Agenda for next meeting

See conclusions.