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

Rostislav Pehlivanov atomnuker at gmail.com
Sun Apr 22 19:21:52 EEST 2018


On 22 April 2018 at 12:46, Mark Thompson <sw at jkqxz.net> wrote:

> 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.)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Something's weird:


More information about the ffmpeg-devel mailing list