Browsing the code a little, it's not clear that drivers are using the
texture object's BaseLevel in a "safe" manner.
Some example uses of BaseLevel:
[intel driver]
const struct gl_texture_image *img = t->Image[0][t->BaseLevel]; //
Without conditioning, this could lead to memory access error. Maybe
that's already an issue?
firstImage = tObj->Image[0][tObj->BaseLevel]; // Same with this
if (sampler->MinFilter == GL_NEAREST ||
sampler->MinFilter == GL_LINEAR) {
maxlevel = tObj->BaseLevel;
} else {
maxlevel = tObj->_MaxLevel;
}
[st_atom_sampler]
sampler->min_lod = CLAMP(msamp->MinLod,
0.0f,
(GLfloat) texobj->MaxLevel - texobj->BaseLevel);
There are more. All using the values that were set in TexParam.
Courtney
On Thu, Dec 5, 2013 at 9:41 AM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:
> Okay, that makes it easier.
>
> Should this change be conditional based on the type of context created?
>
> Courtney
>
>
> On Thu, Dec 5, 2013 at 8:52 AM, Brian Paul <bri...@vmware.com> wrote:
>
>> On 12/04/2013 03:46 PM, Courtney Goeltzenleuchter wrote:
>>
>>> It's come to my attention that Mesa's handling of GL_TEXTURE_BASE_LEVEL
>>> and GL_TEXTURE_MAX_LEVEL in glTexParameter and glGetTexParameter may be
>>> incorrect. The issue happens with the following sequence:
>>>
>>> glTexStorage2D(GL_TEXTURE_2D, 4, GL_RGBA8, 128, 128);
>>>
>>> glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 5);
>>>
>>> glGetTexParameter(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, &n);
>>>
>>> The key question is: What is the value of n?
>>>
>>> Right now, the Mesa driver will clamp the glTexParameter call to the
>>> range 0 .. 3 (as specified by the TexStorage call) and n = 3 after the
>>> GetTexParameter call. However, the value returned on the Intel Windows
>>> driver and NVIDIA's Linux driver return 5. This has apparently been
>>> discussed among Kronos members in bug: 9342
>>> (https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9342
>>> <https://urldefense.proofpoint.com/v1/url?u=https:
>>> //cvs.khronos.org/bugzilla/show_bug.cgi?id%3D9342&k=
>>> oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%
>>> 2BTLs8wadB%2BiIj9xpBY%3D%0A&m=SrPAWBW251dxCErQJNhB0m93E9Vb62
>>> KGHxK3yiRBRuU%3D%0A&s=a0c086b7a31a804e3e786118fd1771
>>> b53c85717a4cf0c8dea41b60e5acd0406b>)
>>>
>>> which I don't have visibility of.
>>>
>>> To match that behavior the texture object will likely need two BaseLevel
>>> and MaxLevel attributes. One that's clamped and used locally and the
>>> other that simply holds the set value as given by the application in the
>>> glTexParameter call.
>>>
>>> Thoughts?
>>>
>>
>> From reading the bug report, it sounds like the ARB decided that clamping
>> should be done when the texture is used, not when glTexParameter is called.
>> In the GL 4.3 spec I don't see any language about clamping in
>> glTexParameter either.
>>
>> We should be doing the use-time clamping already. So I think we just
>> have to remove the clamping step in glTexParameter.
>>
>> -Brian
>>
>>
>
>
> --
> Courtney Goeltzenleuchter
> LunarG
>
>
--
Courtney Goeltzenleuchter
LunarG
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
