[Mesa-dev] [PATCH 2/6] i965: Add a RGBX->RGBA fallback for glEGLImageTextureTarget2D()

[Daniel Stone]

Hi Chad,

On 6 June 2017 at 21:36, Chad Versace <chadversary at chromium.org> wrote:
> @@ -254,8 +255,22 @@ create_mt_for_dri_image(struct brw_context *brw,
>     struct gl_context *ctx = &brw->ctx;
>     struct intel_mipmap_tree *mt;
>     uint32_t draw_x, draw_y;
> +   mesa_format format = image->format;
> +
> +   if (!ctx->TextureFormatSupported[format]) {
> +      /* The texture storage paths in core Mesa detect if the driver does not
> +       * support the user-requested format, and then searches for a
> +       * fallback format. The DRIimage code bypasses core Mesa, though. So we
> +       * do the fallbacks here for important formats.
> +       *
> +       * We must support DRM_FOURCC_XBGR8888 textures because the Android
> +       * framework produces HAL_PIXEL_FORMAT_RGBX8888 winsys surfaces, which
> +       * the Chrome OS compositor consumes as dma_buf EGLImages.
> +       */
> +      format = _mesa_format_fallback_rgbx_to_rgba(format);
> +   }
>
> -   if (!ctx->TextureFormatSupported[image->format])
> +   if (!ctx->TextureFormatSupported[format])
>        return NULL;
>
>     /* Disable creation of the texture's aux buffers because the driver exposes
> @@ -263,7 +278,7 @@ create_mt_for_dri_image(struct brw_context *brw,
>      * buffer's content to the main buffer nor for invalidating the aux buffer's
>      * content.
>      */
> -   mt = intel_miptree_create_for_bo(brw, image->bo, image->format,
> +   mt = intel_miptree_create_for_bo(brw, image->bo, format,
>                                      0, image->width, image->height, 1,
>                                      image->pitch,
>                                      MIPTREE_LAYOUT_DISABLE_AUX);

I wonder if it wouldn't be better to do this in
intel_create_image_from_name. That way it would be more obvious
up-front what's happening, and also it'd be easy to add the analogue
to intel_create_image_from_fds for the explicit dmabuf (as opposed to
ANativeBuffer; your description of 'from dmabufs' threw me because the
dmabuf fd import path would fail immediately on FourCC lookup) import
path.

As an aside, it's safe to enable in Wayland (IMO anyway), because we
only use the DRM format there; there's no concept of a 'surface
format' or visuals inside the Wayland client EGL platform, just direct
sampling from whichever buffer was last attached. EGL_NATIVE_VISUAL_ID
is empty, because we don't have anything to expose to the client.
Probably famous last words tho.

Cheers,
Daniel