Minutes 2019 01 21

Agenda / Minutes for the GPUWeb / VkPortability Meeting 2019-01-21

NT = Neil Trevett

CW = Corentin Wallez

BH = Bill Hollings

DM = Dzmitry Malyshau

MM = Myles Maxfield

DK = Daniel Koch

Vulkan Portability Update

• NT: Enabling subsets of Vulkan to be layered over other native drivers like D3D12 and Metal
  • Shipping early implementations of MoltenVk (Vulkan over Metal) - from Brenwill
  • Also, LunarG have created a version of the Vulkan SDK that are running on Mac
  • Both shipping today, both open-source
• NT: Longer-term goals: shipping multiple layered Vk implementations on D3D12, and maybe even D3D11. Capability support depends on underlying API
• NT: developing portability extension: lets app developer query what functionality is missing
• NT: extending Vk portability test suite so even if layered impl is missing functionality, tests still pass rather than crashing
• NT: enhancing some Vulkan tools layers so you can tell if you’re using functionality not in a particular impl, or emulate a less-capable impl
• NT: on Apple:
  • Using SPIRV-cross
  • On macOS 11 and up, and iOS 9 and up: functionality is very complete. Only ~4 things are missing.
  • Lots of stars on Github
• NT: coming up to ~1 year MoltenVk has been open-sourced. Dota 2 running on it. First iOS apps on top of it. Qt. People shipping stuff not asking or telling us. Wine games. RenderDoc. Dolphin emulator. Early prototype of extension on KhronosGroup/Vulkan-Portability.
• NT: <discussion of future timeline edited out>
• CW: how many ISVs are interested in VkPortability? Or is it more organic?
• BH: organic. Some people contributing actively. Codeweavers with Wine. Valve. Every one in a while we’re pleasantly surprised by something like Forsaken announcing.
• DM: Google’s Filament too.
• NT: probably a couple of dozen ISVs.
• BH: yes, about that. Wine folks aggressively moving games over to it. Mostly I hear about it if there’s an issue.

WebGPU Update

• CW: having F2F this week.
• CW: working on figuring out which features will be in WebGPU, and which have to be deferred as too complicated for now.
  • Goal for this F2F is to come up with JavaScript IDL file. Exact validation rules will come later. Converging reasonably quickly.
• CW: there’s question of shading language. Agreed to have one which is a form of HLSL that’s specified. Ongoing debate / divide on what browser should ingest; that high level language (WHLSL) or SPIR-V. That’s the biggest risk to the API right now.
• CW: aside from that, getting significant agreement.
• CW: impl status: Safari making progress on top of Metal API.
• CW: Google has a native impl of WebGPU on top of Metal, D3D12 and Vulkan. Some on top of OpenGL. Still need to integrate into Chromium.
• DM: FF has a triangle running on all 3 APIs.
• CW: aiming to have first implementations behind a flag probably mid-year.
• CW: optimistic timeline for first WebGPU release is not before early 2020, but hopefully not that far behind.
• CW: questions?
• ??: does the user decide which backend to run?
  • CW: will always be a preferred backend. Linux=Vulkan. Mac=Metal. Windows=probably D3D12. Unclear if app will be able to choose adapters from the web page; fingerprinting concerns.
  • JG: will probably be some control over which GPU is chosen.
  • CW: what I mean is that the browser won’t tell you you’re running on D3D12.

WebGPU and VkPortability Running Together

• MM: in design of VkPortability, are you thinking about running them on top of the other? If yes, which direction?
• NT: we’re aiming to be a portability layer. Interested in WebGPU. Haven’t done anything specially for WebGPU.
• DM: up until now the group’s been focused on Metal; less on D3D12. For the future, WebGPU is essential for VkPortability’s success. Want to build for a simple API, run on all platforms, and run on the web, too. Vk -> OpenGL -> WebGL is painful. Going through WebGPU would make this much better. WebGPU would be a first tier backend for VkPortability. Only reason it hasn’t happened yet is that WebGPU doesn’t have a shape yet.
• DM: the other direction is already implemented. We’ve implemented WebGPU on top of gfx-rs which has the same API as Vulkan.
• CW: seems WebGPU on top of VkPortability is forced to work. Other way should be doable. Didn’t do an extensive analysis, but feature level of WebGPU is ~= to that of Metal. Shouldn’t be that hard to implement or emulate things. Any feature we don’t support should already be part of carved-out subset of VkPortability.
• JG: could be tricky to capture certain restrictions. There might be some non-trivial things we leave out of WebGPU that aren’t easy to polyfill into VkPortability. Seems like a bigger risk.
• DM: that would be a task for the VkPortability WG. Doesn’t feel like WebGPU group has an incentive to prioritize that. We’re still cutting down Vulkan. If we were to go farther would have to cut more.
• JG: there’s a benefit for WebGPU to make this work. Cross-pollination between the groups. If VkPortability has concerns about things they’d like to see, WebGPU is still under active development.
• DJ: Have you seen Vulkan developers use VkPortability not for portability, but because it’s a guideline about what set of features to stick to for ease of use, etc?
  • NT: not sure. The subsets we have right now are very close to Vulkan. Triangle strips - not a big deal.
  • BH: agree. Extends the idea of querying the features that are available.
• MM: In Vulkan there are many optional features. Instead of making a new API, why not make more features optional?
• DK: that’s exactly what VkPortability is.
• MM: so VkPortability uses the same VkInstance?
• DK: you get a structure you can query. More things previously required are now optional.
• BH: right. Currently you can query for geometry, tessellation, etc. If you have VkPortability you can ask about tri fans, etc.
  • CW: another way to answer the question: Vk WG wants to still keep some things as mandatory requirement. Putting subset in main Vulkan would reduce guaranteed features of Vulkan, so Vulkan WG wouldn’t be interested in that.
• DM: would help if we knew by now what features we want to cut out of WebGPU. Still working on draft, still editing and removing features.
• KR: Having seen discussions in the WebGPU CG, a lot of effort was spend integrating the binding model of all three APIs. This was not discussed in VkPortability. Maybe binding model of Vulkan isn’t implementable on D3D12.
• DM: D3D12 has been working since day one, the binding model was a challenge to make work on D3D12 but it is resolved now. Having a fixed input target makes things simpler.
• MM: are there any numbers about how many Windows machines support D3D12 and not Vulkan?
• DM: don’t have the numbers, but Haswell and Broadwell don’t support Vulkan, and there are a lot of laptops with those. They support Win10 and D3D12 at some level.
• NT: UWP / Xbox. Might be interesting for VkPortability layer.
• MM: any support for Vulkan w/o D3D12?
• NT / all: Win7. Win8. :D
• NT: understand use case of WebGPU on top of VkPortability. Is other way around for Emscripten?
  • JG: yes, that’s the big one. To take existing Vulkan apps and port them directly to the web. We expect WebGPU to be a nice enough target that people will want to do full ports, but would be great if we could cross-compile with Emscripten.
  • CW: 2 stages for Emscripten support. 1) Compile to WebAssembly, magically VkPortability-on-WebGPU. 2) You want to use WebGPU, so use WebGPU native (with gfx-rs or Dawn), test there. If you compile to the web, it’ll use WebGPU with almost zero cost. Have incremental adoption if we have VkPortability on top of WebGPU.
• BH: would we anticipate add’l reductions of functionality with VkPortability on top of WebGPU?
  • MM: for example, no persistently mapped buffers - security / portability considerations on the web.
  • BH: exactly those kinds of things we’d want to know about.
  • CW: that’s one. Portability analysis we do for WebGPU tries not to add unnecessary limits. Mostly the same as VkPortability. More constraints: can’t expose exact geometry of hardware and driver. Expose “blessed knobs” to make portability easier. Also for security and portability we forbid data races. If you use a buffer as a storage and uniform buffer in the same pass, we reject it in WebGPU as a data race.
  • MM: data races aren’t impossible, they’re just hard.
  • DM: think we would expose persistent mapping, just without coherency.
  • NT: random thought. Just established Vulkan SC working group which will be interested in some of these things like data races, so good area for cooperation?

W3C Liaison

• CW: there are up to 3 groups / TSGs that want to talk with WebGPU. WebGPU also wants to talk with Khronos in general, for example to use the Data Formats spec.
  • WebGL WG needs to talk to WebGPU.
  • VkPortability needs to go both ways too.
  • Maybe Vulkan SC TSG.
  • How do you see this working?
• NT: From Khronos side, we’re open to liaisons. The more cooperation in the industry, the better in general. Any two orgs with IP agreements and memberships have to be careful. We have established a template for liaison that’s worked well for other groups (have done 3-4 in the past several months). Simple model. No hard-and-fast rule. Could make a proposal to the W3C. The way Khronos does it: both orgs grant each other membership rights at zero cost. In return, there is one restriction: there’s a limited number of people that can come into the other group’s meetings. Prevents floods of people. Usually 2-3 people is good.
  • Two orgs sign normal membership agreement, so normal IP framework is in place.
  • Interesting thing is that the org usually doesn’t have much IP; it’s all in the members’ orgs. The liaisons have to be careful to not take member IP from one org and put it into a design contribution for the other one. That’s another reason to keep the number of liaison folks down.
  • In this case, there’d be the added advantage that there are common members between the two. If we’re looking for one org to normatively reference stuff in either direction, having a formal liaison is helpful. From Khronos’ side, it’s a board-level decision, but would be amazed if Khronos’ board wasn’t supportive of entering into an agreement with the W3C.
• DJ: are the people representing Khronos in the W3C, or their companies?
  • NT: Khronos.
  • DJ: so if Person A in Khronos goes to a W3C group and contributes IP from Company B?
  • NT: they must not do that.
  • DJ: how do they know?
  • NT: liaisons need to know what they’re doing, be professional, and not make design contributions. Rather, help refine design requirements, marketing, etc.
  • NT: and of course if they want to they should join the host organization.
• CW: between W3C and Khronos, seems would largely come from VkPortability group. Wearing multiple hats then. Seems like a lot to manage without fumbling IP.
• NT: there are pros and cons. If company is member of both orgs that can be an advantage. You’re right, they have to be conscious about wearing multiple hats.
• DJ: I see it as a disadvantage because they have to be so conscious all the time.
• NT: may be helpful to have someone not involved with the host org. Liaison should state up front who they’re representing.
• KR: Are there IHVs in the VkPort TSG so a liaison might be able to bring up concerns to WebGPU on features that would cause horrible performance.
  • NT: NVIDIA’s the main GPU vendor participating. It wouldn’t hurt.
  • DK: if you wanted more IHV feedback you’d need a liaison with Vulkan. Portability is a TSG of Vulkan.
  • NT: if that’s one of the agreed goals of the liaison, we obviously have GPU vendors involved with Vulkan. Would probably be able to find people interested in working. GPU community needs WebGPU to be good, so we should be helping where we can.
• CW: makes sense. Sounds like it would be useful. Should probably start discussing between Khronos and W3C, figure out who the liaisons could be. And first liaison could gather requirements between the different groups. Not sure who to talk with at W3C?
  • DJ: I can help. Sounds like we should start by talking to W3C. Most interested between WebGPU to...Vulkan? Could be other interesting ones, like W3C’s ML group. If goal of glTF is to get it as a first-class format on the web that could be interesting too? If more easy to do that work in the W3C rather than talk to browsers directly could be a good one.
  • DJ: could say we’ve discussed between WebGPU and VkPortability groups and we want to collaborate.
  • NT: our discussions are friendly so we should move forward.
  • DJ: browser vendors are on the W3C’s advisory board. Slightly different: elected board.
  • NT: if you decide to do this, please introduce me.
  • DJ: think Apple’s / Google’s / Mozilla’s (Microsoft’s too?) advisory board members should talk with Neil.

Open conversation

• DM: tried to come up with a list.
• DM: investigation sharing. Unfortunately we didn’t share these.
  • Investigation of issues on WebGPU is making great progress thanks largely to Intel. Something we could borrow in VkPortability.
  • SPIRV-Cross. It’s not a deliverable of WebGPU, but 2 impls at the moment are likely going to depend on it, and VkPortability.
  • CW: was going to say SPIRV-validator too, but probably not directly useful to VkPortability.
  • DM: last item is dEQP. Would give us the framework to build conformance test suite for WebGPU.
• KN: don’t want to speak for David Neto but think the biggest thing we’d share are the shader tests. His team’s been doing some work in that area.
• CW: WebGPU being primarily a JS API, the conformance test suite will likely be written in JS. There are however a lot of data-oriented SPIRV tests that we would like to use. (data-oriented SPIRV test, put in some stuff in JSON)
  • KN: you have a lot of data for a test, and it runs in separate test runners using the same data.
• CW: another thing we could collaborate on: a spec for HLSL. Could also modify DXC to accept this Web-HLSL. HLSL is pretty underspecified at the moment and relies on optimizations to emulate legacy fxc behavior. If/when we have a WHLSL spec it provides a mainstream language that can target Vulkan and SPIR-V. Apple’s spec is using formal semantics making it tighter than the prose in the GLSL spec.
• NT: what about Vulkan’s memory model work?
  • CW: yes, very useful for WebGPU.
  • MM: this is one particular area where both potential shading languages for WebGPU would like to agree on. From what we’ve seen so far, SPIR-V WebGPU execution model and WHLSL spec both took parts of Vulkan spec under Creative commons license. Finding a few holes in the model, collaborating to fix them. Hope we and David Neto can talk about these.
  • CW: Robin Morrisset has already filed issues on memory model Github. Jeff Bolz has taken a look. They’re very good actionable feedback.
• NT: question for Dean: we’ve done some work on Metal (MoltenVk). Have a short list of things, if we had in Metal, we could make our subset miss fewer things. Is that useful data?
  • DJ: yes, useful data, please share.
  • MM: written down in an email or bug report would be ideal.
  • MM: when we prioritize these things, it’d be ideal to provide the context of what it’d enable.