Skip to content

Minutes 2019 10 14

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

GPU Web 2019-10-14

Chair: Corentin

Scribe: Ken / Austin

Location: Google Meet

TL;DR

  • Default for bind group layouts #446
    • General agreement on the direction for proposal 2.
    • Both WSL and SPIR-V can deduce the bind group layout from shader source.
    • AI: CW to make a spec PR.
  • Error codes #464
    • Concern that we shouldn’t constrain the validation order. Can be done via spec language that doesn’t require an order of validation in implementations.
    • Suggestion that we could have a generic error code and ultra-specific error codes. CTS would accept both.
    • Brainstorm of different ideas: error codes as extension, using the reporting API, etc.
      • Shouldn’t break the shadertoy usecase.

Tentative agenda

  • Issue workflow
  • setSubData or alternatives #418
  • Error codes #464
  • Defaults for bind group layouts #446
  • <YOUR TOPIC HERE>
  • PR burndown
  • Agenda for next meeting

Attendance

  • Apple
    • Dean Jackson
    • Justin Fan
    • Myles C. Maxfield
  • Google
    • Austin Eng
    • Corentin Wallez
    • Kai Ninomiya
    • Ken Russell
  • Intel
    • Yunchao He
  • Microsoft
    • Damyan Pepper
    • Rafael Cintron
  • Mozilla
    • Jeff Gilbert
  • Mehmet Oguz Derin
  • Timo de Kort

Issue workflow

  • KN: we have a spec editors’ call later today. Would like to have that meeting before discussing this here.

Defaults for bind group layouts #446

  • CW: at F2F, talked about first proposal. Both pipelines and bindgroups have implicit bind group layouts.
    • Second proposal: bindgroups have implicit pipeline layout, can get layouts from that pipeline via .getBindGroupLayouts.
    • One open q: how does this work with remoting impls that don’t have access to actual bind group objects. Also, asking several times, do you get the same object? More questions.
  • JG: we’ll need to spec those. Don’t know whether they block the overall proposal.
  • CW: agree, it’s just an open q. Also: we deduce the layouts from the pipeline (?). Is that achievable with every shading language we care about?
  • JG: I think the idea is very useful.
  • RC: do we still end up deducing what you’re going to use the thing for, and are there performance ramifications associated with that?
  • CW: deducing may or may not have perf implications. Deduce bind group layout has all shader visibility stages set, could make it tied to the shaders using the binding in the pipeline. No performance concern there. If you use dynamic buffer offsets you have to do everything yourself.
  • KN: is it possible to use the same binding point once with only vertex, and once with only fragment?
  • CW: no.
  • KN: then we can tie it to how it’s actually used.
  • RC: why do you have to do everything yourself with dynamic offsets?
  • CW: deduced bind group layout has dynamic offsets. Can’t deduce that from the shader.
  • MM: sounds fine. Believe it is possible to create a pipeline layout from WSL shader.
  • CW: looking as WSL seems to be the case. Any problem deducing component type and texture dimension from WSL shader?
  • MM: I’d have to look. Jeff seems right, the general direction seems good.
  • KN: think if WSL isn’t compatible then we should make it.
  • JG: think it has to be. Couldn’t start with WSL and target Vulkan.
  • MM: couple months ago Damien suggested to make WSL’s binding points to be not backward compatible with HLSL.
  • CW: technically, could deduce info in bind group layout to output correct dimensionality / format in shader. Every shading language that’s transpilation target for WebGPU does the same thing.
  • CW: any opinions about the actual returned objects? Duplicated?
  • KN: my opinion: if you ask for it multiple times you should get the same one, but not the one you passed in originally. My mind could be changed about that.
  • CW: I think returning the same one is OK. Also OK to not de-duplicate bind group layouts across pipelines. If you pass BGL -> PL -> pipeline creation, do you get the same one?
  • KN: maybe it should be a different object each time. Not sure.
  • RC: possible to retrieve objects that were deduced? If not, who cares?
  • CW: proposal is to get the objects that were deduced. Need to know if it’s deduped or not.
  • CW: I’ll make a pull request with spec text and we can discuss it there.
  • AE: can we name the function getDefaultBindGroupLayout or similar?
  • JG: because we have createDefaultView?
  • CW: actually createView with no descriptor.
  • KN: if you pass in explicit bind group layout can you get that?
  • CW: yes.
  • MM: and if you pass in an explicit one, and you ask for one, does it give you the same one you passed in?
  • CW: good question. I’ll make a PR saying it returns the same one.
  • MM think it should be pretty easy to make it do that.
  • KN: the question is whether we make the impl hold on to that via reference.
  • MM: (didn’t capture this)
  • AE: if you drop the reference can you even see if it was GC’d?
  • KN: yes, expando properties can be lost. It’s an opaque object, let me think about it more.

Error codes #464

  • CW: Francois has ported all Dawn validation tests to the CTS. Several places where had to be extra careful of not testing an error that was the wrong one, or not having two errors so we knew if we had the right one. Thinking about adding specific error codes for each failure point in the spec. Then we can test that we check the right error code. Second, implementations will give varying error messages. Chrome might say “buffer not big enough” and Firefox and Safari might say something different. Might overconstrain impl that has a smarter way to do error checks which doesn’t check every specific case. Error codes force you do determine exactly the error that occurred.
  • CW: there’s precedent for this in Vulkan valid usage rules; also have a unique error code generated somehow. Useful for Vulkan validation errors.
  • MM: for functions that check ~100 different things, difficult to make sure the exact order is matched between impls. In WebGL there are some tests that ensure this exact error, rather than another one, is raised by glGetError.
  • CW: that’s something Jeff mentioned too. Let’s not overspecify the validation order. Would over-constrain impls. Better for spec to say, in this case, this error is put into the error scope, and popErrorScope can return any of these errors.
  • KN: definitely don’t want to constrain that. In WebGL we try to not have order dependence in the checks.
  • MM: when we write the CTS, will have to check just that there was a validation error, or that it was one of a collection? Or we write tests where we’re sure there’s exactly one thing wrong?
  • KN: when we write / review tests, make best attempt so tests only hit one error case. If there’s a test that’s wrong, if impl’s trying to make it pass, they might need to fix the test and not the browser.
  • MM: we should write that down somewhere.
  • JG: that we should fix the test?
  • CW: that WebGPU validation tests should only be testing one thing at a time.
  • JG: there will be some tests we have to write that test more than one thing at a time.
  • CW: then accept one of a set, or a sequence.
  • JG: one concern, some cases where in an impl, you might construct validation in a way that you don’t agree with the error codes you generate. Here’s the problem that’s wrong. Give them enough info to fix it on their own. Don’t want to have to constrain things, test specific thing that was wrong. Don’t want to micromanage error cases. “Stride wasn’t a multiple of 4”. “Buffer’s not long enough”. Might write validation in such a way that you report “input was not valid”. Instead of having to micromanage which error to generate, would be nice to say there was an error and we tried to give you reasonable error text. If you follow this, least micro-managey thing to do is only to require that you raised a general validation error.
  • KN: that’s how we ended up with the API we have now. That we wouldn’t add error codes.
  • JG: one of the things we found writing CTS is that we need feedback we’re testing what was intended. Lot of moving parts. Everyone working on WebGL has had to fix a test that wasn’t testing the right thing. Better to have earlier feedback. Can get some value back by embedding the error message from the validation error in the CTS output.
  • CW: that’s something we thought about. And how Francois’ writing the test. Problem is that FF doesn’t have an impl today. You’re not going to go through the CTS results and make sure you got the desired error. But it’s not enough.
  • JG: might not be enough, but I’m not going to go through all passing tests and make sure error messages were OK. But failures, I’ll look at why. Is it valuable?
  • KN: I don’t know.
  • JG: one potential proposal: have standardized validation text keys. Could have error codes but don’t like numbers. “This is the error validation type”, but don’t require it. Optionally could validate that while running CTS. Impls could then decide if they want 1 or many error codes.
  • CW: you’re suggesting, we can agree on some error codes, but impls may / may not use them? Should be valid to pass the CTS without checks for error codes?
  • JG: not sure that’s better. Don’t want to get into the game, did I generate the right error code. I don’t enjoy that aspect of WebGL development.
  • KN: everyone working on WebGL experienced that.
  • JG: in WebGL we held ourselves to the original specs. They had certain ideas about what errors were produced in certain situations. We can try to do it right this time.
  • KN: that’s appealing. If we say this is an unstable part of the API, and we can make changes to spec / CTS about how error codes are generated, would be good. I think it’s already a problem that we’d be exposing error codes to apps. Only really needed for the CTS. Making them unstable only makes that worse.
  • CW: they could be part of the error message. Impl-specific. Browsers can check the error message in CTS if they like. If we start doing this, and we start putting error codes in, even if it’s not part of the spec, people will begin relying on it.
  • MM: In general, much of the Web platform has, upon design, attempted to be unstable and ended up defacto having to be standardized.
  • KN: So we don’t expose this by default and make it an optional extension you turn on when running tests.
  • KR: Does no one see the value of consistency among the WebGL implementations and tests that can test every aspect? This helped really narrow down test cases for WebGL.
  • KN: My thought is that we have a WebGPU extension that we turn on, if available, and if available, we check the codes. And we wouldn’t ship that extension. It would be behind a flag for automated testing.
  • CW: If you do it with an extension that requires a flag, you lose the value of error codes being DuckDuckGoable
  • JG: Seems to be really uncommon for people in WebGL to look at the console output and still not know what’s wrong. I feel the messages we’re giving back are enough for people to read up on. I don’t think that spec-ing specific error codes will help people much more. The messages are generally strictly more actionable than codes.
  • KR: Seems to me the only way to achieve robust automated testing.
  • JG:
  • CW: In the spirit of making a comprehensive CTS, we need a mechanism to know that we’re testing the correct error. It could be a Chromium-specific extension, but that’s gross because it’s only Chromium.
  • JG: One thing Microsoft did with WebGL CI is to diff the outputs between test runs. If the output differed and the test still passed, that was a problem. etc.
  • RC: Yes, that was true. Especially helped when bringing new stuff up and diffing what changed. If we do this, then if certain implementations give more specific errors, we’ll need to allow larger sets of error codes.
  • JG: You could have a flag that no longer accepts a “generic” error code.
  • RC: I think “you’re doing something wrong” is wimpy, but I don’t want to mandate that every implementation have five or six errors for every entry.
  • CW: To give leeway, the CTS could say I expect this error code, or this generic code. Kind of both.
  • KN: I think it’s not too bad. If you want to know all the places you’re returning a generic error, you can search your code for that. Lets a browser easily find where to improve coverage.
  • JG: So sort of a strictly two-level thing. You have to generate an error, but it’s up to you if you want to provide an error key.
  • CW: I also have concerns if we have a lot a lot of strings and they’ll have to be in the source code.
  • MM: It doesn’t remove the string though. There’s still a message.
  • KN / CW: Still would prefer error codes.
  • KR: So how would we do this in the CTS and the spec?
  • CW: ex.) You can have a bad size. The spec says “check that the size is multiple of 4”: here’s the error code. The CTS would check and expect and the specific error code or “generic error”.
  • MM: Kind of wish we could discuss this type of topic with a user. I’d be interested to know if it’s common for applications to check which error occurred and take a different code path.
  • KN: These are all validation errors, so they should never need these at runtime.
  • MM: If that’s true, then maybe it’s only something in the Inspector and not part of the API.
  • JG: We really do want this for telemetry. One of the big problems with WebGL is you get INVALID_OPERATION, somewhere, and you don’t know why. We want to provide “sampler state was invalid” programmatically so a user could collate and send it back.
  • KN: Yes, this is really why we provide strings for error messages.
  • MM: If browsers have different strings, doesn’t that mess it up?
  • JG: Not if you collate by browser -- only a little bit.
  • KN: Really all you care about is if are there any validation errors you didn’t exist? and if it exists, then we need to look into how it got there.
  • MM: If these error messages are only for telemetry and machines won’t be reading them, then we don’t need an error code at all, we just need strings.
  • KN: The error code is for the CTS. This is the issue I have with error codes. They shouldn’t be user-facing -- only CTS-facing.
  • MM: Bad to add a facility only for a test quite.
  • JG: Most of these error messages, even if they have error codes, aren’t actionable in live code -- only for telemetry.
  • KR: Helps for debugging and getting the most detail as possible.
  • MM: Making a distinction between the console and the WebAPI.
  • KR: Even semi-detailed messages in WebGL led to a really robust conformance suite. So I like the idea of a unique error code per validation error in the spec.
  • MM: But we write the CTS. Why can’t we write a comprehensive CTS without exposing this code?
  • KR: But you only know whether it failed generically and not for a specific reason.
  • JG: I do want to mention that having multiple error codes in WebGL for the purposes of FF’s conformance attempts have been a net negative and not a net positive.
  • KR: Why is that?
  • JG: Because we don’t always test them the way the spec says we should test them. i.e. not testing enums first always. Sometimes we test pairs of enums. And we’ve had calls about this.
  • CW: Which is why all or generic is appealing.
  • CW: Getting back to MM’s argument. These messages are purely for developers or for the CTS. The application should never do anything except send it for telemetry or if the CTS, check for the value.
  • KN: That’s an interesting thing, because there actually is a way to do something only for telemetry. WebRecordingAPI? or something? For sending things to the server that aren’t visible to the application. That way we can take the message out completely and put it in the recording API.
  • CW: Can WPT make a fake recording API?
  • JG: Not excited about that. Seems like something middleware, spector.js, would want to surface usefully. It does open up the possibility of people writing divergent code, but it’s a pain to do so and the codes usually aren’t actionable.
  • MM: Whatever we do, we shouldn’t break the shadertoy usecase.
  • KR: And we should minimize the infrastructure web applications need to put up.
  • KR: If we exposed detailed error codes by a WebGPU extension, could that be mandatory? So the browsers have to implement the extensions so browsers can pass with full fidelity, but we wouldn’t normally expose it.
  • JG: I would prefer an option in the CTS.
  • KN: That way users can also run the CTS. But in our automated testing we use it.

PR Burndown

  • Didn’t get to this.
  • #469 - please take a look. Should be easy / non-controversial.
  • #470 - can just merge.
  • Please take a look at these.

Agenda for next meeting

  • AI: Francois: write down more about error codes.
  • Error codes.
  • setSubData and friends.
  • Some discussions about investigations Myles made - not many people commented on them, they’re still super valuable.
    • MM: I’m currently discussing internally about the ones most important. Expect to be ready to talk about one of them in the next month or so. Can have a general discussion about them earlier.
    • RC: which of your investigations should be in the core API?
    • MM: almost none could be implemented on Vulkan without extensions that are almost not-present on Vulkan. So almost all would have to be extensions.
    • CW: maybe next week’s agenda: socialize them to group but not discuss in detail?
  • Workflow
  • PR burndown
Clone this wiki locally