i965/fs: Handle derivative quality decisions in the front-end.

Kristian noted that there's very little use of brw_wm_prog_key in the
generator, and that it basically just generates what it's told, without
caring about what stage it's handling.

One exception to this is derivative handling.  When handling dFdxCoarse
and dFdxFine, we packed an enum value in a second source register,
explicitly telling the generator what to do.  For dFdx, we specified an
enum value of "please use the hint", then checked the program key in the
generator level code.

A natural method is to define separate FS_OPCODE_DD[XY]_{COARSE,FINE}
opcodes, and have the front-end (which already decides what IR to
generate based on the program key) decide which dPdx/dPdy should
correspond to.  This consolidates the decision making in one place.

Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
Reviewed-by: Matt Turner <[email protected]>

1 files changed, 4 insertions, 8 deletions

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h
index fa473d08ef6..e7f6a2bad8e 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -910,8 +910,10 @@ enum opcode {
 
    VEC4_OPCODE_PACK_BYTES,
 
-   FS_OPCODE_DDX,
-   FS_OPCODE_DDY,
+   FS_OPCODE_DDX_COARSE,
+   FS_OPCODE_DDX_FINE,
+   FS_OPCODE_DDY_COARSE,
+   FS_OPCODE_DDY_FINE,
    FS_OPCODE_PIXEL_X,
    FS_OPCODE_PIXEL_Y,
    FS_OPCODE_CINTERP,
@@ -1093,12 +1095,6 @@ enum opcode {
    GS_OPCODE_FF_SYNC_SET_PRIMITIVES,
 };
 
-enum brw_derivative_quality {
-   BRW_DERIVATIVE_BY_HINT = 0,
-   BRW_DERIVATIVE_FINE = 1,
-   BRW_DERIVATIVE_COARSE = 2,
-};
-
 enum brw_urb_write_flags {
    BRW_URB_WRITE_NO_FLAGS = 0,