[Mesa-dev] [PATCH 11/11] st/va: add config support for 10bit decoding
Christian König
deathsimple at vodafone.de
Thu Mar 9 14:08:28 UTC 2017
Am 09.03.2017 um 13:46 schrieb Mark Thompson:
> On 09/03/17 07:54, Christian König wrote:
>> Replaying here from the comment in your other mail as well:
>>> Um, libav* is querying the capabilities and finding that only 8-bit output is supported for Main10:
>> [SNIP]
>>> Unable to create config to test surface attributes: 14 (the requested RT Format is not supported)
>> [SNIP]
>>> So, it works because it decodes to 8-bit surfaces and then everything is the same as 8-bit video after that.
>> Mhm, I've tried with mpv and that is clearly using P010. I had to fix two bugs in the backend driver to avoid crashes when decoding to P010/P016.
> Odd, mpv now uses the libav* APIs to this, so I would have expected it to do the same thing. Oh well, it doesn't really matter - once the capabilities are exposed correctly then it will work for everyone that queries them properly.
I've figured out why that doesn't make a difference. The Config is the
setup for the decoder and there we actually don't need to know if we
setup 8bit or 10bit decoding. Only during the actual decode operation we
need to know that.
>
>> So it clearly uses P016 at least for mpv. What command do you use to get this output?
> I have a utility to dump all of the capabilities: <http://ixia.jkqxz.net/~mrt/vadumpcaps.c>.
>
> (I'm intending to clean this up and put it somewhere more proper at some point; haven't got round to it yet.)
Please push to make this part of vainfo, that is clearly something
needed badly for VA-API.
>>> This adds the 10-bit config support for postproc only - it needs to be there for decode as well.
>>>
>>> To clean the render target format stuff up a bit, I think it might be nicer with something like (on top of your patch, tested with avconv):
>> Ah, yes that makes sense. Any objections merging that into my original patch and adding your signed-of-by line?
> Sure, please do.
Done, new set on the mailing list.
I've dropped the VDPAU support since nobody seems to be interested in
that any more.
Any more comments or are we good to go with that?
Thanks,
Christian.
>
> Thanks,
>
> - Mark
>
>
>> Am 08.03.2017 um 22:36 schrieb Mark Thompson:
>>> On 08/03/17 21:32, Mark Thompson wrote:
>>>> On 08/03/17 12:29, Christian König wrote:
>>>>> From: Christian König <christian.koenig at amd.com>
>>>>>
>>>>> Advertise 10bpp support if the driver supports decoding to a P016 surface.
>>>>>
>>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>>> ---
>>>>> src/gallium/state_trackers/va/config.c | 15 +++++++++++++--
>>>>> src/gallium/state_trackers/va/va_private.h | 1 +
>>>>> 2 files changed, 14 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/src/gallium/state_trackers/va/config.c b/src/gallium/state_trackers/va/config.c
>>>>> index 15beb6c..167d606 100644
>>>>> --- a/src/gallium/state_trackers/va/config.c
>>>>> +++ b/src/gallium/state_trackers/va/config.c
>>>>> @@ -108,17 +108,24 @@ VAStatus
>>>>> vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoint,
>>>>> VAConfigAttrib *attrib_list, int num_attribs)
>>>>> {
>>>>> + struct pipe_screen *pscreen;
>>>>> int i;
>>>>> if (!ctx)
>>>>> return VA_STATUS_ERROR_INVALID_CONTEXT;
>>>>> + pscreen = VL_VA_PSCREEN(ctx);
>>>>> +
>>>>> for (i = 0; i < num_attribs; ++i) {
>>>>> unsigned int value;
>>>>> if (entrypoint == VAEntrypointVLD) {
>>>>> switch (attrib_list[i].type) {
>>>>> case VAConfigAttribRTFormat:
>>>>> value = VA_RT_FORMAT_YUV420;
>>>>> + if (pscreen->is_video_format_supported(pscreen, PIPE_FORMAT_P016,
>>>>> + ProfileToPipe(profile),
>>>>> + PIPE_VIDEO_ENTRYPOINT_BITSTREAM))
>>>>> + value |= VA_RT_FORMAT_YUV420_10BPP;
>>>>> break;
>>>>> default:
>>>>> value = VA_ATTRIB_NOT_SUPPORTED;
>>>>> @@ -146,6 +153,7 @@ vlVaGetConfigAttributes(VADriverContextP ctx, VAProfile profile, VAEntrypoint en
>>>>> switch (attrib_list[i].type) {
>>>>> case VAConfigAttribRTFormat:
>>>>> value = (VA_RT_FORMAT_YUV420 |
>>>>> + VA_RT_FORMAT_YUV420_10BPP |
>>>>> VA_RT_FORMAT_RGB32);
>>>>> break;
>>>>> default:
>>>>> @@ -187,7 +195,9 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>>> config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
>>>>> for (int i = 0; i < num_attribs; i++) {
>>>>> if (attrib_list[i].type == VAConfigAttribRTFormat) {
>>>>> - if (attrib_list[i].value & (VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32)) {
>>>>> + if (attrib_list[i].value & (VA_RT_FORMAT_YUV420 |
>>>>> + VA_RT_FORMAT_YUV420_10BPP |
>>>>> + VA_RT_FORMAT_RGB32)) {
>>>>> config->rt_format = attrib_list[i].value;
>>>>> } else {
>>>>> FREE(config);
>>>>> @@ -198,7 +208,8 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>>> /* Default value if not specified in the input attributes. */
>>>>> if (!config->rt_format)
>>>>> - config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
>>>>> + config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_YUV420_10BPP |
>>>>> + VA_RT_FORMAT_RGB32;
>>>>> mtx_lock(&drv->mutex);
>>>>> *config_id = handle_table_add(drv->htab, config);
>>>> This adds the 10-bit config support for postproc only - it needs to be there for decode as well.
>>>>
>>>> To clean the render target format stuff up a bit, I think it might be nicer with something like (on top of your patch, tested with avconv):
>>>>
>>>> diff --git a/src/gallium/state_trackers/va/config.c b/src/gallium/state_trackers/va/config.c
>>>> index 167d606de6..4551058967 100644
>>>> --- a/src/gallium/state_trackers/va/config.c
>>>> +++ b/src/gallium/state_trackers/va/config.c
>>>> @@ -177,6 +177,7 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>> vlVaConfig *config;
>>>> struct pipe_screen *pscreen;
>>>> enum pipe_video_profile p;
>>>> + unsigned int supported_rt_formats;
>>>> if (!ctx)
>>>> return VA_STATUS_ERROR_INVALID_CONTEXT;
>>>> @@ -193,11 +194,12 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>> if (profile == VAProfileNone && entrypoint == VAEntrypointVideoProc) {
>>>> config->entrypoint = VAEntrypointVideoProc;
>>>> config->profile = PIPE_VIDEO_PROFILE_UNKNOWN;
>>>> + supported_rt_formats = VA_RT_FORMAT_YUV420 |
>>>> + VA_RT_FORMAT_YUV420_10BPP |
>>>> + VA_RT_FORMAT_RGB32;
>>>> for (int i = 0; i < num_attribs; i++) {
>>>> if (attrib_list[i].type == VAConfigAttribRTFormat) {
>>>> - if (attrib_list[i].value & (VA_RT_FORMAT_YUV420 |
>>>> - VA_RT_FORMAT_YUV420_10BPP |
>>>> - VA_RT_FORMAT_RGB32)) {
>>>> + if (attrib_list[i].value & supported_rt_formats) {
>>>> config->rt_format = attrib_list[i].value;
>>>> } else {
>>>> FREE(config);
>>>> @@ -208,8 +210,7 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>> /* Default value if not specified in the input attributes. */
>>>> if (!config->rt_format)
>>>> - config->rt_format = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_YUV420_10BPP |
>>>> - VA_RT_FORMAT_RGB32;
>>>> + config->rt_format = supported_rt_formats;
>>>> mtx_lock(&drv->mutex);
>>>> *config_id = handle_table_add(drv->htab, config);
>>>> @@ -252,6 +253,9 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>> }
>>>> config->profile = p;
>>>> + supported_rt_formats = VA_RT_FORMAT_YUV420;
>>>> + if (p == PIPE_VIDEO_PROFILE_HEVC_MAIN_10)
>>>> + supported_rt_formats |= VA_RT_FORMAT_YUV420_10BPP;
>>>> for (int i = 0; i <num_attribs ; i++) {
>>>> if (attrib_list[i].type == VAConfigAttribRateControl) {
>>>> @@ -263,7 +267,7 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>> config->rc = PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE;
>>>> }
>>>> if (attrib_list[i].type == VAConfigAttribRTFormat) {
>>>> - if (attrib_list[i].value == VA_RT_FORMAT_YUV420) {
>>>> + if (attrib_list[i].value & supported_rt_formats) {
>>>> config->rt_format = attrib_list[i].value;
>>>> } else {
>>>> FREE(config);
>>>> @@ -274,7 +278,7 @@ vlVaCreateConfig(VADriverContextP ctx, VAProfile profile, VAEntrypoint entrypoin
>>>> /* Default value if not specified in the input attributes. */
>>>> if (!config->rt_format)
>>>> - config->rt_format = VA_RT_FORMAT_YUV420;
>>>> + config->rt_format = supported_rt_formats;
>>>> mtx_lock(&drv->mutex);
>>>> *config_id = handle_table_add(drv->htab, config);
>>>>
>>>>> diff --git a/src/gallium/state_trackers/va/va_private.h b/src/gallium/state_trackers/va/va_private.h
>>>>> index 7216aba4..9c32c08 100644
>>>>> --- a/src/gallium/state_trackers/va/va_private.h
>>>>> +++ b/src/gallium/state_trackers/va/va_private.h
>>>>> @@ -57,6 +57,7 @@ ChromaToPipe(int format)
>>>>> {
>>>>> switch (format) {
>>>>> case VA_RT_FORMAT_YUV420:
>>>>> + case VA_RT_FORMAT_YUV420_10BPP:
>>>>> return PIPE_VIDEO_CHROMA_FORMAT_420;
>>>>> case VA_RT_FORMAT_YUV422:
>>>>> return PIPE_VIDEO_CHROMA_FORMAT_422;
>>>>>
>>>> Also, postproc scale only seems partially working with this? With the change above decode is good, but adding a scale as well with something like:
>>>>
>>>> ./avconv -y -threads 1 -vaapi_device :0 -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf scale_vaapi=1280:720,hwdownload,format=p010 -c:v libx264 out.mp4
>>>>
>>>> gives scaled output with a correct luma plane, but the chroma is empty?
>>> (That was with this as well so it doesn't immediately barf on the >8-bit surfaces:
>>>
>>> diff --git a/src/gallium/state_trackers/va/picture.c b/src/gallium/state_trackers/va/picture.c
>>> index 62a68786c4..20fe75085b 100644
>>> --- a/src/gallium/state_trackers/va/picture.c
>>> +++ b/src/gallium/state_trackers/va/picture.c
>>> @@ -74,7 +74,8 @@ vlVaBeginPicture(VADriverContextP ctx, VAContextID context_id, VASurfaceID rende
>>> context->target->buffer_format != PIPE_FORMAT_R8G8B8A8_UNORM &&
>>> context->target->buffer_format != PIPE_FORMAT_B8G8R8X8_UNORM &&
>>> context->target->buffer_format != PIPE_FORMAT_R8G8B8X8_UNORM &&
>>> - context->target->buffer_format != PIPE_FORMAT_NV12)
>>> + context->target->buffer_format != PIPE_FORMAT_NV12 &&
>>> + context->target->buffer_format != PIPE_FORMAT_P016)
>>> return VA_STATUS_ERROR_UNIMPLEMENTED;
>>> return VA_STATUS_SUCCESS;
>>>
>>> )
>>
More information about the mesa-dev
mailing list