On 27/01/18 01:59, srol...@vmware.com wrote: > From: Roland Scheidegger <srol...@vmware.com> > > The size/type query is always legal (if we made it that far). > This causes a difference for GL_TEXTURE_BUFFER - the reason is that these > parameters are valid only with GetTexLevelParameter() if gl 3.1 is supported, > but not if only ARB_texture_buffer_object is supported. > However, while the spec says that these queries return "the same information > as querying GetTexLevelParameter" I believe we're not expected to return just > zeros here. By definition, these pnames are always valid (unlike for the > GetTexLevelParameter() function which would return an error without GL 3.1), > so returning 0 but no error makes no sense to me.
But in general, AFAIU, this is how GetInternalFormat works. The extension only raises an error if their API is not used properly. But not if the combination being requested doesn't make sense. For example, the pname GET_TEXTURE_IMAGE_FORMAT, would return the same value that using GetTexImage. But if the resource is not supported by GetTextImage, it should return NONE, but not raising an error. So for example, you could use as target GL_RENDERBUFFER for GET_TEXTURE_IMAGE_FORMAT query, and just get a GL_NONE, but no an error. While that one would raise an error on GetTexImage. > > This breaks some piglit arb_internalformat_query2 tests (which I belive to > be wrong). > --- > src/mesa/main/formatquery.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/src/mesa/main/formatquery.c b/src/mesa/main/formatquery.c > index 2214f97e67..f345140518 100644 > --- a/src/mesa/main/formatquery.c > +++ b/src/mesa/main/formatquery.c > @@ -960,9 +960,6 @@ _mesa_GetInternalformativ(GLenum target, GLenum > internalformat, GLenum pname, > mesa_format texformat; > > if (target != GL_RENDERBUFFER) { > - if (!_mesa_legal_get_tex_level_parameter_target(ctx, target, true)) > - goto end; > - > baseformat = _mesa_base_tex_format(ctx, internalformat); > } else { > baseformat = _mesa_base_fbo_format(ctx, internalformat); _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev