-
Notifications
You must be signed in to change notification settings - Fork 335
Provide texture and vertex format types #206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Notes:
|
One format that seems to be supported "everywhere" is r10g10b10a2. Should that be added? I guess so. |
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? |
There was a problem hiding this 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
design/sketch.webidl
Outdated
"d32-float-s8-uint" | ||
// TODO other formats | ||
/* Normal 8 bit formats */ | ||
"a8unorm", |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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?
* Provide texture and vertex format types Closes gpuweb#164.
This was still missing depth stencil formats but we can infer the naming conventions from what is there. |
* Provide texture and vertex format types Closes gpuweb#164.
Is there a reason for using edit: hmm now that I think about it, that would result in something like |
I think that's exactly it, we didn't come up with a clearer way of expressing e.g. IIRC some API(s) merge vertex and texture formats so end up with things like
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:
as there are no vertex formats with bgra. |
fwiw I think the main reason we ended up with the current naming is it's similar to what Metal uses. |
Oh I like
Ah that makes sense. I suppose there is no normalized version for 32 bit integers because of hardware limits? Or is this list incomplete?
Ah cool, I was wondering about that. |
I believe that's the reason, yeah. |
editors resolution: open a PR to rename these to match texture formats, including the I'll also fix that obsolete text above. |
See recent discussion on gpuweb#206
See recent discussion on gpuweb#206
* 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
Closes #164.