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

[Jason Ekstrand]

On Wed, Jul 30, 2014 at 8:51 PM, Anuj Phogat <anuj.phogat at gmail.com> wrote:

> On Tue, Jul 29, 2014 at 5:04 PM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
> >
> > 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?
> >
> Yes, this will prevent such operation. This is what I interpreted from
> spec's
> language in section 3.8.5 which describes the glCopyTexImage2D():
>
> "The image is taken from the current color buffer exactly as if these
> arguments
>  were passed to ReadPixels with arguments format and type set according to
>  table 3.15, stopping after conversion of RGBA values."
>
> "Subsequent processing is identical to that described for TexImage2D,
> begin-
> ning with clamping of the R, G, B, and A values from the resulting pixel
> groups.
> Parameters level, internalformat, and border are specified using the
> same values,
> with the same meanings, as the equivalent arguments of TexImage2D."
>
> Table 3.15 doesn't list ReadPixels types for SNORM formats which can be
> used
> during CopyTex*.
>
> Do you interpret the spec differently?
>

No, that's what the spec seems to say.  It seems silly to me, but it's
what's in the spec.

Reviewed-by: Jason Ekstrand <jason.ekstrand at intel.com>


> >>
> >>     }
> >>
> >>     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/20140731/013843ee/attachment-0001.html>