[Mesa-dev] [PATCH 10/15] mesa: Don't allow snorm internal formats in glCopyTexImage*() in GLES3

Jason Ekstrand jason at jlekstrand.net
Tue Jul 29 17:04:04 PDT 2014


On Fri, Jun 6, 2014 at 4:57 PM, Anuj Phogat <anuj.phogat at gmail.com> wrote:

> Fixes few failures in gles3 Khronos CTS test: packed_pixels
>
> Cc: "10.2" <mesa-stable at lists.freedesktop.org>
> Signed-off-by: Anuj Phogat <anuj.phogat at gmail.com>
> ---
>  src/mesa/main/teximage.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 03ebbd8..6474dba 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -2667,6 +2667,17 @@ copytexture_error_check( struct gl_context *ctx,
> GLuint dimensions,
>                       "glCopyTexImage%dD(srgb usage mismatch)",
> dimensions);
>           return GL_TRUE;
>        }
> +
> +      /* Page 139, Table 3.15 of OpenGL ES 3.0 spec does not define
> ReadPixels
> +       * types for SNORM formats. Also, conversion to SNORM formats is not
> +       * allowed by Table 3.2 on Page 110.
> +       */
> +      if(_mesa_is_enum_format_snorm(internalFormat)) {
> +         _mesa_error(ctx, GL_INVALID_OPERATION,
> +                     "glCopyTexImage%dD(internalFormat=%s)", dimensions,
> +                     _mesa_lookup_enum_by_nr(internalFormat));
> +         return GL_TRUE;
> +      }
>

I think I'm missing something.  How does this not completely prevent the
user from using CopyTexImage on SNORM formats?  Shouldn't they still be
able to do CopyTexImage between two RG8_SNORM textures for instance?


>     }
>
>     if (!_mesa_source_buffer_exists(ctx, baseFormat)) {
> --
> 1.8.3.1
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140729/b37510c4/attachment.html>


More information about the mesa-dev mailing list