[Mesa-dev] [PATCH 4/5] blit: Don't take into account the Mesa format when checking MSRT blit

[Marek Olšák]

On Thu, Nov 19, 2015 at 4:25 PM, Neil Roberts <neil at linux.intel.com> wrote:
> According to the GLES3 spec, blitting between multisample FBOs with
> different internal formats should not be allowed. The
> compatible_resolve_formats function implements this check. Previously
> it had a shortcut where if the Mesa formats of the two renderbuffers
> were the same then it would assume the blit is ok. However some
> drivers map different internal formats to the same Mesa format, for
> example it might implement both GL_RGB and GL_RGBA textures with
> MESA_FORMAT_R8G8B8A_UNORM. The function is used to generate a GL error
> according to what the GL spec requires so the blit should not be
> allowed in that case. This patch just removes the shortcut so that it
> only ever looks at the internal format.
>
> Note that I posted a related patch to disable this check altogether
> for desktop GL. However this function is still used on GLES3 because
> there are conformance tests that require this behaviour so this patch
> is still useful.
>
> Cc: Marek Olšák <maraeo at gmail.com>
> ---
>  src/mesa/main/blit.c | 28 +++++++++++++++-------------
>  1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/main/blit.c b/src/mesa/main/blit.c
> index a32f1a4..deb4f5a 100644
> --- a/src/mesa/main/blit.c
> +++ b/src/mesa/main/blit.c
> @@ -129,20 +129,22 @@ compatible_resolve_formats(const struct gl_renderbuffer *readRb,
>  {
>     GLenum readFormat, drawFormat;
>
> -   /* The simple case where we know the backing Mesa formats are the same.
> -    */
> -   if (_mesa_get_srgb_format_linear(readRb->Format) ==
> -       _mesa_get_srgb_format_linear(drawRb->Format)) {
> -      return GL_TRUE;
> -   }
> -
> -   /* The Mesa formats are different, so we must check whether the internal
> -    * formats are compatible.
> +   /* This checks whether the internal formats are compatible rather than the
> +    * Mesa format for two reasons:
> +    *
> +    * • Under some circumstances, the user may request e.g. two GL_RGBA8
> +    *   textures and get two entirely different Mesa formats like RGBA8888 and
> +    *   ARGB8888. Drivers behaving like that should be able to cope with
> +    *   non-matching formats by themselves, because it's not the user's fault.
> +    *
> +    * • Picking two different internal formats can end up with the same Mesa
> +    *   format. For example the driver might be simulating GL_RGB textures
> +    *   with GL_RGBA internally and in that case both internal formats would
> +    *   end up with RGBA8888.
>      *
> -    * Under some circumstances, the user may request e.g. two GL_RGBA8
> -    * textures and get two entirely different Mesa formats like RGBA8888 and
> -    * ARGB8888. Drivers behaving like that should be able to cope with
> -    * non-matching formats by themselves, because it's not the user's fault.
> +    * This function is used to generate a GL error according to the spec so in
> +    * both cases we want to be looking at the appliation-level format, which

typo: application

other than that:

Reviewed-by: Marek Olšák <marek.olsak at amd.com>

Marek