[Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points

[Courtney Goeltzenleuchter]

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 <
courtney at 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 <brianp at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131205/240dd7db/attachment.html>