[FFmpeg-devel] [PATCH 3/8] lavu: add a Vulkan hwcontext

[Mark Thompson]

On 21/04/18 23:29, Carl Eugen Hoyos wrote:
> 2018-04-21 23:33 GMT+02:00, Rostislav Pehlivanov <atomnuker at gmail.com>:
>> On 21 April 2018 at 21:24, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>
>>> 2018-04-20 6:30 GMT+02:00, Rostislav Pehlivanov <atomnuker at gmail.com>:
>>>
>>>> +    [AV_PIX_FMT_P010]      =
>>>> VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16,
>>>
>>>> +    [AV_PIX_FMT_YUV420P10] =
>>>> VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16,
>>>
>>> I don't think both can be correct (unless "PACK16" has no meaning).
> 
>> They're both correct and work.
> 
> That's really strange...
> (Could this be a bug in the driver?)

Sounds like it must be a bug somewhere.

The Vulkan specification says:

"""
VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 specifies a unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, and a two-component, 32-bit BR plane 1 consisting of a 10-bit B component in the top 10 bits of the word in bytes 0..1, and a 10-bit R component in the top 10 bits of the word in bytes 2..3, the bottom 6 bits of each word set to 0.

VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16 specifies a unsigned normalized multi-planar format that has a 10-bit G component in the top 10 bits of each 16-bit word of plane 0, a 10-bit B component in the top 10 bits of each 16-bit word of plane 1, and a 10-bit R component in the top 10 bits of each 16-bit word of plane 2, with the bottom 6 bits of each word set to 0.
"""

Which I think makes it pretty clear that VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 is indeed P010 but VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16 isn't YUV420P10 because they pack the 10 bits at different ends of the 16-bit value.  If a driver is getting that wrong then it should be reported to the vendor.

I don't see any formats at all in the Vulkan specification which put the value at the low end of a containing word, but I might not be looking in the right place?

- Mark


(Vaguely related, because it made me look it up, it appears that the device will always match host-endianness:

After talking about the numeric types,
"""
The representation and endianness of these types on the host must match the representation and endianness of the same types on every physical device supported."
"""

I don't know what that actually means for little-endian graphics cards (e.g. AMD/Nvidia) in big-endian machines (e.g. POWER) - maybe Vulkan just doesn't support that, or maybe the driver can fix it up somehow - but we don't need to think about it at all.)