Skip to content

Minutes 2019 04 29

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

GPU Web 2019-04-29

Chair: Corentin

Scribe: Ken

Location: Google Meet

TL;DR

  • SampleMask and friends #267
    • Consensus to have alpha-to-coverage and sampleMask in the pipeline and sampleMask in the shader as well.
  • getSubData/setSubData #213/#280
    • Would be nice to benchmark mapWrite to see the gains from setSubData.
    • Consensus to remove setSubData and not do getSubData for the MVP.
  • Exposing device limits #275
    • Ties into whether we should expose the equivalent of GL_RENDERER.
    • Exposing GL_RENDERER was important to help clients of WebGL workaround issues but now privacy is a bigger concern.
    • Risk that people start a WebGL context just for GL_RENDERER to workaround WebGPU issues.
    • AI: Discuss this with each browser’s privacy folks for the F2F.

Tentative agenda

  • SampleMask and friends #267
  • getSubData/setSubData #213/#280
  • Exposing device limits
  • Agenda for the F2F.
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Corentin Wallez
    • Kai Ninomiya
    • Ken Russell
    • Shrek Shao
  • Microsoft
    • Chas Boyd
    • Rafael Cintron
  • Mozilla
    • Dzmitry Malyshau
    • Jeff Gilbert
  • Timo de Kort

SampleMask and friends #267

  • CW: nice investigation from Intel. Multisample coverage. 3 features interacting closely. Programmable side of multisampled textures. Features are:
    • Specifying sample mask as output of frag shader
    • Same thing, but with fixed sample mask when compiling pipeline
    • Alpha-to-coverage. Coverage computed from alpha in a HW-dependent manner.
    • DM took a look but discussions on the issue are that we’d like all 3 of these in WebGPU.
    • DM: correct. Only aspect without consensus: supporting sample mask provided by the pipeline. Jiawei suggested we don’t, but I think we should. There’s a way to work around that in Metal, and it’s supported by the other native APIs.
    • CW: on most hardware it’s a hardware state, so it’s probably faster than dynamically changing it in frag shader. Or we could find static writing of a constant value in shaders and pull it out and put it in the pipeline state.
    • MM: in order to make this decision, need to see whether the performance tradeoff’s worth it.
    • CW: additional API surface vs. gains?
    • MM: on one hand, having this feature is good, but on the other hand, not having portable performance is bad.
    • DM: we’re just talking about one AND operation in the shader. Not too concerned about perf in this case. Have concern that if we don’t allow the mask then developers don’t have a good workaround path. APIs don’t allow them to have both alpha-to-coverage and output mask. If no output mask on the pipeline, they’ll have to do it in shader, and that conflicts with alpha-to-coverage.
    • KR: is this emulatable on Metal?
    • CW: yes. Can AND the app’s sample mask with the app-provided one. Seems the additional complexity on Metal is tiny. Think we should just expose the 3 of them.
    • MM: when we’ve spoken to hardware teams, this is not a particular area where people are asking for the feature. (Putting it in the PSO rather than writing it in the shader.) So if people aren’t asking for it then we should not put it in because it can always be added later.
    • DM: the effect’s achievable in Metal because you can merge it with alpha-to-coverage. But if we don’t expose it then people are going to have issues using it with alpha-to-coverage.
    • MM: not saying it shouldn’t be possible to set the coverage. Just whether it’s in the PSO vs. the shader.
    • CW: if you enable alpha-to-coverage but also set SampleMask in shader, then alpha-to-coverage doesn’t apply. So if you want to AND SampleMask and use a-to-c, then you either have to emulate a-to-c in the shader (problematic - why?), or have to set both states on the pipeline object.
    • DM: MM so you’re concerned about the perf Metal will lose because of this path?
    • MM: yes, not sure whether it’s big or small.
    • DM: how would you do this more efficiently on Metal regardless?
    • MM: having perf portable is important. If you can emulate it then it’s a question of the perf tradeoffs.
    • KR: In this case we know that it isn’t possible to emulate the combination of SampleMask in the FS, + a-to-c, on Vulkan and D3D12.
    • MM: should we have a-to-c in the MVP?
    • CW: Important to have, game engines use alpha to coverage instead of blendings sometimes.
    • DM: it’s also used for things like objects fading in and out of the camera view. Common case in games.
    • CW: use it to blend between things changing LODs. Use it for most opaque objects that you want to blend. Makes a transparent pass inside the opaque pass which is a good thing.
    • CW: a-to-c is critical. Agreed?
    • DJ: OK, we’re OK.
    • CW: everyone agrees we want SampleMask in the shader. SampleMask on the pipeline or just in the shader? Only concern is that you can’t use atoc and write the SampleMask in the shader at the same time. Otherwise the SampleMask wins. In order to make this work you have to set the SampleMask on the pipeline state (as well as atoc).
    • (repeating this)
    • KR: it’s just taking Vk’s and D3D12’s limitations in this area.
    • DJ: OK. So you want SampleMask in the pipeline object? and the shader? and if it’s in the shader, then atoc should always be disabled?
    • CW: yes.
    • DJ: what would happen if you don’t put it in the pipeline, but put it in the shader? The shader version would win?
    • CW: yes. But if you have the SampleMask inside the pipeline and atoc also set, then it ands things together.
    • DJ: OK.
    • CW: OK, so we’ll put both in the pipeline state and allow SampleMask to be written in shader?
    • DJ: yes.

getSubData/setSubData #213/#280

  • CW: have two PRs: one which adds getSubData and one which removes setSubData.
  • JG: I put up a PR to remove setSubData because it’s not semantically required by the API. Can polyfill it. Provided some polyfills. Don’t think it’s a good candidate for requiring in the MVP.
  • CW: think we’d be OK with that, esp. considering it’s an easy polyfill. Folks that want most efficient upload path should be using the same method anyway.
  • JG: I think that’s the case. If someone can show on top of an MVP prototype that it’s beneficial to have get/setSubData that’d be nice, but technically outside the scope of an MVP.
  • CW: our prototype does a lot of copies when you map buffers right now.
  • KN: means we can’t prototype the polyfill right now.
  • JG: propose we merge the setSubData PR and abandon the getSubData PR.
  • RC: is there hope your mapping code will get better?
  • CW: of course. :)
  • RC: so it’ll be possible to do in JS vs. native code?
  • CW: yes, roughly. Might even be faster. Amount of calls you make are about the same.
  • RC: in that case JG’s proposal seems fine to me.
  • JG: is Apple deliberating or abstaining?
  • MM: we’re vaguely supportive. Would like to have both for newcomers, but still willing to accept this. One vague concern, polyfill for this call we’re removing would be required to be integrated with an existing engine. Can’t just polyfill this call because it modifies the states of these objects. So you have to modify the whole engine but that’s probably OK.
  • CW: ok, universal agreement.
  • JG: MM can you please capture that in the PR?
  • MM: as a comment? sure.

Exposing Device Limits

  • DM: feedback we got from our early adopters is they have a texture atlas and want to know how big it can be. Need to know how big the max texture size can be.
  • CW: technically we can spec a max min.
  • CW: in #275, exposing compute shader width, also perf critical. Max texture size can give you a good enough limit. Need the other to run your compute shaders efficiently.
  • JG: my initial reaction is, of course we need the max texture size. Is everyone at 16K these days? Haven’t worked on new hardware that supports less than that. Generally, I’m in favor of not only exposing the useful limits, but also the renderer string, which we’ve done in the past for WebGL. Number of reasons. Main one: even fast release cadences can’t ship fast enough for apps to react. When large sites run into problems on hardware we don’t test on, they have to do same-day workaround turnaround. Only way to expose this in the past is the renderer string. The device it’s on, but not the driver version.
  • KR: I do think the driver version is in the renderer string.
  • DM: Vulkan limits
  • CW: 3 levels to the topic right now.
    • Essential limits
    • Limits “good enough” for everyone
    • Expose exactly what the chip, driver version, etc. are
  • JG: reason we lead with the renderer details is, if we agree we should expose the renderer string, no reason to not expose the detailed limits. I think we have enough argument for exposing the renderer string, so we can just expose all the details.
  • DM: I think there’s a case to be made for not exposing all the defined HW limits, which is portability. D3D12’s concept of “tiers” of support is useful. Also linked to the Vulkan pie chart above. Metal & Vulkan require us to support 8K textures.
  • JG: ah, there are 32K machines.
  • MM: think we should have different policies for different limits. Texture size could maybe be hardcoded to 4K. Threads per threadgroup, can’t. Think we should have different strategies for different limits.
  • JG: is this for simplicity’s or privacy’s sake?
  • MM: both.
  • JG: for privacy sake to hold weight then you mustn’t be able to derive this information from elsewhere.
  • MM: not sure we should talk about renderer string now.
  • JG: if we have a quick discussion about it then we could skip the whole discussion.
  • DJ: we turned WebGL’s renderer string off in WebKit due to requests from security and privacy people both internal and external. There hasn’t been any fallout.
  • CW: that’s why I think the renderer string discussion is hard.
  • JG: I’m interested in doing feature level type discussions. Don’t want to argue about which limits we should or shouldn’t expose if the renderer string discussion can supersede it.
  • DJ: I think it’s easier to argue exposing individual limits than the renderer string.
  • JG: there’s prior art.
  • CW: do we expose max texture size, or define 8K? Then the only limits could be e.g. max bindgroup size and compute shader width.
  • JG: what’s the benefit for reducing max texture size?
  • CW: portability. You say 8K is present everywhere.
  • JG: ~20% of devices support 32K.
  • CW: does anyone use it? Apps have to opt in to the limit.
  • CW: agreement was that app would have to opt into increased limits even after MVP. Would have base WebGPU version that works everywhere.
  • JG: then our max texture size would have to be 8K, which is a small minority of devices. 97% can support that. Maybe say 16K, and 8K devices aren’t supported.
  • DM: ARM devices don’t like 16K. On Metal, most ARM devices don’t support 16K. Is Apple fine with 8K? There are some devices with only 4K.
  • MM: we’d be more comfortable with 4K.
  • KN: 4K is iOS 8 only.
  • CW: this is one limit we’re talking about, but DM wanted to discuss this more generally.
  • JG: we can talk about this but we’d have to explain why WebGL is wrong.
  • CW: WebGL’s wrong because it’s not opt-in. You write an app on your machine, but because you automatically got the 64K max texture size, your app breaks on another machine.
  • JG: right. I meant about the renderer string.
  • CW: the hardware details are a lot of bits for fingerprinting.
  • JG: if we ship WebGPU without this, people will load both WebGPU and WebGL and query WebGL for the parameters and renderer string.
  • MM: we mitigated system fonts in WebKit. That’s one example of a strategy of reducing fingerprinting. We’re not giving up.
  • JG: I’m talking specifically about renderer string, was one of the last holdouts for exposing this in WebGL, so it’s ironic I’m pushing for exposing it in this WG / CG.
  • CW: need to talk with our privacy folks about this.
  • JG: I’d be more compelled if there weren’t prior art, and if there were more examples than WebKit removing this info.
  • CW: we should take an AI, talk with our respective privacy folks, and come to the F2F. WebGL’s not good prior art because it exposed OpenGL ES 2.0.
  • KR: WebGL obfuscated the renderer string from day 1, but exposed it because of application needs.
  • DJ: I think exposing the renderer string 4-5 years ago because there was more really problematic hardware back then. Think it’s a tradeoff between privacy problems and delivering WebGL content.
  • CW: action items: talk with privacy folks, see what they think, talk about it at the F2F. Do we have the same needs as WebGL when it came out? Will we have just as many bugs, or will it be better? Apple’s position is a bit better because they have more control of the hardware. More difficult on Chrome.
  • DJ: might be worth for Google folks talking with Maps folks. Last time I talked with them, they said they didn’t necessarily need it for Apple platforms, but older Windows machines.
  • KR: we’d really need to circle around with a lot of high-end WebGL apps to find out whether they’d break if we removed the renderer string.
  • DJ: would be difficult for us to ship the renderer string in Apple’s WebGPU given i just had to take it out of WebGL.
  • JG: understood.

Agenda for the F2F.

  • WIP agenda for the F2F
  • DJ: was pressed for creation of a WG. I drafted a charter, I think. They want to bring it up at a workshop on games in June. Would be nice if our CG knew what we want then.
  • AI: Talk to privacy folks about fingerprinting and the renderer string.
  • CW: mentioned various items around mutability, reusability, etc. See agenda.
  • CW: DM I’ll make sure there’s an agenda that will last 2 days. Would be good to have peoples’ priorities.

Agenda for next meeting

  • CW: should we skip this meeting?
  • JG: why don’t we schedule it, and if it’s short, it’s short
  • KR: agree.
  • CW: ok. next meeting, design agenda for F2F.
  • JG: Early proposals too.
Clone this wiki locally