[Mesa-dev] map-texture-image-v5 branch

[Brian Paul]

On 08/30/2011 12:15 PM, Eric Anholt wrote:
> On Mon, 29 Aug 2011 21:41:04 -0600, Brian Paul<brian.e.paul at gmail.com>  wrote:
>> I've created this branch with the first batch of my reworked
>> map-texture-image patches.  I'm having some network/mail problems so
>> git-send-email isn't working for me ATM.  Please review/test and I'll
>> merge to master.  Thanks.
>
> Many regressions:
>
> http://people.freedesktop.org/~anholt/summary/changes.html

That's not too many.  FWIW, I'm not seeing any of the 
fbo-generatemipmap-formats regressions on my i945 system.
i945 doesn't have texture_sRGB so I'm not sure what's happening there.

With swrast, fbo-generatemipmap-formats has the same failures on 
master as map-texture-image-v5

I suspect the meta decompress_texture_image() function is the root 
cause of most of these failures.  But beyond that I'm not sure why 
because it seems to work OK for me.

Could you take a close look at one of the fbo-generatemipmap-formats 
failures and see if the output is totally wrong or close or what?


>
> (glsl-fs-texturecube-bias is a spurious failure in the before case).
>
> I think just the GetTexImage stuff needs to get sorted out and pushed
> before we move on.  Right now it's regressing on most of our tests that
> happen to use GetTexImage, so I'm not convinced that we will have real
> working code for it even if those regressions are fixed.  However, my
> WIP testcase only shows regressions on SRGB, compressed, and SNORM,
> which happens to be the failures above.

The two big changes I made for GetTexImage() are:
1. Use the new format_unpack.c code instead of the 
gl_texture_image::FetchTexel() function to get RGB values.
2. Use the new meta decompress_texture_image() function to handle 
texture the decompression path.

I didn't mess with the mapping/unmapping stuff at all.

Both paths seem to work as expected for me in the cases I can test.

-Brian