Small updates to match spec more closely #96
Conversation
Also adds the chain of types used by WGPUCompilationInfo (but still no way to actually use it), and makes them extensible.
| WGPUTextureFormat_Depth16unorm = 0x00000026, | ||
| WGPUTextureFormat_Depth24Plus = 0x00000027, | ||
| WGPUTextureFormat_Depth24PlusStencil8 = 0x00000028, | ||
| WGPUTextureFormat_Depth32Float = 0x00000029, |
There was a problem hiding this comment.
Should we leave any space in the texture format list? Or should we just add new ones to the end? I know holes can be bad for switch performance.
There was a problem hiding this comment.
I think we want all formats for v1 in a reasonable order then add at the end when new ones come up?
There was a problem hiding this comment.
technically speaking, we never match on a texture format in hot code where this difference would matter
There was a problem hiding this comment.
We might internally though. It would be annoying to have to translate to an internal packed enum (but probably ok if we want to block these out.
I was thinking 0x000 for core color formats, 0x100 for depth/stencil formats, 0x200 for extensions, or something like that. I wonder if compilers can handle a few blocks of values well.
There was a problem hiding this comment.
I have no real opinion here: texture formats should be relatively cold code in Dawn too since we cache a pointer to dawn_native::Format in the texture and could do the same in pipeline if we wanted.
| WGPUTextureFormat_Depth16unorm = 0x00000026, | ||
| WGPUTextureFormat_Depth24Plus = 0x00000027, | ||
| WGPUTextureFormat_Depth24PlusStencil8 = 0x00000028, | ||
| WGPUTextureFormat_Depth32Float = 0x00000029, |
There was a problem hiding this comment.
I think we want all formats for v1 in a reasonable order then add at the end when new ones come up?
| WGPUTextureFormat_Depth16unorm = 0x00000026, | ||
| WGPUTextureFormat_Depth24Plus = 0x00000027, | ||
| WGPUTextureFormat_Depth24PlusStencil8 = 0x00000028, | ||
| WGPUTextureFormat_Depth32Float = 0x00000029, |
There was a problem hiding this comment.
technically speaking, we never match on a texture format in hot code where this difference would matter
Also adds the chain of types used by WGPUCompilationInfo (but still no
way to actually use it), and makes them extensible. #82 #87