summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/intel_blit.c
diff options
context:
space:
mode:
authorRoland Scheidegger <sroland@vmware.com>2013-11-20 05:17:56 +0000
committerRoland Scheidegger <sroland@vmware.com>2013-11-21 20:39:19 +0000
commit28d7b4147d4048031dd1a99c0858472912ea7e7e (patch)
tree67ba605999e435c82113162352fa66ae6e4e0790 /src/mesa/drivers/dri/i965/intel_blit.c
parent9d1c71e34d5ec225f1d4f12f6d7dad5148ab0e8b (diff)
downloadexternal_mesa3d-28d7b4147d4048031dd1a99c0858472912ea7e7e.zip
external_mesa3d-28d7b4147d4048031dd1a99c0858472912ea7e7e.tar.gz
external_mesa3d-28d7b4147d4048031dd1a99c0858472912ea7e7e.tar.bz2
llvmpipe: calculate more accurate interpolation value at origin
Some rounding errors could crop up when calculating a0. Use a more accurate method (barycentric interpolation essentially) to fix this, though to fix the REAL problem (which is that our interpolation will give very bad results with small triangles far away from the origin when they have steep gradients) this does absolutely nothing (actually makes it worse). (To fix the real problem, either would need to use a vertex corner (or some other point inside the tri) as starting point value instead of fb origin and pass that down to interpolation, or mimic what hw does, use barycentric interpolation (using the coordinates extracted from the rasterizer edge functions) - maybe another time.) Some (silly) tests though really want a high accuracy at fb origin and don't care much about anything else (Just. Don't. Ask.). Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Diffstat (limited to 'src/mesa/drivers/dri/i965/intel_blit.c')
0 files changed, 0 insertions, 0 deletions