[Mesa-dev] [PATCH] mesa: fix glGetTexImage for srgb textures when srgb decode is skipped
sroland at vmware.com
Mon May 23 08:57:51 PDT 2011
I'd support that as well, sounds more sane than doing
nonlinear-to-linear plus linear-to-linear - when I did the fast-path
srgb texgetimage patch I didn't notice there is already other code which
is switching the fetch functions for GL_SKIP_DECODE_EXT.
Sounds to me though wine is doing something inefficient in the first
place, since I don't think d3d apps would generally do something which
would really require reading back the texture image.
Am 23.05.2011 16:45, schrieb Brian Paul:
> I think another approach would be to temporarily set the
> Sampler.sRGBDecode field to GL_SKIP_DECODE_EXT, use the non-sRGB path
> to get the texels, then restore Sampler.sRGBDecode to its original
> value. Call _mesa_set_fetch_functions() as needed to choose the
> non-decoding texel fetch functions. Then we could avoid the
> linear_to_nonlinear() function altogether.
> We should probably have a piglit test to exercise glGetTexImage with
> sRGB textures...
> On Sat, May 21, 2011 at 5:37 PM, Mike Kaplinskiy
> <mike.kaplinskiy at gmail.com> wrote:
>> Sorry looks like I edited that comment a few too many times. Here's an
>> updated patch with the comment fixed.
>> On Sat, May 21, 2011 at 7:15 PM, Mike Kaplinskiy
>> <mike.kaplinskiy at gmail.com> wrote:
>>> This fixes the loading screen for Assassins Creed Brotherhood running
>>> under wine for me [exposed by a fast-path that actually fixed it at
>>> be0a2f62f3a5bc6f05c3c7c6b674f2688aee031d]. May also fix bug 37150.
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev