I like this but we don't have consensus here yet.

Proposal from @toji in meeting: Consider having these match the vec types in WGSL (for both vertex and texture), somehow, instead.

Problem I just thought of with this is we have to add something to describe the notions that are not expressed in WGSL:

• BGRA vs RGBA (texture formats only)
• sRGB (texture formats only)
• unorm vs snorm vs float (vertex and texture formats)
• number of bits per component (vertex and texture formats) - note that, for vertex data and texture sampling, (I think) all values come in as 32-bit even if the texture/vertex format is <32bit/channel and the shader has features enable to support <32bit types

Point I expressed on the call: both D3D (DXGI_Format) and Vulkan (VkFormat) use the same enums for vertex and texture types. Only Metal uses different types. Therefore, I don't believe there is going to be any confusion about the colors and whatnot.

Because of prior art I have a relatively strong preference to reuse pixel formats, and also because of prior art I don't think this will be a major source of confusion for people. People are pretty good at analogies!

IMHO this change isn't super necessary as the vertex formats work well as is and adding semantics with color names doesn't make things more understandable. Color channels make sense for textures because of all the special cases and the opaque-layout, but the vertex buffers are just linear memory.

We're basically churning names because we can, not because we have to. Given our timeline I think we should have an increased bar for breaking API changes so we can get to a v1 in finite time.

We're basically churning names because we can, not because we have to. Given our timeline I think we should have an increased bar for breaking API changes so we can get to a v1 in finite time.

Oh wow, hold on. This is the time to do breaking changes, why would we want to increase the bar for it now?

The names are inconsistent and confusing to some extent. They increase the API complexity for no reason, we should fix em.

Oh wow, hold on. This is the time to do breaking changes, why would we want to increase the bar for it now?

As we're getting closer to a v1, it's natural that the bar should increase and bikeshedding decrease. IMHO this change is at most a very minor improvement (or even not an improvement at all) so it's the type of bikeshedding we should stop doing very soon.

I think the core question is whether this is a non-negligible improvement or not. I think it's worth the change. I'm not sure whether we should do this or something like 4x16uint as discussed prior on #206, to address:

Color channels make sense for textures because of all the special cases and the opaque-layout, but the vertex buffers are just linear memory.

It still matches nicely with the texture formats, just replacing rgba with 4x. OTOH it makes the "16uint" look really weird in a way that looks okay for texture formats. Maybe if I were renaming everything I would consider uint16x4 and uint16rgba or something?

Fwiw I prefer the uint16x4 and uint16rgba variants. But really my main concern lies in char, short and half being too ambiguous, which this PR solves already.

We talked about this with @kvark on Monday and one reason to make both vertex and texture format enums match would be that it makes it clear that the layout is the same when fetching vertex data and when doing copies from buffers to textures. I'm now neutral on this change.

But really my main concern lies in char, short and half being too ambiguous, which this PR solves already.

Agreed. I actually don't think they're strictly speaking ambiguous - these days they have well defined meanings - and that's why I was okay with these names when we first landed it. But I consider the char and short names to be "evasive", that is, avoiding trying to specify the size (as they were when C was invented) (half is brief but otherwise unambiguous, I think). Everywhere else in the spec we try pretty hard to spell things out so you need less ambient knowledge to read code.

I really don't like this. I don't think many people are confused by the fact that vertex data uses different type names from texture formats.

Also, vertex data is almost always going to have a position attribute. It doesn't make sense that that should be an rg32float or rgb32float or rgba32float. It's not texture data. floatN is a much better description of the types of things people will store in these structures.

I suggest we put a table in the spec explaining that e.g. "float4" is comparable to "rgba32float".

If we can't use rgba32float for both, I might rather have xyzw32float. (and rgba32float) None of these are wholly satisfying to me.

I guess I poorly explained my goal - it's really not to make the names the same. I agree I don't think that is really a source of confusion. My goal is to make them more consistent with one another - in particular get rid of these outlying char/short/int/float/half terms which we don't use anywhere else - e.g. here int means int32 whereas in other places it is always followed by a size. I would like to make the component types look similar between the two enums.

My current thought is that flipping things around to make uint16x4 and uint16rgba is the most consistent.

That sounds like an easier stepping stone to get consensus for.

Pushed a commit trying out some new names, but I'm not sold on them at all. But they give something to contemplate.

The new names seem ok for vertex formats but look completely alien for texture formats. It's weird to move from RGB nomenclature for texture as everyone is super used to these names.

It's falling apart on texture formats :) But on vertex formats - it's definitely an improvement, since it addresses the inconsistency of naming by using the same "unorm" and the bitcount semantic. @kainino0x could we get the texture formats back, and proceed with only the vertex format changes?

One thing to consider before we land on a change is how would we represent vertex formats that aren't so simple? For example, Metal has the following:

• MTLVertexFormatInt1010102Normalized. "snorm10-10-10-2"?
• MTLVertexFormatUInt1010102Normalized. "unorm10-10-10-2"?
• MTLVertexFormatUChar4Normalized_BGRA. "unorm8x4-bgra"? "unorm8bgra"? "bgra8unorm"?

D3D12 also has optional 5-6-5 and 5-6-5-1 vertex formats.

Vulkan also allows VK_FORMAT_A8B8G8R8_{U,S}{INT,NORM}_PACK32. (Admittedly I have no clue how this is different from R8G8B8A8 though. Maybe the bits are reversed?)

Another question is whether the order of parts of the name should match the texture formats. E.g. instead of "unorm8x4", "4x8unorm" (to match "rgba8unorm"). I think that's kind of weird though, and not that necessary.

I don't really have an opinion whether to take this PR or not, but uint16x1 should really be uint16. x1 seems like it is forcing unnecessary consistency.

I disagree actually. Imagine code that says:
{ format: "uint32", offset: 0, shaderLocation: 0 }.
I think this could leave a reader wondering, where the heck is the number of components specified?

They hover over the parameter, jump to the enum location and see that there are the x2 x3 x4 variants. The x1 seems more confusing because the users will wonder if there's a vec1<u32> in WGSL or stuff like that.

I don't know that I'm super comfortable leaning on IDE features to supply API readability. Modern editors are pretty amazing at it but JS is a notoriously finicky language to autocomplete in the best of situations and I find that frequently built-in APIs like this can lag in editor support.

I've moved from "supportive" to "apathetic" regarding dropping the x1 postfixes because of Kai's comment. You could probably alleviate some of that concern by changing the key to something like layout instead of format, but I don't know that I want to bikeshed that name in addition to the formats themselves.

So we have approvals from Google, Mozilla, and Apple now. Can we just proceed without waiting another week for a call?

So we have approvals from Google, Mozilla, and Apple now. Can we just proceed without waiting another week for a call?

Yes

@kvark what's your opinion about x1?

@kainino0x no strong opinion. Arguments from both sides are reasonable, and it only affects 3 formats anyway.

Last meeting we asked people to chime in if they had concerns (apart from the x1) and noone did, so we can merge this and open a PR to discuss the x1 removal?

Yep, let's not keep this floating any longer.

Filed #1434 to follow-up