[Mesa-dev] [PATCH] st/va:Add support for indirect manner by returning VA_STATUS_ERROR_OPERATION_FAILED
Based on VA Spec,DeriveImage() returns VA_STATUS_ERROR_OPERATION_FAILED if driver dont have support for internal surface formats.Currently vaDeriveImage() failed for non-contiguous planes and operation failed error string is required to support indirect manner i.e. vaCreateImage()+vaPutImage() incase vaDeriveImage() failed with VA_STATUS_ERROR_OPERATION_FAILED. This patch will notify to the client as operation failed with proper error sting,so that client will fallback to vaCreateImage()+vaPutImage(). v2: updated commit message based on VA spec. Signed-off-by: suresh guttula --- src/gallium/state_trackers/va/image.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/gallium/state_trackers/va/image.c b/src/gallium/state_trackers/va/image.c index 807fc83..f7e0db0 100644 --- a/src/gallium/state_trackers/va/image.c +++ b/src/gallium/state_trackers/va/image.c @@ -212,9 +212,12 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image) surf = handle_table_get(drv->htab, surface); - if (!surf || !surf->buffer || surf->buffer->interlaced) + if (!surf || !surf->buffer) return VA_STATUS_ERROR_INVALID_SURFACE; + if (surf->buffer->interlaced) + return VA_STATUS_ERROR_OPERATION_FAILED; + surfaces = surf->buffer->get_surfaces(surf->buffer); if (!surfaces || !surfaces[0]->texture) return VA_STATUS_ERROR_ALLOCATION_FAILED; @@ -261,7 +264,7 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image) default: /* VaDeriveImage is designed for contiguous planes. */ FREE(img); - return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT; + return VA_STATUS_ERROR_OPERATION_FAILED; } img_buf = CALLOC(1, sizeof(vlVaBuffer)); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/va:Add support for indirect manner by returning VA_STATUS_ERROR_OPERATION_FAILED
This patch will return VA_STATUS_ERROR_OPERATION_FAILED incase vaDeriveImage() failed for non-contiguous planes.This error string is required to support indirect manner i.e. vaCreateImage()+vaPutImage() incase vaDeriveImage() failed with VA_STATUS_ERROR_OPERATION_FAILED. Signed-off-by: suresh guttula --- src/gallium/state_trackers/va/image.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/gallium/state_trackers/va/image.c b/src/gallium/state_trackers/va/image.c index 807fc83..f7e0db0 100644 --- a/src/gallium/state_trackers/va/image.c +++ b/src/gallium/state_trackers/va/image.c @@ -212,9 +212,12 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image) surf = handle_table_get(drv->htab, surface); - if (!surf || !surf->buffer || surf->buffer->interlaced) + if (!surf || !surf->buffer) return VA_STATUS_ERROR_INVALID_SURFACE; + if (surf->buffer->interlaced) + return VA_STATUS_ERROR_OPERATION_FAILED; + surfaces = surf->buffer->get_surfaces(surf->buffer); if (!surfaces || !surfaces[0]->texture) return VA_STATUS_ERROR_ALLOCATION_FAILED; @@ -261,7 +264,7 @@ vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image) default: /* VaDeriveImage is designed for contiguous planes. */ FREE(img); - return VA_STATUS_ERROR_INVALID_IMAGE_FORMAT; + return VA_STATUS_ERROR_OPERATION_FAILED; } img_buf = CALLOC(1, sizeof(vlVaBuffer)); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
While calling ucopy* functions to copy data to image ,it passes box.width which is calculated from surface . If the image buffer created for image dimensions width=40 and u copy use surface width=48. Which is giving a wrong stride for dst buffer. Thanks, Suresh G Get Outlook for Android<https://aka.ms/ghei36> From: Ilia Mirkin Sent: Tuesday, October 2, 2018 7:53:09 AM To: Sharma, Deepak Cc: ML Mesa-dev; Guttula, Suresh Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16. Looking at vlVaGetImage, it looks like it just copies data into the texture -- I don't see how UVD is implicated in this. Perhaps the transfer's stride is being set wrong? Or maybe either u_copy_nv12_to_yv12 or util_copy_rect (or one of the functions they call) is having trouble? On Mon, Oct 1, 2018 at 10:17 PM Sharma, Deepak wrote: > > 16 was considering UVD. > > in vlVagetImage, the width,height passed to function is not used but rather > the surface width/height and that causes issue in this case,not sure how > driver will handle that ? > > > From: Ilia Mirkin > Sent: Monday, October 1, 2018 6:49 PM > To: Sharma, Deepak > Cc: ML Mesa-dev; Guttula, Suresh > Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16. > > On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak wrote: > > > > From: suresh guttula > > > > In case of decoding of resolution like 40x24, while allocating surface > > video buffer is always aligned with macroblock width/height which is 16. > > But when application tries to get data after decoding through vaCreateImage > > /vaGetImage, image width/height aligned with 2 and result a smaller image > > buffer which causes the memory stomping issue. > > Shouldn't the driver be allocating a larger backing texture instead? > Why 16 and not 8 or 32 or 4096? > > -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] auxiliary: use vl_drm_screen_create method for surfaceless
On 11 October 2017 at 07:13, Guttula, Suresh <suresh.gutt...@amd.com<mailto:suresh.gutt...@amd.com>> wrote: > HI, > >>- why do we need "surfaceless" support >ChromeOS supports surfacelsess and we need this va enablement for > surfaceless in chromium. Ack, that should have been part of the commit message. >>>I will update the commit message. >> - does upstream VAAPI has surfaceless platform > Yes. It uses headless support of VA-API for decoding. There's no VA_DISPLAY_SURFACELESS in libva [1]. Thus adding one here is _very_ confusing and misleading. >>>Sorry I understood wrongly the question, I thought you are asking about mesa-vaapi. In libva it is using drm path only. If I understood correctly , no need of any macro VA_DISPLAY_SURFACELESS in libva as there is no problem to use drm path for egl platform surfaceless. The problem exists in mesa side as the check is added to enable va based on platform. https://github.com/01org/libva/blob/master/va/va_backend.h#L39 >>>libva uses “VA_DISPLAY_DRM_RENDERNODES” in this case. In libva ,Chromium (Ozone) for egl surfaceless platform goes for drm display . https://cs.chromium.org/chromium/src/media/gpu/vaapi_wrapper.cc?rcl=e1a85cf02acf0b4ccaad6e37afcf41d1fd26ce24=1188 >> - why is the surfaceless implementation identical to the DRM one > If I understand your question correctly, In case of surfaceless platform > ,it uses headless support of VAAPI, which will use drm implementation. If I > miss something here please provide some more details on the question. > To put it otherwise: You're "adding" support for surfaceless for the sake of adding a name. There's no functional difference nor upstream (see the libva question above) demand for it. >>>The reason for adding "surfaceless" in mesa is the condition checks for platform "drm/wayland/x11" to enable va. But in case of chromium ,we build mesa with_egl_platforms=surfaceless and not mesa_gbm because chromium uses minigbm .So echo $platform is surfaceless, even it is using drm path, condition check fail because of platform type picked as surfaceless and va is not enabled. What is stopping you from using --with-platforms=drm ? because if we use with_platforms=drm, we need to enable mesa_gbm which is not required for chromium(with_egl_platforms=surfaceless). Thanks, Suresh G ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 2/2] auxiliary: use vl_drm_screen_create method for surfaceless
HI, >>- why do we need "surfaceless" support ChromeOS supports surfacelsess and we need this va enablement for surfaceless in chromium. >> - does upstream VAAPI has surfaceless platform Yes. It uses headless support of VA-API for decoding. - why is the surfaceless implementation identical to the DRM one If I understand your question correctly, In case of surfaceless platform ,it uses headless support of VAAPI, which will use drm implementation. If I miss something here please provide some more details on the question. Thanks, Suresh G -Original Message- From: Emil Velikov [mailto:emil.l.veli...@gmail.com] Sent: Tuesday, October 10, 2017 9:09 PM To: Guttula, Suresh <suresh.gutt...@amd.com> Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org>; Sharma, Deepak <deepak.sha...@amd.com>; Koenig, Christian <christian.koe...@amd.com>; ML mesa-stable <mesa-sta...@lists.freedesktop.org>; Emil Velikov <emil.veli...@collabora.com> Subject: Re: [Mesa-stable] [PATCH 2/2] auxiliary: use vl_drm_screen_create method for surfaceless Hi Suresh, On 10 October 2017 at 07:20, sguttula <suresh.gutt...@amd.com> wrote: > when display type is VA_DISPLAY_DRM_RENDERNODES and if drm screen > create method is not enabled then vscreen is NULL. To fix this > issue,this patch will enable > vl_drm_screen_create() for surfaceless platforms > Repeating some earlier questions: - why do we need "surfaceless" support - does upstream VAAPI has surfaceless platform - why is the surfaceless implementation identical to the DRM one Without any additional information, I think you should be using the drm platform. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
