[Mesa-dev] Fwd: [PATCH] mesa: Correctly set base and max texture levels in glTexparameterf

[Anuj Phogat]

On Fri, Jan 4, 2013 at 1:23 AM, Ian Romanick <idr at freedesktop.org> wrote:
> On 01/02/2013 06:44 PM, Anuj Phogat wrote:
>>
>> On Wed, Jan 2, 2013 at 11:50 PM, Brian Paul <brianp at vmware.com> wrote:
>>>
>>>
>>> On 01/02/2013 10:39 AM, Paul Berry wrote:
>>>>
>>>>
>>>> On 2 January 2013 07:38, Anuj Phogat <anuj.phogat at gmail.com
>>>> <mailto:anuj.phogat at 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.