diff options
author | Roland Scheidegger <[email protected]> | 2013-10-18 20:52:26 +0200 |
---|---|---|
committer | Roland Scheidegger <[email protected]> | 2013-10-21 15:42:04 +0200 |
commit | 3bdd1074e1e85faa73ba927dee1547d956f6144f (patch) | |
tree | dd7e72cb27bcc6bd6184614e2dc3b8898dcab1c3 /src/gallium/drivers/llvmpipe/lp_context.h | |
parent | 21a57f9040b1688e6501509c88c79c2d277c8b1e (diff) |
gallivm: implement seamless cube filtering
For seamless cube filtering it is necessary to determine new faces and new
coords per sample. The logic for this is _seriously_ complex (what needs
to happen is very "asymmetric" wrt face, x/y under/overflow), further
complicated by the fact that if the 4 samples are in a corner (meaning we
only have actually 3 samples, and all 3 are on different faces) then
falling off the edge is happening _both_ on x and y axis simultaneously.
There was a noticeable performance hit in mesa's cubemap demo when seamless
filtering was forced on (just below 10 percent or so in a debug build, when
disabling all filtering hacks, otherwise it would probably be a bit more) and
when always doing the logic, hence use a branch which it only does it if any
of the pixels in a quad (or in two quads) actually hit this. With that there
was no measurable performance hit in the cubemap demo (neither in a debug nor
release buidl), but this will vary (cubemap demo very rarely hits edges).
Might also be different on other cpus, as this forces SoA sampling path which
potentially can be quite a bit slower.
Note that as for corners, this code gets all the 3 samples which actually
exist right, and the 4th texel will simply be the same as one of the others,
meaning that filter weights will be a bit wrong. This however should be
enough for full OpenGL (but not d3d10) compliance.
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
Diffstat (limited to 'src/gallium/drivers/llvmpipe/lp_context.h')
0 files changed, 0 insertions, 0 deletions