Am 11.07.2013 15:50, schrieb Jose Fonseca: > > > ----- Original Message ----- >> From: Roland Scheidegger <srol...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
