On Fri, Aug 9, 2013 at 8:28 PM, Ian Romanick <i...@freedesktop.org> wrote:
> On 08/09/2013 04:22 AM, Martin Andersson wrote:
>>
>> I think I have found an issue in the piglit test.
>>
>> Marek, could you take a look at the attached patch and see if it looks
>> correct. If so I will send it to the piglit list.
>
>
> Wow. That test is confusing. It would be a lot more obvious (and less
> error prone) if each case statement directly computed expected and bias. I
> think you're right about the GL_RGB_INTEGER_EXT case, but it seems like the
> GL_ALPHA_INTEGER_EXT case has a similar problem. Shouldn't value[0],
> value[1], and value[2] be set to 0?
I think you're right that GL_ALPHA_INTEGER_EXT also have a problem,
but it doesn't cause the test to fail. Take this example:
value = 72, 89, 0, 72
expected = 0, 0, 0, 0.25
// computed bias
bias = -72, -89, 0, -71.75
// ivec4 t = texture(tex, gl_TexCoord[0].xy);
t = 0, 0, 0, 72
t + bias
result = -72, -89, 0, 0.25
I guess the negative values are rounded up to zero, which are the
expected values for rgb so the test passes.
This example illustrates why GL_ALPHA_INTEGER_EXT failed when alpha was zero.
value = 121, 68, 32, 0
expected = 0.25, 0.5, 0.75, 0
// computed bias
bias = -120.75, -67.5, -31.25, 0
// ivec4 t = texture(tex, gl_TexCoord[0].xy);
t = 121, 68, 32, 1
t + bias
result = 0.25, 0.5, 0.75, 1
Which fails the test. If value instead is:
value = 121, 68, 32, 1
bias = -120.75, -67.5, -31.25, -1
The result becomes:
result = 0.25, 0.5, 0.75, 0
Which passes the test, for all alpha values greater than one the
result alpha becomes negative which I guess get rounded to zero, which
also passes the test.
This is my analysis of this issue, but my knowledge of these things
are pretty limited so I could be wrong.
//Martin
>
>> //Martin
>>
>> On Tue, Aug 6, 2013 at 11:20 PM, Marek Olšák <mar...@gmail.com> wrote:
>>>
>>> Sorry, I have no idea. You can try to remove support for RGBX integer
>>> formats and see if it helps.
>>>
>>> In is_format_supported, return FALSE for all R?G?B?X_?INT formats.
>>>
>>> Marek
>>>
>>> On Sat, Aug 3, 2013 at 11:51 AM, Martin Andersson <g02ma...@gmail.com>
>>> wrote:
>>>>
>>>> Well, I should have been more clear. If I do this:
>>>>
>>>> 263: value[3] = 0;
>>>> 290: expected[3] = 1.0;
>>>>
>>>> The test always passes, but if I only do this:
>>>>
>>>> 290: expected[3] = 1.0;
>>>>
>>>> The test fails with this error:
>>>>
>>>> texture-integer: failure with format GL_RGB8I_EXT:
>>>> texture color = 92, 126, 14, 104
>>>> expected color = 0.25, 0.5, 0.75, 1
>>>> result color = 0.25098, 0.501961, 0.74902, 0
>>>> PIGLIT: {'result': 'fail' }
>>>>
>>>> //Martin
>>>>
>>>> On Sat, Aug 3, 2013 at 5:23 AM, Marek Olšák <mar...@gmail.com> wrote:
>>>>>
>>>>> FragShaderText contains the shader code. Anyway, we have found the
>>>>> issue: expected[3] should really be set to 1.0, because RGB formats
>>>>> must return (r,g,b,1). It's a bug in the piglit test.
>>>>>
>>>>> Marek
>>>>>
>>>>> On Fri, Aug 2, 2013 at 11:44 PM, Martin Andersson <g02ma...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Fri, Aug 2, 2013 at 2:52 PM, Marek Olšák <mar...@gmail.com> wrote:
>>>>>>>
>>>>>>> The format doesn't have alpha. See what the texture fetch writes to
>>>>>>> the alpha channel.
>>>>>>
>>>>>>
>>>>>> I looked at the code but I can't figure out where the texture fetch
>>>>>> happens, could you point me in the right direction?
>>>>>>
>>>>>>>
>>>>>>> You may try setting "texture-integer.c:290" to "expected[3] = 1.0;"
>>>>>>
>>>>>>
>>>>>> The test passes if I do that.
>>>>>>
>>>>>> //Martin
>>>>>>
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On Fri, Aug 2, 2013 at 2:15 PM, Martin Andersson <g02ma...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I started to look at why the spec/!OpenGL 3.0/gl-3.0-texture-integer
>>>>>>>> sometimes fails on my AMD 6950, using mesa master. It fails with
>>>>>>>> errors like this:
>>>>>>>>
>>>>>>>> texture-integer: failure with format GL_RGB8I_EXT:
>>>>>>>> texture color = 100, 9, 71, 0
>>>>>>>> expected color = 0.25, 0.5, 0.75, 0
>>>>>>>> result color = 0.25098, 0.501961, 0.74902, 1
>>>>>>>> PIGLIT: {'result': 'fail' }
>>>>>>>>
>>>>>>>> When I ran the test a bunch of times I found that it only failed
>>>>>>>> when
>>>>>>>> the last texture color was zero. So when I changed this code in the
>>>>>>>> pigilt test:
>>>>>>>>
>>>>>>>> value[0] = rand() % max;
>>>>>>>> value[1] = rand() % max;
>>>>>>>> value[2] = rand() % max;
>>>>>>>> value[3] = rand() % max;
>>>>>>>>
>>>>>>>> to this:
>>>>>>>>
>>>>>>>> value[0] = rand() % max;
>>>>>>>> value[1] = rand() % max;
>>>>>>>> value[2] = rand() % max;
>>>>>>>> value[3] = 0;
>>>>>>>>
>>>>>>>> The test always fails.
>>>>>>>>
>>>>>>>> I found this bug https://bugs.freedesktop.org/show_bug.cgi?id=63664
>>>>>>>> But I can't reproduce this bug on my intel G45 (running mesa 9.1.5).
>>>>>>>>
>>>>>>>> Anyone know what is causing this or how I could debug it further?
>>>>>>>>
>>>>>>>> //Martin
>>>>>>>> _______________________________________________
>>>>>>>> mesa-dev mailing list
>>>>>>>> mesa-dev@lists.freedesktop.org
>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> mesa-dev mailing list
>>>>>>>> mesa-dev@lists.freedesktop.org
>>>>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
