On Fri, Jan 4, 2013 at 1:23 AM, Ian Romanick <i...@freedesktop.org> wrote: > On 01/02/2013 06:44 PM, Anuj Phogat wrote: >> >> On Wed, Jan 2, 2013 at 11:50 PM, Brian Paul <bri...@vmware.com> wrote: >>> >>> >>> On 01/02/2013 10:39 AM, Paul Berry wrote: >>>> >>>> >>>> On 2 January 2013 07:38, Anuj Phogat <anuj.pho...@gmail.com >>>> <mailto:anuj.pho...@gmail.com>> wrote: >>>> >>>> @@ -670,6 +668,28 @@ _mesa_TexParameterf(GLenum target, GLenum >>>> pname, GLfloat param) >>>> need_update = set_tex_parameteri(ctx, texObj, pname, p); >>>> } >>>> break; >>>> + case GL_TEXTURE_BASE_LEVEL: >>>> + case GL_TEXTURE_MAX_LEVEL: >>>> + { >>>> + GLint p[4]; >>>> + /* Check if param exceeds maximum value an integer can >>>> hold */ >>>> + if (param > 2147483647.0f) { >>>> + p[0] = (GLint) 2147483647.0f; >>>> + } >>>> + else if (param < 0.0f) { >>>> + p[0] = 0; >>>> + } >>>> >>>> >>>> I'm not convinced that this amount of thoroughness is necessary. >>>> There's no language in the spec (or test cases that I'm aware of) to >>>> indicate that out-of-range floats need to be translated to INT_MAX or >>>> 0. I think it would be adequate to just do "p[0] = (int) >>>> round(param);" and just let the behaviour be undefined for >>>> out-of-range values. >>>> >> Yes, there is no such text in the spec. But gles3 conformance is testing >> this case. GTF/Source/GL3Tests/GTFTestSGISTextureLod.c in gles3 >> conformance sets param=8589934592.0f using glTexParameterf() and >> expect 2147483647 when queried using glGetTexParameteriv(). if not >> handled correctly we get param=-2147483648. >> What conformance test expects is logical but not exactly follow >> the text in spec. I'm not sure if we should file a bug in conformance >> test suite. > > > I believe they are relying on table 3.17 (page 145, page 157 of the PDF) > that says TEXTURE_MAX_LEVEL can be "any non-negative integer". I would > expect > > glGetTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, &m); > glTexParameteriv(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, m); > > to always work. If the Get call returns -2147483648, the second call will > generate an error. right. I think spec should suggest clamping of out-of-range floats to {INT_MIN, INT_MAX}. gles3 conformance test looks correct. So, I'll keep the clamping code in this patch.
> > I'll submit this as a spec bug. Thanks Ian. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
