On Thu, Nov 19, 2015 at 4:25 PM, Neil Roberts <n...@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 <mar...@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.ol...@amd.com>
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
