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
<court...@lunarg.com <mailto: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
<mailto: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=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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
