On 08/30/2011 12:15 PM, Eric Anholt wrote:
On Mon, 29 Aug 2011 21:41:04 -0600, Brian Paul<brian.e.p...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
