|Summary:||i915g: gl_FragCoord is always (0.0, max_y)|
|Product:||Mesa||Reporter:||Nicholas Bishop <nicholasbishop>|
|Component:||Drivers/Gallium/i915g||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED MOVED||QA Contact:||Default DRI bug account <dri-devel>|
|i915 platform:||i915 features:|
|Attachments:||Patch: Handle I915_SEMANTIC_POS when setting texCoords for gl_FragCoord|
Description Nicholas Bishop 2016-08-25 05:16:17 UTC
Created attachment 126029 [details] [review] Patch: Handle I915_SEMANTIC_POS when setting texCoords for gl_FragCoord On Intel Pineview M hardware, the i915 gallium driver doesn't output the correct gl_FragCoord. It seems to always have an X coord of 0.0 and a Y coord of the window's height in pixels, e.g. 600.0f or such. I believe this is a regression caused in part by commit afa035031ff9e0c07a2297d864e46c76f7bfff58 (https://lists.freedesktop.org/archives/mesa-commit/2016-January/061181.html) The old behavior used output zero, while the new behavior uses actual zeroes. In the case of gl_FragCoord output zero happened to be the correct one. I've attached a patch that seems to fix the issue for me. I ran the piglit "quick" tests and observed 17 new tests passing, and one regression. I suspect the regression is unimportant since it involves derivatives that aren't implemented for this driver anyway: "fs-dfdy-accuracy" test failed ... in i915_fpc_translate.c: case TGSI_OPCODE_DDY: /* XXX We just output 0 here */ debug_printf("Punting DDX/DDX\n");
Comment 1 Nicholas Bishop 2016-08-25 23:34:31 UTC
Posted the patch to the mailing list with a somewhat clearer commit message: https://lists.freedesktop.org/archives/mesa-dev/2016-August/127065.html FWIW, the process of submitting a patch via the mailing list is a really big barrier to entry for someone new to the project.
Comment 2 GitLab Migration User 2019-09-18 19:31:03 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/668.