diff options
author | Roland Scheidegger <sroland@vmware.com> | 2013-03-09 01:46:33 +0100 |
---|---|---|
committer | Roland Scheidegger <sroland@vmware.com> | 2013-03-12 00:24:22 +0100 |
commit | 5c41d1c22282fe2fd72a77339246de8e861b4b22 (patch) | |
tree | 426989fa6fa76bcfd859a6e826ed15d4314a2a91 /src/gallium/auxiliary/gallivm/lp_bld_quad.c | |
parent | b7262ac7ea650c4416af28097c66fc64f72e3c28 (diff) | |
download | external_mesa3d-5c41d1c22282fe2fd72a77339246de8e861b4b22.zip external_mesa3d-5c41d1c22282fe2fd72a77339246de8e861b4b22.tar.gz external_mesa3d-5c41d1c22282fe2fd72a77339246de8e861b4b22.tar.bz2 |
gallivm: clean up passing derivatives around
Previously, the derivatives were calculated and passed in a packed form
to the sample code (for implicit derivatives, explicit derivatives were
packed to the same format).
There's several reasons why this wasn't such a good idea:
1) the derivatives may not even be needed (not as bad as it sounds since
llvm will just throw the calculations needed for them away but still)
2) the special packing format really shouldn't be part of the sampler
interface
3) depending what the sample code actually does the derivatives will
be processed differently, hence there is no "ideal" packing. For cube
maps with explicit derivatives (which we don't do yet) for instance the
packing looked downright useless, and for non-isotropic filtering we'd
need different calculations too.
So, instead just pass the derivatives as is (for explicit derivatives),
or let the rho calculating sample code calculate them itself. This still
does exactly the same packing stuff for implicit derivatives for now,
though explicit ones are handled in a more straightforward manner (quick
estimates show performance should be quite similar, though it is much
easier to follow and also does the rho calculation per-pixel until the
end, which we eventually need for spec compliance anyway).
No piglit changes.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Diffstat (limited to 'src/gallium/auxiliary/gallivm/lp_bld_quad.c')
-rw-r--r-- | src/gallium/auxiliary/gallivm/lp_bld_quad.c | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_quad.c b/src/gallium/auxiliary/gallivm/lp_bld_quad.c index 8a0efed..1955add 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_quad.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_quad.c @@ -79,14 +79,9 @@ lp_build_ddy(struct lp_build_context *bld, } /* - * To be able to handle multiple quads at once in texture sampling and - * do lod calculations per quad, it is necessary to get the per-quad - * derivatives into the lp_build_rho function. - * For 8-wide vectors the packed derivative values for 3 coords would - * look like this, this scales to a arbitrary (multiple of 4) vector size: - * ds1dx ds1dy dt1dx dt1dy ds2dx ds2dy dt2dx dt2dy + * Helper for building packed ddx/ddy vector for one coord (scalar per quad + * values). The vector will look like this (8-wide): * dr1dx dr1dy _____ _____ dr2dx dr2dy _____ _____ - * The second vector will be unused for 1d and 2d textures. */ LLVMValueRef lp_build_packed_ddx_ddy_onecoord(struct lp_build_context *bld, @@ -121,6 +116,11 @@ lp_build_packed_ddx_ddy_onecoord(struct lp_build_context *bld, } +/* + * Helper for building packed ddx/ddy vector for one coord (scalar per quad + * values). The vector will look like this (8-wide): + * ds1dx ds1dy dt1dx dt1dy ds2dx ds2dy dt2dx dt2dy + */ LLVMValueRef lp_build_packed_ddx_ddy_twocoord(struct lp_build_context *bld, LLVMValueRef a, LLVMValueRef b) |