[Mesa-dev] [PATCH] meta: Add GLSL variant of _mesa_meta_GenerateMipmap() function

[Brian Paul]

On 08/28/2012 07:04 PM, Ian Romanick wrote:
> On 08/28/2012 08:58 AM, Brian Paul wrote:
>> On 08/28/2012 12:14 AM, Anuj Phogat wrote:
>>> This reduces the overhead of using the fixed function internally
>>> in the driver.
>>>
>>> Note: ARB_fragment_shader is not present in intel->gen< 4. I'll send
>>> out a separate patch to avoid enabling _mesa_meta_GenerateMipmap() in
>>> those chips.
>>> No regressions observed in all.tests with this patch. Need more
>>> testing
>>> for integer textures.
>>
>> A recent ARB bug report points out that linear filtering is not
>> supported for integer textures. And thus, there's some question about
>> what to do for automatic mipmap generation of integer textures. It
>> doesn't always make sense to average four integer texels to produce a
>> new one.
>>
>> I'll monitor the bug and see what the ARB decides on. We might wind up
>> just raising GL_INVALID_OPERATION.
>
> I just noticed that today as well. In the interest of keeping the
> release somewhat on track, could we commit Anuj's patch (I still
> haven't fully reviewed it... it's the top of my to-do list for today)
> functionally as-is? If Khronos decides that glGenerateMipmap on an
> integer texture should generate an error, we can implement that as a
> bug fix.

Well, the code in the patch sets up bilinear filtering in all cases so 
I think we'll hit the 'incomplete texture' state when we try to render 
the next smaller mipmap level.  See the _mesa_is_texture_complete() 
function in texobj.h.

So, at the least, we'd have to use nearest filtering for integer 
textures to get any output.

-Brian