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.
I'll submit this as a spec bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
