[Mesa-dev] [PATCH 2/2] gallivm: handle srgb-to-linear and linear-to-srgb conversions

[Roland Scheidegger]

Am 11.07.2013 15:50, schrieb Jose Fonseca:
> 
> 
> ----- Original Message -----
>> From: Roland Scheidegger <sroland at vmware.com>
>>
>> srgb-to-linear is using 3rd degree polynomial for now which should be _just_
>> good enough. Reverse is using some rational polynomials and is quite
>> accurate,
>> though not hooked into llvmpipe's blend code yet and hence unused (untested).
>> Using a table might also be an option (for srgb-to-linear especially).
>> This does not enable any new features yet because EXT_texture_srgb was
>> already
>> supported via util_format fallbacks, but performance was lacking probably due
>> to the external function call (the table used by the util_format_srgb code
>> may
>> not be all that much slower on its own).
>> Some performance figures (taken from modified gloss, replaced both base and
>> sphere texture to use GL_SRGB instead of GL_RGB, measured on 1Ghz Sandy
>> Bridge,
>> the numbers aren't terribly accurate):
>>
>> normal gloss, aos, 8-wide: 47 fps
>> normal gloss, aos, 4-wide: 48 fps
>>
>> normal gloss, forced to soa, 8-wide: 48 fps
>> normal gloss, forced to soa, 4-wide: 47 fps
>>
>> patched gloss, old code, soa, 8-wide: 21 fps
>> patched gloss, old code, soa, 4-wide: 24 fps
>>
>> patched gloss, new code, soa, 8-wide: 41 fps
>> patched gloss, new code, soa, 4-wide: 38 fps
> 
> Indeed, not a big difference.  Though these figures seem low overall -- I get 72.5275 on my machine.  This was with release/profile build, right?
Yes with release build - I get less than half that with debug build. You
got 72.5 on a 1Ghz Sandy Bridge using 1 thread? I was also using llvm 3.1.

> 
> Eitherway the patch looks good.
Actually it does not I forgot to include the actual conversion code.
I'll send out another version :-(.

Roland