- From: Corentin Wallez <cwallez@google.com>
- Date: Tue, 5 Dec 2017 13:13:56 -0500
- To: public-gpu <public-gpu@w3.org>
- Message-ID: <CAGdfWNO1Bp3+RTRtAWkahtg+Tc5mS_m8+afGH4VqJT6ajjPKhQ@mail.gmail.com>
GPU Web 2017-11-29
Chair: Corentin
Scribe: Ken
Location: Google Hangout
Minutes from last meeting
<https://docs.google.com/document/d/1t6HBDJPxpRaEcEac1yK4KMcaoOaAPSV5Vgym-4Nf2NM>
TL;DR
-
Status updates:
-
Apple: Wrote positions papers about shading languages.
-
Google: First test passing on the Vulkan backend of NXT.
-
Mozilla: Progress on gfx-rs ll
-
Google’s discussion of the skeleton SPIR-V execution environment
<https://docs.google.com/document/d/12HItPcVy_uRpE22do9Aj-_aPA0XNLCbTBcIYA-UKvJ0/edit>
-
Additional WebGPU constraints can be added by an extra code transform
pass in toolchain. Done offline, or online and validated by the browser.
-
This is a pretty comprehensive skeleton modulo WebGPU features.
-
Discussion whether “robust acces” is enough or explicit behavior is
needed.
-
Apple’s position papers (#41 <https://github.com/gpuweb/gpuweb/issues/41>
#42 <https://github.com/gpuweb/gpuweb/issues/42> #43
<https://github.com/gpuweb/gpuweb/issues/43>)
-
#41
-
Consensus that should be a recommend high-level language
-
Consensus that this language should be HLSL or a derivative as
long as it has a spec.
-
#42
-
Discussion of language “dynamism”
-
Discussion of interoperability of high-level languages
-
Discussion of maintenance burden vs. developer accessibility of
HLSL vs. SPIR-V
Tentative agenda
-
Administrative stuff (if any)
-
Individual design and prototype status
-
Shading language
-
Agenda for next meeting
Attendance
-
Apple
-
Dean Jackson
-
Myles C. Maxfield
-
Theresa O'Connor
-
Google
-
Corentin Wallez
-
David Neto
-
John Kessenich
-
Kai Ninomiya
-
Ken Russell
-
Microsoft
-
Chas Boyd
-
Rafael Cintron
-
Mozilla
-
Dzmitry Malyshau
-
Jeff Gilbert
-
Markus Siglreithmaier
-
Yandex
-
Kirill Dmitrenko
-
Elviss Strazdiņš
-
Tyler Larson
Shading language
Google’s skeleton of what a "WebGPU execution environment for SPIR-V"
<https://docs.google.com/document/d/12HItPcVy_uRpE22do9Aj-_aPA0XNLCbTBcIYA-UKvJ0>
could be.
-
RC: to what extent will we have to modify programs that output SPIR-V to
conform to these constraints?
-
Will we need a “Secure SPIR-V” or “WebGPU” switch?
-
CW: yes but it would be a tiny change. Some of the behaviors undefined
in SPIR-V become defined now. Only 3 are listed in this documents.
-
JK: The way you trust this is via a validator, rather than a frontend
being in a WebGPU mode.
-
RC: the question about initializers for example.
-
JK: The compiler should just put these in.
-
CW: Any SPIR-V generated by any tool can be put through a validator
which will clean it up.
-
RC: so we’ll take any SPIR-V from any tool?
-
CW: when you’re an app developer producing SPIR-V offline, you’ll run it
with an extra optimization pass which resolves this undefined behavior.
-
JK: actually you can do it in multiple ways. Someone needs to put these
extra instructions in.
-
DJ: we would not accept any SPIR-V programs that have uninitialized
variables?
-
CW: yes, that would work. It would be another optimization pass or
transform to the SPIR-V program you’re using.
-
CB: so this component / validator...you could additionally have another
flag on your frontend compiler?
-
CW: yes.
-
MM: so everyone will have to recompile their shaders?
-
JK: or run it through a transform which fixes it up. Or decide that the
thing run on end users’ systems could fix it up while it loads it.
-
CB: whatever tool does this could warn early.
-
JK: think that what you want to warn about is using a capability that’s
not least common denominator, so it won’t be portable.
-
CW: that’s sort of an end user problem. Toolchain takes invalid SPIR-V
(due to these constraints) and makes it valid.
-
JG: how complete do you think this spec is? It’s not very many
restrictions.
-
CW: some of these constraints can be small or big. For example, which
builtins you can use. Appendix A of the Vulkan spec is pretty small though.
I don’t expect it to be huge.
-
DN: a lot will bleed over into what features are available in WebGPU;
this will impact the restrictions put on shaders.
-
CW: there are some variables created in the shader, and these need
initializers. There are other variables whose contents come from buffers
and the API.
-
CB: does this require runtime validation of addresses in the shader?
-
CW: on hardware which doesn’t support robust resource access, we
would need to clamp buffer dereferences, for example. Discussed here:
https://github.com/gpuweb/gpuweb/issues/33
-
For image texel fetches: these would probably always require
clamping, though (JG) this may have just been an omission from Vulkan’s
robust buffer access.
-
MM: haven’t come to a conclusion about whether robust buffer extensions
are sufficient.
-
CW: came to the conclusion they’re not.
-
JG: not strictly, but they’re a building block we can use.
-
CW: we didn’t agree we’d use the hardware robust buffer access, because
hardware can have one of many behaviors
-
MM: that’s what I’m talking about; don’t know the perf penalty of having
explicit behavior, so can’t decide which behavior to choose
-
CW: this can still be decided later, per the environment spec writeup.
Apple’s position papers:
-
https://github.com/gpuweb/gpuweb/issues/41
-
https://github.com/gpuweb/gpuweb/issues/42
-
https://github.com/gpuweb/gpuweb/issues/43
-
MM: Apple’s position: it should be possible to write in a human-readable
language, full stop.
-
CW: this is possible even if we choose SPIR-V, because compilers exist
-
MM: second issue: blessing a single language as the one that’s promoted
for teaching, marketing, etc.
-
Not a technical position. Just the language that the documentation is
written in, for example.
-
(#41) Apple believes there should be one dominant language, for a
couple of languages.
-
CW: we still don’t know what Secure HLSL means.
-
MM: apologies - we are writing a document on this and intended to
publish it but am a little behind. Will be out soon.
-
CW: we all probably agree that this chosen language should probably be
HLSL, HLSL++, Secure HLSL, or GLSL.
-
DJ: maybe should we start by blessing a single human readable
language?
-
JG: don’t think we should bless a single language, but understand
that everyone else thinks we should.
-
JG: think you can write the documentation in anything you want. We
provide a compile target.
-
CW: let’s talk about V1.
-
JG: it works fine in Vulkan; that ships with SPIR-V. People are starting
to ship SPIR-V for OpenGL too.
-
MM: don’t agree – every Vulkan example out there is written in GLSL.
-
JG: the build targets are SPIR-V.
-
JG: Vulkan doesn’t see the need to have a blessed higher-level language.
There are projects which support other higher-level languages. The compiler
tool chain takes care of this. The point is that you don’t need to bless a
single higher-level language.
-
DN: maybe the word “bless” is too vague here.
-
CW: maybe say: community, if you can, use this language.
-
CB: it’s at least a recommendation.
-
JG: what I disagree with is that the API should ingest anything but
SPIR-V
-
CB: that’s a different question that we’re talking about
-
JG: ok then
-
DN: think Secure HLSL might have good ergonomics based on what we saw in
Chicago.
-
DJ: it’ll be more documentation by example than a language spec.
-
DJ: changes since Chicago: the majority of HLSL programs are Secure
HLSL programs too.
-
CW: any objections to using Secure HLSL?
-
KN: one objection is that we’d have to build up the ecosystem around
Secure HLSL before we could move forward.
-
CB: aren’t the secure extensions additive?
-
MM: yes
-
KN: talking about tools, etc. Need to have robust tools that ingest
Secure HLSL before we can say the ecosystem is at V1.
-
Would prefer to not block on Secure HLSL until we know that it’ll be
done in time.
-
Given choice between HLSL and Secure HLSL, would like to bless HLSL
now, and once Secure HLSL is built out enough, we switch to using Secure
HLSL and start using the new features.
-
We can release documentation now, without waiting for a new ecosystem.
-
CW: to be clear: Google thinks the blessed language should be HLSL; it’s
what a majority of the shaders are written in. Concern that people in the
WebGL ecosystem will be confused because we switch from GLSL to HLSL. This
is just one drawback I’m thinking of.
-
DJ: the tools convert to SPIR-V anyway. No matter what we do, the WebGL
folks will have to do work.
-
KN: for every existing WebGL engine which already has a lot of GLSL
shaders, have to make sure there’s a good story for them to use those
shaders in WebGPU. Don’t want them to have to fork all of their shaders.
But I’m fine with that being shaderc and a WASM module. We should just
promise that these tools exist.
-
MM: yes, you’re right. There are many GLSL to HLSL compilers. Agree on
this point.
-
On distinction between HLSL and Secure HLSL: accepting HLSL now with
the understanding that we can upgrade to Secure HLSL later sounds OK.
-
JG: agree, as long as the “accept” is a recommendation and not what the
browser has to ingest.
-
DN: want HLSL to be a pinned down spec.
-
MM: we – for some value of we – are working on that.
-
CB: Microsoft’s working on this too.
-
MM: that pretty much resolves #41.
#42
-
Question of directly ingesting that language.
-
MM: there are multiple reasons that direct ingestion is valuable.
-
MM: making a website that wants to modify their shaders ship a compiler
costs both time and money
-
View-Source lets you modify the source live. If you can’t have human
readable sources then you definitely can’t do this
-
There was another point here which KR didn’t capture
-
DJ: does everyone agree with the assertion that you can convert between
HLSL / Secure HLSL / GLSL / SPIR-V?
-
JG: more or less. It’s often a lossy conversion.
-
DJ: yes, but we’ll have to do it on for example Apple’s platforms.
-
JG: functionally it’s not lossy but you might lose things like variable
and function names.
-
MM: there’s one meta thing: not arguing against ingesting other
languages also. It’s OK to have ingestion of another high level language
and also SPIR-V
-
JK: is this ingestion of a language by one tool or many tools?
-
There are some serious problems of high-level languages being
portable among multiple tools
-
JG: think this would be an ANGLE-like library that everyone uses
-
CW: everyone using the same library wouldn’t be a good idea. As I review
patches to ANGLE I see corner cases that are unspecified all the time.
-
JG: also don’t want a billion of these proliferating
-
DJ: maybe someone could express on the issue the negative reasons. The
assertion that, in general, intermediate languages are easier to process.
-
CW: there’s a bunch of stuff weird in this proposal.
-
Dynamism: some web pages need to compile things dynamically.
-
Size: but you can put an HLSL to SPIR-V compiler on your web page
itself and it won’t be that big.
-
Don’t these cancel each other out?
-
MM: the compiler’s big enough that you don’t want to send it over the
wire for each page load.
-
It’s not just ShaderToy. There are lots of examples of libraries that
snip shaders together.
-
CW: the SceneKit example: you probably want those shaders linked up
front. The fact that applications use text-based copy-pasting and defines,
etc. to produce their shaders is not how you do this in native apps.
-
MM: it’s possible to say that the way people write shaders today is bad.
-
KN: we know why people do this – it’s because the APIs for a very long
time only took GLSL (both WebGL and OpenGL without extensions). The reason
engines snip shaders together is because that’s the primitive.
-
JG: SPIR-V is concatenatable. You can concatenate the string version of
it and assemble it, too. One of my open questions: how much of this can you
claw back if you had to deal with these constraints?
-
DJ: if you only had Secure HLSL, would you be happy in the same sense?
-
JG: it would hide more things from you; that’s one concern. A nearby
proposal to this is if we only took in a high-level language. But you might
lose some of the explicit-ness.
-
MM: thought Kai gave the exact opposite argument a couple of weeks ago,
SPIR-V being high-level.
-
JK: SPIR-V is very explicit about what types can be combined to make
what type. HLSL is all over the place in terms of being able to take
various linear algebraic types and combine them. SPIR-V doesn’t have this
problem.
-
DJ: didn’t Jeff say that we want to be able to assemble SPIR-V?
-
JG: it’s not x86 assembly. You could extract something readable from it
even without debug symbols. Want to know how many points in this issue
would be satisfied by it.
-
MM: would lose comments and variable names
-
CW: you would not. SPIR-V has debug info.
-
CB: sounds like SPIR-V is pretty much a high level language. The other
aspect of it is that it has a detailed spec?
-
JG: and easy to interpret.
-
JK: it’s very precise. SSA form. No polymorphism. Much lower level
language than any language that has templates.
-
MM: being explicit isn’t the same as being precise.
-
JK: there are ambiguities in these high level languages.
-
CW: there are very few high-level languages with multiple interoperable
implementations: C/C++, Javascript, Python? They are much bigger than
Secure HLSL will be.
-
KR: want to ask MM about whether he thinks we should use HLSL
-
DJ: there are a huge number of advantages in higher-level languages.
SPIR-V is a lower level binary format that’s explicit. HLSL’s easier to
write and use. That’s the choice we’re making
-
CW: that’s not the decision we’re making. Want it to be (1)
interoperable (2) portable (3) reasonable cost for browsers to address
-
KR: HLSL doesn’t have a specification, it can’t be better specified than
something that has a tight specification like SPIR-V.
-
JK: it’s massively harder to interpret HLSL than SPIR-V
-
KD: the question is whether we’ll ingest HLSL or SPIR-V, it has nothing
to do with developer convenience. Developers will use HLSL/GLSL/Secure-HLSL
anyway.
-
JG: it’s a higher bar. we’re not choosing “today, we’ll ingest HLSL”.
When we ingest HLSL at the browser level we’re saying that we’ll support
this, forever, in its current form. Would be nice to not have that burden.
If we later decide we want to support Secure HLSL.
-
TOC: if we go SPIR-V or Secure HLSL here, the maintenance burden is
still forever
-
JG: the burden of handling SPIR-V is probably a quarter of the others.
Would be more reliable in the long run because the
-
TOC: we should prioritize the web developers’ time as opposed to the
browser developers’
-
JG: You can have both by making a library, you just don’t ship it as
part of the platform. It comes out of the browser cache.
-
JK: there are almost an infinite number of examples of expressions you
can form in HLSL. it’ll be impossible to enumerate them all.
-
KR: Not just theoretical, these weeks again we had crazy HLSL compiler
that was braking the HLSL compiler. Closed as won’t fix and Olli had to add
unused variable detection in ANGLE. This problem happens over and over
again. Max token length? Preprocessor?... All because WebGL use a text
based language.
-
JK: Sequencing points? What’s the order of side effects of parts of a
complex expression? And so forth.
-
In SPIR-V these questions don’t even exist. Add this to that, and
you’re done.
-
Can’t believe HLSL can be that tightly specified.
-
JG: Maybe a proposal: JG is interested in what a super-easy to write
HLSL language can be. Particularly interested in seeing this implemented on
top of SPIR-V. Don’t think this is at odds with our trek toward the MVP.
-
JG: would propose that interested parties do this – take HLSL or
Secure HLSL, produce SPIR-V, and once we are further along, we could
consider shipping the functionality of that library in the browser.
-
DJ: we might ship that in the browser. (Not to a stable version of
Safari.) Because of Apple’s position that we should make things easier for
developers. Would translate to Metal SL directly.
-
CB: how many implementations of SPIR-V are there now?
-
CW: as many as there of GPU vendors.
-
KN: they all have different hardware ISAs. They might be reusing LLVM or
parts of Khronos’ SPIR-V tools.
-
CW: they also don’t share code. If they all use LLVM they all have
different SPIR-V frontends.
Agenda for next meeting
Google to produce writeup for UMA and buffer mapping
MM: email Corentin with more topics
Received on Tuesday, 5 December 2017 18:14:44 UTC