Skip to content

Minutes 2019 12 09

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

GPU Web 2019-12-09

Chair: Corentin

Scribe: Ken

Location: Google Meet

TL;DR

  • Neil Trevett presented slides discussing how SPIR-V could be used by WebGPU and under which constraints.
  • Lots of good discussion on the various aspects of what would happen if WebGPU used SPIR-V. See detailed minutes.

Tentative agenda

  • W3C-Khronos liaison
    • Requirements/possibility for potential:
      • fork of the SPIR-V spec that is not owned by Khronos
      • normatively referencing the SPIR-V spec with extensions and subsetting
      • (example): what about a different way to do tessellation, how obligated is the SPIR-V group to take it? Comment on it? Have any opinions at all about it?
      • What about reorganizing the SPIR-V spec into a single document? Feasibility of that, esp. for WebGPU specifically?
    • What are the implications of using the SPIR-V spec in the WebGPU spec if certain implementers of WebGPU don’t grant a reciprocal IP license in the file format adopters’ program?
    • How can the WebGPU group provide bugs, feedback or “contributions” to the SPIR-V WG?
      • Would people need to join the SPIR-V IP zone to contribute to SPIR-V?
    • (stretch) what about normatively referencing the Khronos Data Format spec
  • Agenda for next meeting

Attendance

  • Khronos
    • Neil Trevett
  • Apple
    • Dean Jackson
    • Myles C. Maxfield
    • Robin Morisset
    • Maciej Stachowiak
    • Saam Barati
  • Google
    • Austin Eng
    • Corentin Wallez
    • Dan Sinclair
    • David Neto
    • James Darpinian
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
    • Ryan Harrison
  • Intel
    • Yunchao He
  • Mozilla
    • Dzmitry Malyshau
  • W3C
    • François Daoust
    • Dominique Hazael-Massieux
  • Timo de Kort

W3C-Khronos liaison

Neil Trevett’s (NT’s) slides

  • DM: Is SPIR-V a file format?
    • NT: Yes, zero-cost clickthrough with no conformance tests
  • MS: if our file format ends up being a variant are there any implications?
    • NT: yes, we’ll cover that later. If you change functionality then you’re definitely not covered under the IP framework. If you only use partial functionality then you’re covered.
  • MS: if you only have partial support you can’t pass the conformance test suite. How does conformance testing apply to partial impls of a file format?
    • NT: only for APIs do we have conformance tests.
    • MS: so no conformance testing for file formats?
    • NT: normally a set of tools, validators, etc. But no need - almost impossible for the reasons you outlined - to have conformance tests on how someone would use a file format. From eng pt of view, a click-through is a no-op, but still significant from a legal standpoint.
  • MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that.
    • NT: nobody is forced to come into Khronos’ IP framework.
  • NT: if WebGPU wanted to make SPIR-V extensions, maybe those could be created under the W3C IP framework. Also, if WebGPU WG wanted to mix custom version of SPIR-V, subset stuff (that doesn’t break conformance), vendor extensions etc., and normatively reference SPIR-V, then that mixture spec could be created under W3C IP framework.
  • NT: would encourage WebGPU WG to put any SPIR-V extensions it creates independently into the Khronos registry. Though not required.
  • DJ: SPIR-V spec & source materials not currently in the “yellow zone” - but could be moved there?
    • NT: yes - could be discussed - do we have SPIR-V people on the call?
  • MS: it sounds like - we could make something that’s textually a fork of the source spec, while normatively referencing the SPIR-V spec - is that correct?
    • NT: yes.
  • DM: we can subset functionality in the extensions? Similar to VkPortability? Does SPIR-V have no extensions right now that do this?
    • NT: typically - and anyone from SPIR-V please correct - Khronos specs don’t do subtractive extensions. Don’t think you’d need to do that. On top line (between green and purple boxes), could say, this spec includes SPIR-V except such and such. Just carve out what parts of SPIR-V you want to bring in as your baseline.
    • DN: typically, API spec will say, we expect shader modules with this whitelist of capabilities/formats, and that’s how subsetting occurs.
    • MM: aren’t extensions opt-in though? If file doesn’t opt-in then you don’t get that subsetting?
    • DN: it’s another aspect, where shader module, yes, does declare what it relies on. To use e.g. 16-bit ints, have to declare that. VkContext creation, you say that you need a driver that exposes that feature, so you can instantiate shaders that use that functionality.
    • NT: if you’re creating WebGPU extended spec, it’s up to you what you put in that spec. E.g., we’re not including such-and-such parts. Could say, WebGPU spec mandates certain set of extensions. Can subtract that out.
    • CW: David & team have drafted WebGPU env spec for SPIR-V - sounds like that document could be folded into WebGPU extended SPIR-V spec. “We only allow these opcodes”, “require these extensions”, etc.
    • NT: exactly.
  • MM: in a world where we’d have our own documents similar to what’s in the yellow box (but not the same - removing functionality) - why would we phrase things as extensions at all? Not just put into core documents?
    • NT: you could do that. Khronos offers extension functionality if you want to use it. If there’s functionality you want to build into core spec you could do that.
    • DN: example: in Vulkan spec you can get just the core spec, and one with extension functionality folded inline directly. We use “extension” to describe things beyond the original core. How it’s presented is up to who’s writing the spec.
    • NT: also, you can create all your work under the W3C IP framework. That could apply whether you’re making the core spec or extension specs.
  • NT: the simple liaison is only an agreement to sit down and talk - nothing about IP or detailed designs. If we want to work together more closely we could (just brainstorming) extend the simple liaison to cover detailed designs more.
    • NT: if it turns out it’s good for WebGPU to get something into core SPIR-V - we can definitely take requirements, bug reports, etc. We can provide feedback - happy to do all that. One thing we have to avoid - taking detailed designs from W3C. Just IP concerns.
    • CW: you said W3C licenses IP in the spec to anyone. If we had a W3C recommendation that creates new IP related to SPIR-V, would it be licensed to everyone, including all Khronos members?
    • DJ: I think the diff is, W3C gives you royalty-free license for implementing WebGPU. If WebGPU implemented something like SPIR-V, then it would be clear that you could only use those for implementing WebGPU.
    • NT: exactly. This is a good point, and also: there are differences in the IP policies. W3C contributions couldn’t be taken into Khronos specs unless the policies matched exactly. But I don’t think we need that. Perfectly workable flow without doing that logistically tricky part.
  • FD: extended SPIR-V “mix” documentation - hypothetically - what status would it had? W3C recommendation on its own? Something different?
    • NT: it’s up to W3C. I’m not qualified to say.
    • FD: in this case we want the patent policy to apply to the whole. But in this case some of it comes from the SPIR-V spec. But we only have patent commitments from the WebGPU group.
    • NT: you have the option of creating your own spec, referencing SPIR-V. You could certainly mix the purple and blue boxes. As long as you have the normative reference you still have Khronos IP protection. Source materials covered under CC-BY. If you use those tools to create your spec under W3C - not ratified by Khronos - that’s fine.
    • MM: let’s say we made our document (from the yellow box), added / removed stuff, and had normative reference to SPIR-V. Would we need to annotate parts that are identical, or just have one line saying “parts are from the SPIR-V spec”?
    • NT: you have to have clarity. You need to say what parts are unchanged, because otherwise you don’t know what’s covered by IP agreement. Could have a side table saying what’s unchanged / changed. As long as you have clarity, you can decide the best way to manage that.
  • RC: what about contributing opcodes? Do those constitute submarined IP? Do we have to say what they’re for?
    • DN: the submarine aspect only happens if you try to merge it back into the Khronos specs proper. I.e., when NVIDIA released ray-tracing they published extensions in the normal form. Didn’t have to collaborate at all, but out of courtesy they published them on the registry. Basically no Khronos interaction aside from publishing. Submarining could only happen when contributing to Khronos pool.
    • RC: what if someone wants to contribute to make tools work well with raytracing. How does that work with only being able to contribute certain things?
    • NT: if a company like nvidia wanted to get their raytracing ideas into core spir-v from khronos, then obviously they’d participate in the wg at khronos.
  • CW: Going through the original agenda:
  • fork of the SPIR-V spec that is not owned by Khronos
    • MM: let’s say we make a doc that’s the yellow box but adds/removes stuff. Can’t contribute detailed designs back to Khronos. Would be targeting particular version of SPIR-V spec - not getting additions SPIR-V would make to their doc. Sounds to me a lot like a fork because info doesn’t transfer back and forth.
    • NT: there is a danger - would like to avoid that given legal constraints. Think thing on right hand side is imp’t. If something comes up, e.g. it would be really good if core SPIR-V from Khronos did this thing - would be great to send it over as a high-level requirement. That’s absolutely fine. Can’t go down to the level of saying, the spec has to look like this. That’s the realm of IP contribution. Do think we could capture this with a slightly deeper liaison. We want WebGPU to be happy with SPIR-V.
    • MM: procedurally I don’t think it’s reasonable for us to describe a problem to Khronos and hope they come up with something matching our constraints. Seems to me that we’ll be solving our problems.
    • NT: you’ll be solving your problems, and I’ll bet you’ll also find functionality holes in the core spec. Would be great if everyone could adopt them. Doesn’t require anyone to join the Khronos IP framework to do this - we have great external contributors right now.
    • DN: things only collide when you have overlapping “something” - e.g. two definitions of the same noun/verb. E.g. we create WebGPU-flavored images, and the core spec has their own images, but they use different token numbers.
    • MM: the future is a long time - hard to believe that’ll never happen. Also - tools have their own licenses. If contributing to tools is their own license, and we impl it in WebGPU and ship it in browsers, why would we contribute it back to Khronos? Already contributed it to the tools under the tools licenses.
    • NT: you’re not obligated to contribute it back. Only question, is there an advantage to having it in the core tools? More momentum, more people looking at the solution and helping improve it?
  • RC: suppose group comes up with new fancy way of doing tessellation or similar. What obligations if any are there to contributing it back? Or some graphics rendering thing that exists in another form in the tools? Do SPIR-V folks tpically accept these?
    • DN: e.g raytracing again. NVIDIA developed tooling across dxc, spirv-tools, and others. (glsl extension, Vk extension). Extensions in 3 APIs, developed all this until they decided to publish. Then contributed it back. That was nice. They were incentivized to do so because of the ecosystem expansion.
    • DN: sometimes there’s a contribution that’s not well thought through, e.g. by someone new to the ecosystem. Sometimes we’ll read their spec and jam it into the spir-v tools.
    • RC: so that’s true for things that are being contributed that work differently from the core spec?
    • DN: yes. AMD for example contributed extensions to shader ballots that were ultimately folded into the core spec.
  • What about reorganizing the SPIR-V spec into a single document? Feasibility of that, esp. for WebGPU specifically?
    • MM: sounds like two paths:
      1. take what’s in the yellow box (if green box turns yellow, all the better), we add/remove stuff, have normative reference and annotations referring to ratified spec.
      1. We publish extensions, reference ratified spec, and list requirements that WebGPU impl must reference those extensions
    • Are these correct?
    • NT: sounds correct. Or could have hybrid of those 2 mechanisms.
    • CW: we could say, execution environment for WebGPU could be part of WebGPU extended spec. WebGPU specific extensions could be standalone SPIR-V extensions, made by W3C, or vendors themselves.
    • NT: sounds correct. Can use whatever mechanism works best for particular functionality.
  • What are the implications of using the SPIR-V spec in the WebGPU spec if certain implementers of WebGPU don’t grant a reciprocal IP license in the file format adopters’ program?
    • NT: means that you’re not entering into the mutual license grant of the originators of the spec. It’s a possibility that one of the originators of the spec may assert patents against that implementer. That’s what the IP framework of both organizations is intended to avoid. Could argue that it’s a file format, much less IP-sensitive than APIs. But there is an increased risk if that adopter doesn’t enter into the IP framework.
    • MM: in these collaborative possibilities we’ve been discussing nobody signed anything. What am I missing?
    • NT: all talking about Khronos’ definition of Adopters of these specs. If don’t agree into dual IP licensing - that’s a question up to the adopter.
    • CW: would W3C need to adopt SPIR-V without IP agreement to use logo?
    • NT: only if W3C was actually adopting SPIR-V. They’re not.
    • RC: what if implementer doesn’t sign anything with Khronos?
    • NT: then it’s a trademark violation. If you say you’re SPIR-V conformant and you haven’t signed anything, you’re in violation and Khronos takes steps to protect our trademarks.
    • RC: suppose I’m an Adopter but I don’t put any logo, etc.
    • NT: if you don’t want to use the trademark and don’t want IP protection then you don’t have to sign anything.
  • How can the WebGPU group provide bugs, feedback or “contributions” to the SPIR-V WG?
    • No detailed designs.
  • Skipping Khronos data format spec.
  • MM: interesting if we did standardize on spir-v if some implementers wouldn’t be able to use the name of the language they’re implementing.
  • MM: has spir-v wg ever considered possibility of textual grammar of the language?
    • DN: there is a spir-v assembly text format, non-normative, that’s 1:1 in terms of functionality.
    • MM: any thoughts about making it normative?
    • DN: that hasn’t been discussed.
  • CW: going back to trademark note - adoption of trademark license is free and comes with no ip implications.
    • NT: right. Khronos Adopters program for file formats lets you click to get the trademark license without entering into IP framework.
    • RC: suppose somebody does sign all the agreements. What about implications for other things in SPIR-V IP zone like Vulkan, etc.? Can contributions to SPIR-V be used in Vulkan?
    • NT: no. Contributions are to an individual spec. Similarly, question of asserting Essential Claims against an implementer of a particular spec.
    • RC: so if people want to contribute substantial detailed designs, that’s where the IP framework comes in.
    • NT: yes - that’s where it would make sense to become a Khronos member and contribute under the IP framework.
    • RC: and if someone participates, better not speak in both?
    • NT: both groups have to worry about submarined IP.
  • MM: this was very helpful Neil. Thank you.
    • NT: no problem.

Agenda for next meeting

  • CW: Should we keep discussing this topic next week?
    • MM: no.
    • FD: if you want advice from W3C legal, that can be arranged.
  • Buffer mapping
Clone this wiki locally