summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary/gallivm/lp_bld_format.h
diff options
context:
space:
mode:
authorRoland Scheidegger <sroland@vmware.com>2013-07-13 17:31:52 +0200
committerRoland Scheidegger <sroland@vmware.com>2013-07-13 18:42:17 +0200
commit6bcbb0dc82f9f72c747ef39ed80a4ee0d883ce8e (patch)
tree0fe77e14d43a97441246476db4a15f51ac8647eb /src/gallium/auxiliary/gallivm/lp_bld_format.h
parent9b8d97e5bf76219e84e4f4e9c90c16a543eb837d (diff)
downloadexternal_mesa3d-6bcbb0dc82f9f72c747ef39ed80a4ee0d883ce8e.zip
external_mesa3d-6bcbb0dc82f9f72c747ef39ed80a4ee0d883ce8e.tar.gz
external_mesa3d-6bcbb0dc82f9f72c747ef39ed80a4ee0d883ce8e.tar.bz2
gallivm: handle srgb-to-linear and linear-to-srgb conversions
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 So there's a performance hit but it seems acceptable, certainly better than using the fallback. Note the new code only works for 4x8bit srgb formats, others (L8/L8A8) will continue to use the old util_format fallback, because I can't be bothered to write code for formats noone uses anyway (as decoding is done as part of lp_build_unpack_rgba_soa which can only handle block type width of 32). Compressed srgb formats should get their own path though eventually (it is going to be expensive in any case, first decompress, then convert). No piglit regressions. v2: use lp_build_polynomial instead of ad-hoc polynomial construction, also since keeping both linear to srgb functions for now make sure both are compiled (since they share quite some code just integrate into the same function). v3: formatting fixes and bugfix in the complicated (disabled) linear-to-srgb path. Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Diffstat (limited to 'src/gallium/auxiliary/gallivm/lp_bld_format.h')
-rw-r--r--src/gallium/auxiliary/gallivm/lp_bld_format.h11
1 files changed, 11 insertions, 0 deletions
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format.h b/src/gallium/auxiliary/gallivm/lp_bld_format.h
index 12a0318..744d002 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format.h
@@ -158,4 +158,15 @@ lp_build_rgb9e5_to_float(struct gallivm_state *gallivm,
LLVMValueRef src,
LLVMValueRef *dst);
+LLVMValueRef
+lp_build_linear_to_srgb(struct gallivm_state *gallivm,
+ struct lp_type src_type,
+ LLVMValueRef src);
+
+LLVMValueRef
+lp_build_srgb_to_linear(struct gallivm_state *gallivm,
+ struct lp_type src_type,
+ LLVMValueRef src);
+
+
#endif /* !LP_BLD_FORMAT_H */