i965: Stop using BRW_RASTRULE_LOWER_RIGHT on Gen4-5.

This effectively reverts Robert Ellison's 2009 commit
cc8afbd3862fedfe42e51c3774960d1c7078ec53.

I'm not seeing any GL spec text indicating that UPPER won't work.
On Gen6+, this bit moved to 3DSTATE_WM as a single bit, controlling
UPPER_LEFT vs. UPPER_RIGHT.  There is no way to request LOWER_RIGHT,
so UPPER_RIGHT is the best you can do.

In the G45 docs, it's marked as "Reserved" as well, but we just
decided to use it anyway.

This patch unifies the behavior between Gen4-5 and Gen6+.

Note that this is separate from point sprite texcoord behavior.

Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>

diff --git a/src/mesa/drivers/dri/i965/brw_sf_state.c b/src/mesa/drivers/dri/i965/brw_sf_state.c
index 69a6d6befeaec960dbb66750314f049853f5f3de..edc6967d2951f31368b48a130b84b5f4343da130 100644 (file)
--- a/src/mesa/drivers/dri/i965/brw_sf_state.c
+++ b/src/mesa/drivers/dri/i965/brw_sf_state.c
@@ -132,33 +132,7 @@ static void upload_sf_unit( struct brw_context *brw )
    else if (sf->sf6.line_width <= 0x2)
        sf->sf6.line_width = 0;
 
-   /* _NEW_BUFFERS */
-   if (!render_to_fbo) {
-      /* Rendering to an OpenGL window */
-      sf->sf6.point_rast_rule = BRW_RASTRULE_UPPER_RIGHT;
-   }
-   else {
-      /* If rendering to an FBO, the pixel coordinate system is
-       * inverted with respect to the normal OpenGL coordinate
-       * system, so BRW_RASTRULE_LOWER_RIGHT is correct.
-       * But this value is listed as "Reserved, but not seen as useful"
-       * in Intel documentation (page 212, "Point Rasterization Rule",
-       * section 7.4 "SF Pipeline State Summary", of document
-       * "Intel® 965 Express Chipset Family and Intel® G35 Express
-       * Chipset Graphics Controller Programmer's Reference Manual,
-       * Volume 2: 3D/Media", Revision 1.0b as of January 2008,
-       * available at
-       *     https://01.org/linuxgraphics/documentation/hardware-specification-prms
-       * at the time of this writing).
-       *
-       * It does work on at least some devices, if not all;
-       * if devices that don't support it can be identified,
-       * the likely failure case is that points are rasterized
-       * incorrectly, which is no worse than occurs without
-       * the value, so we're using it here.
-       */
-      sf->sf6.point_rast_rule = BRW_RASTRULE_LOWER_RIGHT;
-   }
+   sf->sf6.point_rast_rule = BRW_RASTRULE_UPPER_RIGHT;
 
    /* _NEW_POINT */
    sf->sf7.sprite_point = ctx->Point.PointSprite;