Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

grorg
Copy link
Contributor

@grorg grorg commented Feb 7, 2019

Closes #164.

@grorg
Copy link
Contributor Author

grorg commented Feb 7, 2019

Notes:

  • includes -srgb versions
  • does not include extended range formats
  • does not include 16 bit packed since they are not available on all platforms
  • same with 32 bit packed (although maybe they should be there)

@grorg grorg requested a review from Kangz February 7, 2019 22:34
@litherum
Copy link
Contributor

litherum commented Feb 7, 2019

@grorg
Copy link
Contributor Author

grorg commented Feb 7, 2019

One format that seems to be supported "everywhere" is r10g10b10a2.

Should that be added? I guess so.

@Kangz
Copy link
Contributor

Kangz commented Feb 8, 2019

Thanks for contributing this! The naming convention looks great. We don't need to investigate portability of formats just yet be we could include RGB10A2 and RGB565 just as examples of how packed formats are named.

Also could the texture naming convention comment show how compressed formats would be named?

Copy link
Contributor

@kvark kvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!
Looks good for the most part, noted a few suggestions

"d32-float-s8-uint"
// TODO other formats
/* Normal 8 bit formats */
"a8unorm",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: this one isn't supported by Vulkan

Copy link

@magcius magcius Feb 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory it is if you use component swizzling in the image view

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for this particular case we could emulate the format. This is only possible since A8 behaves like R8 for all scenarios where an image view is not involved.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should remove it. Sorry I didn't notice this before.

We can always add it back later if we think it's worth it.

"r8g8b8a8-unorm",
"r8g8b8a8-uint",
"b8g8r8a8-unorm",
"d32-float-s8-uint"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be good to have some depth (+-stencil) formats as well

"char2",
"char3",
"char4",
"ucharnorm",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

merging words together here doesn't look particularly good
maybe we can have uchar1norm instead?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bikeshedding, but I don't like how the "u" and "norm" are separated either.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the "norm" used in vertex formats doesn't even match the texture format conventions, where only "unorm" and "snorm" are allowed. OTOH, I don't feel like bikeshedding too much...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(same with "int" "short" "char" - above they would be "sint" "sshort" "schar", which are names I definitely don't love. Plus "int" especially has a long history of having variable size....)

/* Normal 128 bit formats */
"rgba32uint",
"rgba32sint",
"rgba32float",
Copy link

@magcius magcius Feb 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there no BGRA, ARGB, or ABGR texture types? Are these actually RGBA32 (in that they are one 32-bit word which is host-endianness-specific?), or are they R8G8B8A8? Does it matter since POWER is basically dead anyway?

@grorg grorg merged commit bce24a2 into gpuweb:master Feb 9, 2019
@grorg grorg deleted the vertex-texture-formats branch February 9, 2019 20:35
JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Feb 10, 2019
* Provide texture and vertex format types

Closes gpuweb#164.
@Kangz
Copy link
Contributor

Kangz commented Feb 11, 2019

This was still missing depth stencil formats but we can infer the naming conventions from what is there.

JusSn pushed a commit to JusSn/gpuweb that referenced this pull request Mar 26, 2019
* Provide texture and vertex format types

Closes gpuweb#164.
@jespertheend
Copy link
Contributor

jespertheend commented Dec 9, 2020

Is there a reason for using char, short and half? Maybe I'm misunderstanding what these formats represent, but using a similar format to TypedArrays such as uint8, uint16, float16 and float32 seems more logical to me.

edit: hmm now that I think about it, that would result in something like uint82 for a 2 component type, which is probably not ideal. Though I'm still a bit confused by what char and short mean exactly. The current spec for int says signed 32-bit integer value whereas for char it says signed 8-bit value. Does this mean it is also an integer?

@kainino0x
Copy link
Contributor

I think that's exactly it, we didn't come up with a clearer way of expressing e.g. vec2<uint16>. But we probably could, if we really don't like char/short. We agreed on those because the meaning is fairly clear even though they don't match a whole lot else.

IIRC some API(s) merge vertex and texture formats so end up with things like rg16uint/rg16unorm vertex formats. We chose to specify the number of components for vertex formats, but the rgba components for texture formats. That also isn't entirely necessary. rg16uint/rg16unorm or 2x16uint/2x16unorm or uint16x2/unorm16x2 could work.

Does this mean it is also an integer?

yes, they're supposed to be integers if they don't say "norm". Reason it's worded that way is there are also the normalized versions which don't represent integers.


I also noticed we have this bit of text that seems to be obsolete:

If no number of values is given in the name, a single value is provided. If the format has the -bgra suffix, it means the values are arranged as blue, green, red and alpha values.

as there are no vertex formats with bgra.

@kainino0x
Copy link
Contributor

fwiw I think the main reason we ended up with the current naming is it's similar to what Metal uses.

@jespertheend
Copy link
Contributor

Oh I like uint16x2. Maybe it's because I haven't worked with low level programming languages a whole lot. But I was a bit confused by the names and had to go over what each of them meant in my head. I think specifying the bits in the name would help with that.

Reason it's worded that way is there are also the normalized versions which don't represent integers

Ah that makes sense. I suppose there is no normalized version for 32 bit integers because of hardware limits? Or is this list incomplete?

I also noticed we have this bit of text that seems to be obsolete

Ah cool, I was wondering about that.

@kainino0x
Copy link
Contributor

I suppose there is no normalized version for 32 bit integers because of hardware limits?

I believe that's the reason, yeah.

@kainino0x
Copy link
Contributor

editors resolution: open a PR to rename these to match texture formats, including the rgba part.
Rationale: while textures are often colors and vertex data is often not, the rgba naming corresponds with the .rgba swizzling of the vec datatypes as fed into the shaders. And it's just more consistent.

I'll also fix that obsolete text above.

kainino0x added a commit to kainino0x/gpuweb that referenced this pull request Dec 21, 2020
kainino0x added a commit to kainino0x/gpuweb that referenced this pull request Dec 21, 2020
kvark pushed a commit that referenced this pull request Feb 16, 2021
* Rename GPUVertexFormat members to match GPUTextureFormat

See recent discussion on #206

* try out some new names, not sold on them

* less is more

* Remove stale line

* I deleted the wrong thing...

* update bikeshed to try to fix build?

* upgrade better

* try --skip-manifest

* add a dry run with line numbers for errors

* temporarily enable (buggy) --line-numbers

* undo

* fix merge
@kainino0x kainino0x mentioned this pull request Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants