[Mesa-dev] [PATCH 2/2] gallivm: change cubemaps / derivatives handling, take 55

Brian Paul brianp at vmware.com
Tue Apr 16 12:51:47 PDT 2013


On 04/16/2013 01:07 PM, sroland at vmware.com wrote:
> From: Roland Scheidegger<sroland at vmware.com>
>
> Turns out the previous "fix" for handling per-pixel face selection and
> derivatives didn't work out that well - the derivatives were wrong by
> quite a bit, in theory transformation of the derivatives into cube space
> should work, but would be _a lot_ more work than the "simplified" transform
> used.
> So, for explicit derivatives, I'm just giving up and go back to not honoring
> them.
> For implicit derivatives (and the fake explicit ones) however we try
> something a little different, we just calculate rho as we would for a 3d
> texture, that is after scaling the coords by the inverse major axis.
> This gives the same results as calculating the derivs after projection of
> the coords to the same face as long as all pixels hit the same face (and
> only without rho_no_opt, otherwise it should be a bit worse). And when
> not all pixels are hitting the same face, the results aren't so hot but
> not catastrophically bad (I believe not off by more than a factor of 2 without
> no_rho_opt and not more than sqrt(2) with no_rho_opt). I think this is better
> than just picking the wrong face but who knows...

Sounds OK to me.

Reviewed-by: Brian Paul <brianp at vmware.com>


More information about the mesa-dev mailing list