feat: add DXGI-to-VkFormat switch generation script - #235
Conversation
* Some consumers may need a specification-compliant (and much easier to integrate) auto-generated DXGI-to-VkFormat switch. E.g., DDS to KTX2 converters have to figure out the corresponding VkFormat of the input DDS DXGI format. Signed-off-by: Walid Chtioui <walid.chtioui.main@gmail.com>
|
|
* Some librarise map same DXGI enum value to custom enums with same names but only prefixed by some value (see tinydds.h for an example). This is disabled by default and is only a placeholder for convenience. Signed-off-by: Walid Chtioui <walid.chtioui.main@gmail.com>
* We assume that the first encountered DXGI-to-VkFormat conversion is the most suitable DXGI-to-VkFormat conversion. Without this check we will end up with multiple similar case statements on same DXGI enum values because 'formats.json' is used to map VkFormat to other formats and can, therefore, map to same DXGI value multiple times (e.g., DXGI_FORMAT_R8G8B8A8_UNORM) Signed-off-by: Walid Chtioui <walid.chtioui.main@gmail.com>
Signed-off-by: Walid Chtioui <walid.chtioui.main@gmail.com>
|
Looks good. Would be great to extend |
Signed-off-by: Walid Chtioui <walid.chtioui.main@gmail.com>
Signed-off-by: Walid Chtioui <walid.chtioui.main@gmail.com>
Done. By the way, generating DXGI->VkFormat mappings from reverse VkFormat->DXGI might not be ideal because multiple DXGI formats can (need to verify) map to the same VkFormat. E.g., see At the very least, we can be confident that the generated switches, even though they cover only a subset, are 100% correct and with no ambiguity. |
We must look into this but keep in mind that
|
3 participants
Some consumers may need a specification-compliant (and much easier to integrate) auto-generated DXGI-to-VkFormat switch. E.g., DDS to KTX2 converters have to figure out the corresponding VkFormat of the input DDS DXGI format.
Related: KhronosGroup/KTX-Software#1223