-
Notifications
You must be signed in to change notification settings - Fork 12
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
Confirm R16G16_S10_5 support #206
Comments
@fluppeteer please educate us whether this format is representable with DFD. |
Fixed-point sign-magnitude? Interesting. When I've got updates in place I'll try to make that clearer, since sign-magnitude is only really discussed under the floating point formats section. I'd write it as this: vendorId = 0 I think that's consistent with, e.g., table 103 in the KDFS. I'm rusty, so please check it looks sensible, don't just trust me. :-) In the above I'm assuming sign-magnitude, so "-1.0" is 0x8020". If it's fully-signed and "-1.0" is 0xFFE0, it's simpler. I'm not a huge fan of the VK_FORMAT_R16G16_S10_5_NV naming (especially since S is used for stencil in depth-stencil format), but it's going to have to be new no matter what is done, and I don't have a firm suggestion. There are already the INT formats that are effectively the same as NORM but with a different definition of "1.0", and this feels like a variant. |
Thanks Andrew. Looks okay to me except that bytesPlane0 should be 4. I'm not fond of the naming either. |
D'oh. Sorry, I realised I was thinking of it as a single-channel format and then corrected myself and updated the number of samples, but forgot to fix bytesPlane0. |
@lexaknyazev how can we confirm if this is sign-magnitude or fully signed? This format is already in the valid list in libktx's |
Asked internally. |
Thanks. While you are at it ask about the transfer function. |
Got an answer:
|
Thanks. In that case it's simpler, and each channel is just one 16-bit signed integer sample with a sample_upper of 32 and sample_lower of -32, I think. |
Thanks for the answers @lexaknyazev. I see no reason not to support this in KTX. The DFD is straightforward. If we do, no spec. change is needed, right? I don't think we'll want to support it in We'll need to update vk2dfd, dfd2vk, validate and info at a minimum. |
Right. Once DFD tools, |
I've opened KhronosGroup/KTX-Software#859 to complete support in KTX-Software. Closing this. |
@fluppeteer I'm working on adding support in KTX-Software. I have vk2dfd working and I'm now making dfd2vk work. This is based around using |
ping @fluppeteer. |
Sorry Mark. Yes, I think that works for fixed-point (basically anything other than "maximum number representable-ish = NORM, 1 = INT/SCALED"). If it's really a fixed-point format and doesn't have a separate signed bit, though, I ought to push back strongly on the Vulkan format naming, because it's hopelessly misleading; I'll try to raise an internal Khronos issue. |
The format has been renamed to |
It is KTX-Software that needs updating. Nothing to do here. I should have closed this when I merged KTX-Software PR #864. There is no mapping for this to formats in other APIs. @lexaknyazev are there any possible mappings? If so, please add then to |
I went to start the update and found that this name is not in the vk.xml in GitLab's |
It's there, in the main branch. |
Oh! Silly me. I didn't realize my workarea didn't have |
The name has been updated in KTX-Software PR #921. |
The
VK_NV_optical_flow
extension adds a newVK_FORMAT_R16G16_S10_5_NV
format:It should be checked whether it's representable with DFD.
The text was updated successfully, but these errors were encountered: