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

[Brian Paul]

In _mesa_test_texobj_completeness() we check if BaseLevel is negative. 
If so, we mark the texture object as 'incomplete'.  Down in the drivers, 
we should never sample from a texture that's incomplete.  In gallium, 
for example, we use a dummy/fallback texture instead.

-Brian

On 12/05/2013 10:16 AM, Courtney Goeltzenleuchter wrote:
> 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 <mailto: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
>     <mailto: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=8j9s5ig%2FDyFT8SNxc8Hh2Ote4QS96m9F38JN6bYow4U%3D%0A&s=8b560a97e6e9d96f301fa9015d729022dfa73f3f26427740d8cd54d2e29e76c1>
>             <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__b53c85717a4cf0c8dea41b60e5acd0__406b
>             <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=SrPAWBW251dxCErQJNhB0m93E9Vb62KGHxK3yiRBRuU%3D%0A&s=a0c086b7a31a804e3e786118fd1771b53c85717a4cf0c8dea41b60e5acd0406b>>)
>
>             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
>