With the “Mesa DRI Intel(R) Sandybridge Mobile” driver, using Mesa 7.11.2, ARB fragment program TXP instructions that have ‘fragment.color’ as the coordinate input seem to not do the required W division on the texture coordinates. For an example, see the attached variant of the tri-tex.c Mesa demo. The input colors (used as texture coordinates) have all components scaled by 0.5 – so using projective texture sampling everything should look as before. Three different ways to apply the projection have been added (grep for “MODE”): manual division by W, TXP with a temp reg (containing simply fragment.color) as coordinate input, and TXP with fragment.color directly as input. Of these three modes, only the first two work as expected; the 3rd one does not apply the W division (you can only see a fraction of what you're supposed to see of the texture). This is especially interesting as the difference between the 2nd and 3rd modes is merely that the 2nd mode moves the value of the fragment color to a temp reg before using it as sampling input.
Created attachment 57659 [details] Test program variant exhibiting the issue Look for “#define MODE”, change it's value to switch how the TC projection is applied.
fun bug. have a fix I need to write a piglit test for.
I've gone ahead and pushed Eric's fix. This should be fixed in Mesa master with the following commit: commit d707e337f5f9a7b6ed465ade1b0b7c06606dde22 Author: Eric Anholt <eric@anholt.net> Date: Mon Aug 13 18:08:56 2012 -0700 i965: Fix bug in the old FS backend's projtex() calculation. In the old backend, we looked at any FS attribute's proj_attrib_mask bits, n just texcoords. Now that we have _mesa_vert_result_to_frag_attrib(), we can fill in the other FS inputs with correct proj_attrib_mask info. NOTE: This is a candidate for stable branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46644 Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> We'll need to cherry-pick this to 8.0.
merged to 8.0
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.