summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/vc4/vc4_bufmgr.c
diff options
context:
space:
mode:
authorIago Toral Quiroga <[email protected]>2015-02-24 19:02:50 +0100
committerIago Toral Quiroga <[email protected]>2015-06-18 08:35:46 +0200
commit2b1cdb0eddb73f62e4848d4b64840067f1f70865 (patch)
tree13547974a7b74aed1eb1884614a2dc9f17355e60 /src/gallium/drivers/vc4/vc4_bufmgr.c
parent36e3eb6a957f8f20ed187ec88a067fc65cb81432 (diff)
i965: Fix textureGrad with cube samplers
We can't use sampler messages with gradient information (like sample_g or sample_d) to deal with this scenario because according to the PRM: "The r coordinate and its gradients are required only for surface types that use the third coordinate. Usage of this message type on cube surfaces assumes that the u, v, and gradients have already been transformed onto the appropriate face, but still in [-1,+1] range. The r coordinate contains the faceid, and the r gradients are ignored by hardware." Instead, we should lower this to compute the LOD manually based on the gradients and use a different sample message that takes the computed LOD instead of the gradients. This is already being done in brw_lower_texture_gradients.cpp, but it is restricted to shadow samplers only, although there is a comment stating that we should probably do this also for samplerCube and samplerCubeArray. Because of this, both dEQP and Piglit test cases for textureGrad with cube maps currently fail. This patch does two things: 1) Activates the texturegrad lowering pass for all cube samplers. 2) Corrects the computation of the LOD value for cube samplers. I had to do 2) because for cube maps the calculations implemented in the lowering pass always compute a value of rho that is twice the value we want (so we get a LOD value one unit larger than we want). This only happens for cube map samplers (all kinds). I am not sure about why we need to do this, but I suspect that it is related to the fact that cube map coordinates, when transported to a specific face in the cube, are in the range [-1, 1] instead of [0, 1] so we probably need to divide the derivatives by 2 when we compute the LOD. Doing that would produce the same result as dividing the final rho computation by 2 (or removing a unit from the computed LOD, which is what we are doing here). Fixes the following piglit tests: bin/tex-miplevel-selection textureGrad Cube -auto -fbo bin/tex-miplevel-selection textureGrad CubeArray -auto -fbo bin/tex-miplevel-selection textureGrad CubeShadow -auto -fbo Fixes 10 dEQP tests in the following category: dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*cube* Reviewed-by: Ben Widawsky <[email protected]>
Diffstat (limited to 'src/gallium/drivers/vc4/vc4_bufmgr.c')
0 files changed, 0 insertions, 0 deletions